labview.gsi.de www-wnt.gsi.de/shiptrap/ labview.gsi.de/CS/cs.htm

1. Report on data acquisition and control systems of trap facilitiesDietrich Beck, DVEE/GSI, 23th of May 2002 http://labview.gsi.de http://www-wnt.gsi.de/shiptrap/ http://labview.gsi.de/CS/cs.htm

3. 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

4. Requirements to the control system • Active control in real-time with a precision of 100ns • 300 -1000 process variables (most of them are “static” ) • “ simple” data acquisition • High flexibility • SHIPTRAP has many different operational modes • new (not yet foreseeable) experimental techniques • Control System to be maintained by a PhD student • development environment must be easy to learn • creation and changing of GUIs should be simple • hardware and drivers have to be commercially available • Reusable for other (trap) experiments, if possible

5. Hardware

6. Cooking Recipe for the SHIPTRAP Control System • Take the concept and the (modified) design from the ISOLTRAP CS • Implement the control system with LabVIEW, • Add the DSC module (former BridgeVIEW) for trending and alarming, • Use a G++ toolkit to implement the CS in an object oriented way • Classes • Inheritance • G++  C++  limited number of levels of inheritance (VIs of the new class have links to VIs of the parent class )

7. Functionality of the BaseProcess Class set watchdog alarm set tags SuperProc DSCIntProc DSC Engine inheritance install/remove watchdog set status and error Device Process BaseProcess • Individual event, periodic action and state machine loops (three threads) • Watchdog (event and periodic action loop) • Communication between processes via calls • Simple (one way) • Synchronous (wait for answer) • Asynchronous (answer will be sent later) • Trending and alarming via the DSC interface process • Parent class for ALL other processes • Daughter classes add new events, attributes and methods

8. Caller Callee localhost Simple Call Caller Client_node2 Server_node1 Callee node1 node2 thread of caller continues execution no feedback from callee (except: “callee does not exist”) LabVIEW message queue TCP/IP

9. Synchronous Call 1 Caller Callee 2 (temporary LabVIEW message queue) localhost Client_node2 Server_node1 Callee Caller Server_node2 Client_node1 node1 node2 thread of caller is blocked/waits until answer is received or call timed out no programmatic overhead needed for answer (success, act value, error…) LabVIEW message queue TCP/IP

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

11. User PC On-line Analysis GUI Control GUI Call Hardware Software (Proc) Software (Lib) Exp. Specific General Part Buy! OPC TCP/IP? Toolkit Central PC Comm. Interface DSC Interface DSC Engine Data Server Super Central Process Super Comm. Interface Comm. Interface Super Data Acquisition Timing AFG High Voltage DataAcq. Instr. Driver Timing Instr. Driver AFG Instr. Driver HV Instr. Driver Frond-end PC Frond-end PC SR430 PPG100 DS345 IHQF015p

12. Toolkit User PC Central PC Frond-end PC Frond-end PC

13. Performance • Trending: each action in each process is monitored via trending • Alarming: each error in each process is monitored via alarming • Watchdog: event thread and periodic action thread of each process • RAM: each process takes about 300-400kByte • CPU: overhead for 50 processes is about 10% CPU time (PIII 700MHz) • No real time system! • “Roundtrip” time for local synchronous call is 11ms (overhead: see above; PIII 700MHz) • “Roundtrip” time for remote synchronous call is 33ms (overhead: see above; PIII 700MHz  PIII 500MHz  PIII 700MHz)

14. Status and Outlook SHIPTRAP specific part • Work has started • Test version (including data acquisition, timing and frequencies) summer 2002 • “Final System” summer 2003 • Late 2001: first beam time with prototype of an old version General part of the control system • Quite a few instrument drivers (or prototypes) • Core classes BaseProcess, SuperProc, DSCIntProc QueueServer and QueueClient are „finished“ • Classes for DS345, PPG100, SR430, IVI-Scopes “finished”

15. Coworkers • Faouzi Attallah (AP) • Dietrich Beck (DVEE) • Holger Brand (DVEE) • Klaus Poppensieker (DVEE) • Wolfgang Quint (AP) • Johannes Schönfelder, August 2000-June2001 (AP) • Christian Toader, August 1999-August 2000 (AP)