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

CS – a control system framework

Dr. Dietrich Hans Beck, DVEE, GSI20 November 2002

20 November [email protected] -

http://labview.gsi.de/CS/cs.htm

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



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



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 techniqueScan: repeat cycle for different frequencies (minutes-days)

1s

134Nd

gas cell bunchercooler trapprec. trap detectorshort-lived isotopes



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



A general versus a performing tool

High performance but too special

General but too weak performance

Optimal



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 (1000 -10000 process variables)



Example for a simple control system

Events: Function calls: Process: Library:



BaseProcess class Provides functionality for all child classes

Two treads: event handling and periodic action. Optional: state machine in a 3rd 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



... 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,...)



Example: DS345 class Class for AFG DS345 from

SRS Child of BaseProcess class Adds events and methods

Object template of the DS345 class



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.



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



Simple Call

LabVIEW message queue

Caller Callee

localhost

Caller Callee

node1 node2

Client_node2 Server_node1

TCP/IP

•thread of caller continues execution•no feedback from callee (except: “callee does not exist”)



Synchronous Call


Caller Callee

localhost

Caller Callee

node1 node2


TCP/IP

1

2 (temporary LabVIEW message queue)

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



Asynchronous Call


CallerCallee

localhost

Caller

Calleenode1

node2


TCP/IP

1

2

Client_node3

Async Callee

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)



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



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 2003 http://labview.gsi.de/CS/cs.htm



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



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

Documents

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