|
cumbia-tango 1.x
C++ multi threaded library based on cumbia and the Tango control system
|
cumbia-tango integrates cumbia with the Tango control system framework, providing specialised Activities to read, write attributes and impart commands. Readings are accomplished through either a poller or the Tango event system, for those attributes suitably configured. Write operations are always executed in an asynchronous thread and the result is delivered later in the main thread. Cumbia activities are employed by the module to setup the connection, access the database, subscribe to events or carry out periodic readings. Progress and result events are delivered to the main thread from the background activity. As stated in the previous section, activities identified by the same token belong to the same thread. Here, the token is the Tango device name. Applications that connect to the Tango control system will typically instantiate a CumbiaTango object that defines which kind of threads will be used (e.g. Qt’s for graphical interfaces) and thereafter parametrizes each reader or writer. Several modern design patterns have been exploited to provide a flexible and scalable architecture. Singletons have been completely replaced by service providers in order to offer services For graphical applications. The component provides helpful classes that can be used from outside an activity to access devices, fetch database properties or interpret exceptions raised from within the engine. Aside from these utilities, one would not normally employ this module directly. Cumbia-qtcontrols and qumbia-tango-controls is where to look for when the integration between the control system and the user interface is the objective.
cumbia-libs on github.io
| Other cumbia modules |
|---|
| cumbia module. |
| cumbia-tango module. |
| cumbia-qtcontrols module. |
| qumbia-tango-controls module. |
| qumbia-epics module. |
| qumbia-epics-controls module. |
| qumbia-plugins module. |
The CumbiaTango class is an extension of the Cumbia base one. Its main task is managing the so called actions. An action represents a task associated to either a Tango device attribute or a command (called source). Read, write, configure are the main sort of jobs an action can accomplish. More types of actions are foreseen, such as multiple readings or writings in sequence. CuTangoActionI defines the interface of an action. Operations include adding or removing data listeners, starting and stopping an action, sending and getting data to and from the underlying thread (for example retrieve or change the polling period of a source). CuTReader implements the interface and holds a reference to either an activity designed to receive events from Tango or another intended to poll a source.
Activities is where the Tango connection is setup, database is accessed for configuration, events are subscribed, a poller is started or a write operation is performed. This is done inside the thread safe init, execute and onExit methods, invoked from another thread. Progress and results are forwarded by the publishProgress and publishResult methods in the activity and received in the onProgress and onResult ones implemented by the action. Therein, CuDataListener’s onUpdate method is invoked with the new data. Reception safely occurs in the main thread.
As previously stated, activities identified by the same token (a CuData object) belong to the same thread. cumbia-tango groups threads by Tango device name.
The CuTReader is able to read device attributes as well as commands that return a value. What they read is determined by the source, expressed as a string with the same syntax known by QTango users.
The refresh mode is normally automatically chosen by cumbia-tango. If possible, events are used. If not, the second choice is polling. CuEventActivity and CuPollingActivity are the two cumbia activities involved respectively. Before starting either activity, CuTAttConfigActivity is used to get either the attribute properties or the command information. In any of the methods involving data exchange, CuData is used to hand results to the CuDataListener implementations installed on the reader.
The refresh mode as well as the polling period (if pertinent) can be changed at runtime.
CuTDbPropertyReader class deals with fetching device, attribute and class properties from the Tango database. Property retrieval is performed in a separate thread. CuData and CuDataListener have the same role as the aforementioned reader. A list of properties (also of mixed type - device, attribute or class) can be requested setting up a set of CuData input descriptive elements. See CuTDbPropertyReader documentation.
A cumbia plugin is available to sequentially or concurrently perform readings. See qumbia-plugins/cumbia-multiread.
CuTWriter is the class in charge of writing attributes and imparting commands. The syntax used for the target name is the same as the =reader's one. Writing is performed in a separate thread.
The classes listed above are rarely supposed to be directly instantiated and used. In graphical applications, the cumbia-qtcontrols and the cumbia-tango-controls modules have to be used. See the cumbia-qtcontrols and the cumbia-tango-controls modules for further information.
Graphical applications would normally instantiate CumbiaTango as explained in the constructor documentation and then pass the reference to the objects (readers, writers) that need it to communicate with the cumbia-tango engine. The other class methods should seldom be necessary.
1.9.5