1. CORBA usage within the TANGO control system
TANGO philosophy
TANGO IDL file
Connecting client to our distributed objects
The TANGO servers to interface the equipment
Writing TANGO applications (client)
Asynchronism within Tango
Conclusion
CORBA controls /24/2019

2. What is TANGO ? Tango is the new generation of the ESRF control system
It is an evolution of the old ESRF TACO control system
It is developed in close collaboration between Soleil and ESRF
It uses CORBA as middleware between applications and the hardware
It is object oriented
It supports object oriented language (Java/C++/Python) and three OS (Linux, Solaris and Windows)
It is interfaced to commercial software used in our institutes (Igor, Matlab and LabView)
CORBA controls /24/2019

3. TANGO philosophy Do not give application programmers a headache …
A common way to access every kind of equipment (from a single relay to a sophisticated radio frequency system)
Hide middleware details
… neither the equipment interface programmer
Define a common pattern used to program every kind of equipment interface
CORBA controls /24/2019

4. TANGO philosophy (2) Generic: Every interfaced equipment is a “device”
A device supports :
A name and a state
Commands
Used to send order to the equipment (“On” to a power-supply)
Attributes (they are not CORBA attributes)
Used to read/write physical value (The current delivered by a power-supply)
They are normalized data types with a fixed set of properties
minimum, maximum, units, description….
Can be read/write or read-write
Zero, one or two dimensions
Miscellaneous utilities features (ping, black-box…)
CORBA controls /24/2019

5. Some device(s) One device One device One device
CORBA controls /24/2019

6. A sophisticated device (RF cavity)
another
device
CORBA controls /24/2019

7. TANGO IDL We need only one IDL file with only one interface “Device”
At least five CORBA operations needed within this interface
To send command
To read attribute(s)
To write attribute(s)
To get the list of command supported by the device
To get the list of attribute supported by the device
Using these calls, we are able to write generic applications
CORBA controls /24/2019

8. TANGO IDL: Sending commands
Commands have a name and may need data and may also return data
Only a pre-defined set of data type is supported (from the experiment gained from TACO)
Basic types, arrays of basic types and 2 exotic types
We don’t want to write as many operations in the IDL as the pre-defined set of data types allows
We are using CORBA Any object to transfer our data
It’s generic
We loose compile time type checking
any command_inout(in string name, in any argin);
CORBA controls /24/2019

9. TANGO IDL: Reading attribute
We want to be able to read several attributes within a single call (Sequence of)
Attributes supports “only” four types of data (CORBA Any)
Attributes are always transferred as arrays (sequence within the Any)
typedef sequence<string> StringArray;
Struct AttributeValue { ….
any value;
string name; };
typedef sequence<AttributeValue> AttributeValueList;
AttributeValueList read_attributes(in StringArray names);
CORBA controls /24/2019

10. TANGO IDL Writing attributes
Similar to the read_attributes operation
void write_attributes(in AttributeValueList values);
Getting command list
struct DevCmdInfo {
string name;
long in_type;
long out_data_type; };
typedef sequence<DevCmdInfo> DevCmdInfoList;
DevCmdInfoList command_list_query();
CORBA controls /24/2019

11. TANGO IDL Getting attribute list AttributeConfig { string name;
long data_type;
AttrDataFormat format; … };
Typedef sequence<AttributeConfig> AttributeConfigList;
AttributeConfigList get_attribute_config();
CORBA controls /24/2019

12. IDL helps but it could do more !
Obviously, the first release of the IDL file was not complete ! New features of Tango need change in the IDL
A new interface called “Device_2” which inherits from Device with re-declarations of some operations
interface Device_2: Device {
any command_inout_2(in string name,
in any argin,
in DevSource source); …. }
CORBA controls /24/2019

13. Connecting people Each device is a CORBA object with its own servant
The framework used to write our servers needs a database with one entry for each device
The stringified device IOR is also stored in this database
We don’t use the Naming Service. Our database plays the role of a Naming Service
The database is accessed like any other device via a database server with one device
To connect to the database device, we use a corbaloc URI. The host and port part of the URI is known via an environment variable ( -D option for the JVM). The object key is “hard coded”
CORBA controls /24/2019

14. What about the device interface programmer ?
We have defined a device pattern to write every device interface software in a common way
It is based on commonly used object oriented design patterns like singleton, command
The programmer need to write a class with:
One method for each command
A set of two methods for reading attributes
One method to write attributes
We use a code generator (POGO) to generate the “glue” around this class
CORBA controls /24/2019

15. TANGO server code generator (POGO)
CORBA controls /24/2019

16. Tango server framework
The DeviceImpl (Device_2Impl) class is written once and included in our library
The framework will call one specific method for each command, a set of two specific methods when reading attributes and one another when writing attribute.
The argument are extracted/inserted from/into the CORBA Any object by the framework.
The framework writes the device stringified IOR in the database
CORBA is hidden by the framework.
CORBA controls /24/2019

17. TANGO server framework
Most of the times, we do not create specific POA. We are using the “RootPOA”
In few cases, we use corbaloc URI and therefore need another POA.
Will OMG standardize how object accessed through corbaloc URI must be registered in POA ?
Our servers access hardware, care should be taken about thread policy
The SINGLE_THREAD_MODEL POA policy may generate deadlock for re-entrant call. We serialize device access ourselves in the framework.
CORBA controls /24/2019

18. Client side What will application programmers not like ?
Building connection to devices using a three stage mechanism
Checking which level of the Device interface the remote device implements
Managing reconnection to devices in case of front-end computer reboot or software crashes
Inserting/Extracting data into/from CORBA Any object
We provide them a “API” to make them happy when they arrive at work.
The main API classes are:
DeviceProxy, DeviceData and AttributeData
CORBA controls /24/2019

19. Client API The DeviceProxy class The DeviceData class
Connect to remote device in its constructor from the device name
Automatically reconnect in case of front-end failure
Manage our device naming convention
Knows which version of the “Device” interface the remote object supports and reacts accordingly.
The DeviceData class
Insert and extract data into/from the Any
Allows usage of standard C++ vector (list could be added)
The DeviceAttribute class
Similar to DeviceData but for attribute
CORBA controls /24/2019

20. Client API usage DeviceProxy dev(“sr/d-ct/1”);
DeviceData send_data,received_data;
vector<double> d_vect = …;
send_data << d_vect;
received_data = dev.command_inout(“MyCommand”,send_data);
string cmd_reply;
received_data >> cmd_reply;
CORBA controls /24/2019

21. Example of generic application (Jive)
CORBA controls /24/2019

22. Asynchronism within TANGO
Asynchronism means two things
Providing calls which does not block the clients (asynchronous calls)
Pushing event(s) to the applications (event system)
Asynchronous calls are implemented using the CORBA Dynamic Invocation Interface (DII)
Provided by many ORB’s (It’s not the case for the AMI)
Requires no change on the server side
It is easily hidden by our API
Implemented for our command_inout, read_attributes and write_attributes CORBA operation.
CORBA controls /24/2019

23. TANGO asynchronous calls
In the DeviceProxy class we have
command_inout_asyn() method which builds the CORBA request object and send it to the remote object (using the send_deferred call). It returns an asynchronous call identifier
command_inout_reply(id) method checks if the answer is arrived (using the poll_response CORBA call) and throws exception if not
command_inout_reply(id,timeout) method checks if the answer is arrived and wait for timeout if the answer is not yet there.
The API re-throws exception if the CORBA request object contains exceptions thrown by the device
Similar calls for read_attributes and write_attributes
CORBA controls /24/2019

24. Future developments Near future developments Long term development
Adding callback features to asynchronous calls.
Add a logging service
Add an event system (see A. Götz talk on Friday morning)
Write server using Python for fast prototyping
Connect Tango device to an history database
Long term development
Security (using CORBA Portable Interceptor ?)
Multi-devices access in one call
CORBA controls /24/2019

25. Conclusion
Object oriented software is more and more used in our institutes (50 people in this workshop)
CORBA is well adapted
TANGO device servers already deployed next to our existing TACO control system (20 classes already written)
It’s really great to choose standardized software (like CORBA). It was not difficult to move from one ORB supplier to another.
WEB site :
CORBA controls /24/2019