CORBA usage within the TANGO control system n

CORBA usage within the TANGO control system n n n n 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 2002 10/18/2021 1

What is TANGO ? n n n n 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 Lab. View) CORBA controls 2002 10/18/2021 2

TANGO philosophy n 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 n … neither the equipment interface programmer – Define a common pattern used to program every kind of equipment interface – Hide middleware details CORBA controls 2002 10/18/2021 3

TANGO philosophy (2) n n 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 2002 10/18/2021 4

Some device(s) One device CORBA controls 2002 10/18/2021 One device 5

A sophisticated device (RF cavity) another device CORBA controls 2002 10/18/2021 6

TANGO IDL n n We need only one IDL file with only one interface “Device” At least five CORBA operations needed within this interface – – – n 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 2002 10/18/2021 7

TANGO IDL: Sending commands n n 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 n n 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 2002 10/18/2021 8

TANGO IDL: Reading attribute n n n 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> String. Array; Struct Attribute. Value { …. any value; string name; }; typedef sequence<Attribute. Value> Attribute. Value. List; Attribute. Value. List read_attributes(in String. Array names); CORBA controls 2002 10/18/2021 9

TANGO IDL n Writing attributes – Similar to the read_attributes operation void write_attributes(in Attribute. Value. List values); n Getting command list struct Dev. Cmd. Info { string name; long in_type; long out_data_type; }; typedef sequence<Dev. Cmd. Info> Dev. Cmd. Info. List; Dev. Cmd. Info. List command_list_query(); CORBA controls 2002 10/18/2021 10

TANGO IDL n Getting attribute list Attribute. Config { string name; long data_type; Attr. Data. Format format; … }; Typedef sequence<Attribute. Config> Attribute. Config. List; Attribute. Config. List get_attribute_config(); CORBA controls 2002 10/18/2021 11

IDL helps but it could do more ! n n 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 Dev. Source source); …. } CORBA controls 2002 10/18/2021 12

Connecting people n n n 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 n n 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 2002 10/18/2021 13

What about the device interface programmer ? n n n 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 n We use a code generator (POGO) to generate the “glue” around this class CORBA controls 2002 10/18/2021 14

TANGO server code generator (POGO) CORBA controls 2002 10/18/2021 15

Tango server framework n n n The Device. Impl (Device_2 Impl) 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 2002 10/18/2021 16

TANGO server framework n n n Most of the times, we do not create specific POA. We are using the “Root. POA” 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 2002 10/18/2021 17

Client side n 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 n n We provide them a “API” to make them happy when they arrive at work. The main API classes are: – Device. Proxy, Device. Data and Attribute. Data CORBA controls 2002 10/18/2021 18

Client API n The Device. Proxy class – – n 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 Device. Data class – Insert and extract data into/from the Any – Allows usage of standard C++ vector (list could be added) n The Device. Attribute class – Similar to Device. Data but for attribute CORBA controls 2002 10/18/2021 19

Client API usage Device. Proxy dev(“sr/d-ct/1”); Device. Data send_data, received_data; vector<double> d_vect = …; send_data << d_vect; received_data = dev. command_inout(“My. Command”, send_data); string cmd_reply; received_data >> cmd_reply; CORBA controls 2002 10/18/2021 20

Example of generic application (Jive) CORBA controls 2002 10/18/2021 21

Asynchronism within TANGO n Asynchronism means two things – Providing calls which does not block the clients (asynchronous calls) – Pushing event(s) to the applications (event system) n 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 2002 10/18/2021 22

TANGO asynchronous calls n In the Device. Proxy 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 n Similar calls for read_attributes and write_attributes CORBA controls 2002 10/18/2021 23

Future developments n Near future developments – – – n 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 2002 10/18/2021 24

Conclusion n n 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 CORBA controls 2002 10/18/2021 25