Report on data acquisition and control systems of trap facilities Dietrich Beck, DVEE/GSI, 23 th of May

Institute – Exp.PlatformSoftwareStatusContactComment KVI - Tri  p Jyvaskyla GSI - SHIPTRAPPC(WinNT)LabVIEW + GSI - HITRAPPC(WinNT)LabVIEW + University of Ferrara LPCPC(WinNT) + XLabwin CVI + K.U. Leuven - CSNSM - MISTRALoperational LMU University of Mainz University of Warsaw CERN - ISOLTRAPPC(Win2000) VME(OS/9) C++ C, Assembler to LV ? CERN - REXTRAPPC(Win2000) VME(OS/9) C++ C, Assembler Imperial

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

Requirements to the control system Active control in real-time with a precision of 100ns 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 1.development environment must be easy to learn 2.creation and changing of GUIs should be simple 3.hardware and drivers have to be commercially available Reusable for other (trap) experiments, if possible

Hardware Vacuum pump controllerTC600, TCM1601 RS485Pfeiffer Active Gauge ControllerAGCRS232Edwards Gas inlet controllerRVC200 RS232 Pfeiffer Pulse Pattern GeneratorPPG100ISABecker & Hickl Arbitrary Function GeneratorDS345GPIBStanford Research High voltage power suppliesCANiseg Multi I/O card6024EPCINational Instruments CAN-Bus interfacePCINational Instruments RS485 interfacePCINational Instruments GPIB interfacePCI, Ethernet National Instruments Transient RecorderPCINational Instruments Multi Channel ScalerSR430GPIBStanford Research

Cooking Recipe for the SHIPTRAP Control System 1.Take the concept and the (modified) design from the ISOLTRAP CS 2.Implement the control system with LabVIEW, 3.Add the DSC module (former BridgeVIEW) for trending and alarming, 4.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 )

Device Process DSC EngineDSCIntProcSuperProc watchdog set tagsset watchdog alarm set status and error 1.Individual event, periodic action and state machine loops (three threads) 2.Watchdog (event and periodic action loop) 3.Communication between processes via calls a)Simple (one way) b)Synchronous (wait for answer) c)Asynchronous (answer will be sent later) 4.Trending and alarming via the DSC interface process 5.Parent class for ALL other processes 6.Daughter classes add new events, attributes and methods Functionality of the BaseProcess Class BaseProcess inheritance install/remove

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”)

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

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)

Toolkit User PC Control GUIOn-line Analysis GUI Central PC Central Process Comm. Interface Data Server DSC EngineDSC Interface SR430PPG100DS345 Frond-end PC Comm. Interface Data Acquisition DataAcq. Instr. Driver Timing Timing Instr. Driver AFG AFG Instr. Driver High Voltage HV Instr. Driver IHQF015p Super HardwareSoftware (Proc)Software (Lib) Exp. SpecificGeneral PartBuy! CallOPC TCP/IP? Super Frond-end PC Comm. InterfaceSuper

Toolkit User PC Central PC Frond-end PC

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 kByte 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)

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”

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)