CS – a control system framework Dr. Dietrich Hans Beck, DVEE, GSI 20 November 2002

- Why do we need a framework? Life-time of a control system > 10 years Experiments and their control systems grow in Size Functionality Complexity “Life-time” of a PhD student  2-3 years Dedicated “special” systems Limited reusability Full load of maintenance and development has to be carried by the experiments

20 November - … A framework Supplies functionality that is needed at many experiments Can be maintained centrally and developed further by a dedicated group Enables experiments to help each other Requires only little experiment-specific add-ons to implement a system for a specific experiments Saves man-power …

20 November - Typical Scenario for a Mass Measurement Cycle: stopping of ions ion the gas cell (static) extraction from the gas cell transfer capture and cool ions in the buncher ejection from the buncher (dynamic) transfer capture in the cooler trap mass selective buffer gas cooling ejection from the cooler trap transfer capture in the precision trap purification excitation of ion motion at  RF   c = (q/m) · B (  gain of energy) measurement of kinetic energy via a time-of-flight technique Scan: repeat cycle for different frequencies (minutes-days) 1s gas cellbunchercooler trapprec. trapdetector short-lived isotopes

20 November - Requirements to the CS framework Developer/Maintainer Only one software tool that is easy to use Commercial hardware and software tools Maintainability Well structured into small (independent) packages Applicable to many projects Documentation User Flexibility Stability Comfortable handling High-Performance, we have to run sequences with a precision of 100ns and at 1s intervals Access from and to everywhere

20 November - A general versus a performing tool High performance but too special General but too weak performance Optimal

20 November - Cooking recipe for the CS framework LabVIEW SCADA functionality (alarming, trending, security, …)  LabVIEW DSC module Object oriented design  ObjectVIEW Event driven communication between objects Multi-Threading Distributed system  TCP/IP Aimed at ISOLTRAP or SHIPTRAP like systems ( process variables)

20 November - Example for a simple control system Events: Function calls : Process: Library:

20 November - BaseProcess class Provides functionality for all child classes Two treads: event handling and periodic action. Optional: state machine in a 3 rd thread Watchdog for both threads Alarming and status logging of all treads Methods for event driven communication Simple (no answer from callee) Synchronous (wait for answer from callee) Asynchronous (answer from callee is sent elsewhere) Query event names and parameters THE base class of CS

20 November - No further use of wrappers Directly method calls to BaseProcess class (acquire, release, send msg,...) Faster, less problems when re-inheriting, faster mass compile,... Optional: use no multiwait, but message queues only „OET := FALSE“ (avoid „slow“ multiwait,...)

20 November - Example: DS345 class Class for AFG DS345 from SRS Child of BaseProcess class Adds events and methods Object template of the DS345 class

20 November - Add functionality: DS345.ProcCases Is called from the BaseProcess event loop via a “virtual function call” Calls the methods added Example: function call to the DS345.reset method. Triggered by an “Reset” event.

20 November - How to send an event: “call process” Call the Object “AFG1” (maybe instance of class DS345) on the remote node “abc123.gsi.de” with a “Reset” event

20 November - Simple Call LabVIEW message queue CallerCallee localhost CallerCallee node1node2 Client_node2Server_node1 TCP/IP thread of caller continues execution no feedback from callee (except: “callee does not exist”)

20 November - Synchronous Call LabVIEW message queue CallerCallee localhost Caller Callee node1node2 Client_node2Server_node1 TCP/IP 1 2 (temporary LabVIEW message queue) Server_node2Client_node1 thread of caller is blocked/waits until answer is received or call timed out no programmatic overhead needed for answer (success, act value, error…)

20 November - Asynchronous Call LabVIEW message queue Caller Callee localhost Caller Callee node1 node2 Client_node2Server_node1 TCP/IP 1 2 Client_node3 Async Callee node3 Server_node2 thread of caller continues execution parallel execution of tasks distributed over several nodes programmatic overhead needed to synchronize answer (success, act value, error)

20 November - Performance (700MHz, PIII) Synchronous call on local node: 3ms Synchronous call to remote node: 15ms 100 instances: CPU load < 10% Needs RAM: each instance takes a few Mbyte Robust communication

20 November - Status It works, but some functionality still missing Lots of new device classes are being implemented GPL license (but requires LabVIEW, toolkits (SQL, DSC, …) and ObjectVIEW) In operation at SHIPTRAP ISOLTRAP, PHELIX and LEBIT work has started, data taking in

20 November - ObjectVIEW – what could be better? Directories instead of LLBs (faster, easier handling without VI Library Manager, SSC,...) „Protected“ methods Improved creation of run-time environment OPC (without DataSocket) Re-Inheritance Date of class creation in XML description Duplicate methods in child class: default keep, optional overwrite Missing methods in parent class: default keep method of child class, optional delete Select multiple child classes for operations like replace or delete method

20 November - ObjectVIEW – what could be better… Copy class with change of icons Menu bar Easy multiple inheritance Automatic create of method templates „Copy/move“: target class is nonsense „Add method“ (and other actions): no change of class „Add new read method“: without lock