...
4 | Because we use RW/ROdouble, ROpattern, and other BACI components, we have to include baci.idl. | |
6 | This is necessary for all alma interfaces so they will have the correct location within the Interface Repository. | |
8 | And now the creation of a new module, with the name PS. A module is (by ESO specifications) a part of code, which rounds up some functionality (same as package in Java and namespace in C++). | |
9 | Interface (like a class in C++) is a defined collection of methods and properties, specific for one object. One module can contain many interfaces with some common characteristics. | |
10-12 | When we are defining actions, we must write its arguments and what it returns. Every asynchronous action must have "in ACS::CBvoid cb, in ACS:CBDescIn desc". Note that beside arguments there is also a word "in". Here is short explanation of all possibilities (from Advance CORBA programming with C++):
| ]]></ac:plain-text-body></ac:structured-macro> |
13-15 | Here we define our properties as read-only attributes, which are read-only because we do not want someone to change them uncontrollably. |
When finished writing an IDL, the file must be "compiled" by an IDL compiler. In the ACS environment, you can simply use the acsMakefile, but this will be discussed later. At this point there is no actual need to compile the IDL since the client and servant stubs (generated by TAO from the IDL) never even need to be viewed to write the C++ class!
...
...
Configuration Database files
The Configuration Database uses these files so that distributed objects can be instantiated with pre-configured data for their properties. More about how this is done can be found in the Configuration Database and XML Schemas for Configuration Database documents.
For the PowerSupply Component we need to create three different XML files containing:
...
While a running system can have many XML files describing the configuration data for a particular instance of a Component, there can be only one XML schema per Component, defining the structure and all default values for the configuration of that Component type.
We will describe the case of the power supply component as it is in the acsexmpl module. This description is often considered a bit hard to understand at a first glance. As we said before we kindly suggest to read all the CDB documentation before proceeding. If you do not have time at the moment, we have added, at the end of this chapter, the case of the mount example that is simpler then the power supply. With the mount example we aim to help the developers in speeding up the process of creating new components. For the mount component, you should at least have a look on its IDL interface.
On the other hand the mount component example is not enough to fully understand the interactions between xml, xsd in the CDB. A good idea could be that of fully understand the case of the mount then read again this chapter to extend your knowledge with the power supply example.
| Code Block | ||||
|---|---|---|---|---|
|
...
| |||
<xs:schema targetNamespace="urn:schemas-cosylab-com:PowerSupply:1.0" |
...
xmlns:xs="http://www.w3.org/2001/XMLSchema" |
...
xmlns="urn:schemas-cosylab-com:PowerSupply:1.0" |
...
xmlns:cdb="urn:schemas-cosylab-com:CDB:1.0" |
...
xmlns:baci="urn:schemas-cosylab-com:BACI:1.0" |
...
elementFormDefault="qualified" attributeFormDefault="unqualified"> |
...
<xs:import namespace="urn:schemas-cosylab-com:CDB:1.0" schemaLocation="CDB.xsd"/> |
...
<xs:import namespace="urn:schemas-cosylab-com:BACI:1.0" schemaLocation="BACI.xsd"/> |
...
<xs:complexType name="PowerSupplyType"> |
...
<xs:sequence> |
...
<xs:element name="current" type="baci:RWdouble"/> |
...
<xs:element name="readback" type="baci:ROdouble"/> |
...
<xs:element name="status" |
...
> <xs:complexType> <xs:complexContent> <xs:restriction base="baci:ROpattern"> |
...
<xs:attribute name="resolution" type="xs:int" use="optional" |
...
default="511" /> |
...
<xs:attribute name="bitDescription" type="xs:string" use="optional" |
...
default="On,Remote,Sum Failure,External Interlock, DC Overcurrent,Phase Failure,Not Ready,State Inconsistent,Ramping"/> <xs:attribute name="whenSet" type="xs:string" use="optional" |
...
default="3, 2, 0, 0, 0, 0, 1, 1, 1"/> |
...
<xs:attribute name="whenCleared" type="xs:string" use="optional" |
...
default="2, 3, 3, 3, 3, 3, 3, 3, 3"/> |
...
</xs:restriction> |
...
</xs:complexContent> |
...
</xs:complexType> |
...
</xs:element> |
...
</xs:sequence> |
...
<xs:attribute name="id" type="xs:int" use="optional" default="0"/> |
...
</xs:complexType> |
...
<xs:element name="PowerSupply" type="PowerSupplyType"/> |
...
</xs:schema> |
1 & 3 | This is the namespace we will be using for PowerSupply. It is arbitrary but should include the name of the Component. |
4-5 | The namespace that was used for BACI and CDB. These urns are not arbitrary and can be found by looking in $ACSROOT/config/CDB/schemas/*. |
8-9 | Please see 4-5. |
10-38 | These rows describe the type of the record in the xml file. The user is free to customize this complex type in order to add specific information (see CDB documentation for further information about this issue). |
13-15 | Here we just specify that current is of type RWdouble and readback is a ROdouble. Nothing else needs to be specified because these are simple types already defined in BACI.xsd. |
17-34 | Since status is a ROpattern (which is a complex type), minimal attributes have been specified in BACI.xsd. Because of this, it is necessary to specify a pattern or enum's attributes since they will not change for any Component instantiated from this schema. |
39 | We specify that the xml contain one record of the same name of the component. The type of the record is PowerSupplyType defined above (see 10-38) |
The xml files are parsed against their schema definition. In PowerSupply.xsd the PowerSupply is defined to be of PowerSupplyType. By customizing the PowerSupplyType, the PowerSupply.xml will be accordingly different. If the developer would add some custom field to the configuration of the power supply, in the PowerSupply.xml file, he also has to change its schema definition. We suggest having a look on the CDB documentation about that. The acsexmplFilterWheel shows an example of a customized xsd/xml for a generic filter wheel. 1.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<?xml version="1.0" encoding="utf-8"?> |
...
<Components xmlns="urn:schemas-cosylab-com:COBs:1.0" |
...
xmlns:cdb="urn:schemas-cosylab-com:CDB:1.0" |
...
xmlns:baci="urn:schemas-cosylab-com:BACI:1.0" |
...
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> |
...
<_ Name="TEST_PS_1" |
...
Code="acsexmplPowerSupplyImpl" |
...
Type="IDL:alma/PS/PowerSupply:1.0" |
...
Container="bilboContainer"/> |
...
<_ Name="TEST_PS_2" |
...
Code="acsexmplPSOptimized" |
...
Type="IDL:alma/PS/PowerSupply:1.0" |
...
Container="bilboContainer2"/> |
...
</Components> |
This xml file describes the deployment information for components.
...
7. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
8. <current xmlns="urn:schemas-cosylab-com:TestPowerSupplyACS:1.0"/>
9 <readback xmlns="urn:schemas-cosylab-com:TestPowerSupplyACS:1.0"/>
10 <status xmlns="urn:schemas-cosylab-com:TestPowerSupplyACS:1.0"/>
11. </PowerSupplyACS>Actual configuration data ($ACS_CDB/CDB/alma/TEST_PS_1/ TEST_PS_1.xml).
This xml file describes a single instance for a PowerSupply component. Note that the property follow the specifications stated in the TestPowerSupplyACS schema.
2 & 26 | PowerSupplyACS corresponds to the name specified on line 44 of the XML schema and the schema namespace is also used here. |
3-4 | Please see 4-5 of the schema. |
8-10 | current, readback and status properties are defined in TestPowerSupplyACS schema. |
...
As we saw writing the constructor of the component, it receives a pointer to a maci::ContainerServices object. Really, maci::ContainerServices is an interface and the component receives an implementation of that interface defined in the maci module. The developer is free to replace this default implementation with another one that better fits its needs.
Throw the ContainerServices object the Containers offers the component a set of services freeing the developer of the details of their implementation.
The getContainerServices() method returns a pointer to the container services object so there is no need to store the container services object received in the constructor in a local variable.
Here I report a brief description of the services of the default implementation of the ContainerServices in the maci module. For further details, have a look at the doxygen documentation.
ACE_CString getName() // Return the name of the component
PortableServer::POA_var getPOA() // Return a reference to the POA
// Get a Component of type T
template<class T> T* getComponent(const char *name)
// Get a dynamic component of typoe T
template<class T> T* getDynamicComponent(maci::ComponentSpec
compSpec, bool markAsDefault);
// Get the default component (of type T) that implements the idl interface
template<class T> T* getDefaultComponent(const char* idlType);
// get the descriptor of a component
maci::ComponentInfo getComponentDescriptor(const char* componentName)
// Find components using their name or their type
ACE_CString_Vector findComponents(const char *nameWilcard, const char *typeWildcard)
void releaseComponent(const char *name) // release the component with the given name
void releaseAllComponents() // Release all the components
CDB::DAL_ptr getCDB() // Return a reference to DAL that allows accessing the CDB
PortableServer::POA_var getOffShootPOA() // Return the offShoot POA
// Activate a CORBA servant that implements the offshoot interface
ACS::OffShoot_ptr activateOffShoot(PortableServer::Servant cbServant)
// Deactivate a CORBA offShoot servant
void deactivateOffShoot(PortableServer::Servant cbServant)
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...