1 / 25

CORBA usage within the TANGO control system

Discover the TANGO philosophy and CORBA usage within the TANGO control system. Learn how to connect clients to distributed objects, interface equipment with TANGO servers, and write TANGO applications efficiently. Explore the essence of TANGO and its object-oriented approach supporting Java, C++, Python.

brianeaton
Download Presentation

CORBA usage within the TANGO control system

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

  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)

  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 • Hide middleware details

  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…)

  5. Some device(s) One device One device One device

  6. A sophisticated device (RF cavity) another device

  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

  8. any command_inout(in string name, in any argin); 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

  9. typedef sequence<string> StringArray; Struct AttributeValue { …. any value; string name; }; typedef sequence<AttributeValue> AttributeValueList; AttributeValueList read_attributes(in StringArray names); 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)

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

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

  12. interface Device_2: Device { any command_inout_2(in string name, in any argin, in DevSource source); …. } 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

  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”

  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

  15. TANGO server code generator (POGO)

  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.

  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.

  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

  19. Client API • The DeviceProxy 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

  20. 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; Client API usage

  21. Example of generic application (Jive)

  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.

  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

  24. Future developments • Near future developments • 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

  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 : http://www.esrf.fr/tango

More Related