A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework A control system framework for experiments at GSI Dietrich Beck, DVEE/GSI

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Outline Motivation Requirements Design {Implementation details} Status Of course, we try some live demo!

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Background ISOLTRAP (GSI/CERN) control system, started in 1992, VME based, still in use at three different experiments (D. Beck) Therapy control system, originating from West Area Neutrino Facility (CERN), started in 1995, VME and AIX based, Factory Link as SCADA system (H. Brand) Lot’s of input from experiments like SHIPTRAP (GSI), PHELIX (GSI), ISOLTRAP (CERN), LEBIT (MSU), WITCH (Leuven), … This is not an academic exercise but something to be used in real life Use small experiments as test ground for large experiments

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Experiment control system group Today working group within the department DVEE supports small and medium sized experiments in designing and developing control system up to process variables per experiment LabVIEW as the typical development tool Tomorrow huge experiments    10 x process variables How far can we go with LabVIEW?

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Boundary conditions Lifetime of experiments and their control systems > 10 years Experiments a their control systems grow in –Size –Functionality and –Complexity Responsible are PhD students (for about 2-3 years each) Each experiment has its dedicated control system –Limited Reusability –Full load of development and maintenance has to be carried by each experiment Idea: Development of a control system framework (CS)

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Definition - A framework... supplies functionality that is needed for different experiments can be maintained and developed further by a dedicated group allows for an exchange of software and know-how saves man-power … CONTROL SYSTEM = FRAMEWORK + EXP. SPECIFIC ADD-ONS

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Requirements Developer Only one development tool, that is easy to learn Hard- and Software commercially available Maintainability Software is structured into small (independent) packages Applicability to many different projects Documentation User Flexibility!!! – Multiplicity and type of used components as well as operational states(!) configurable on the fly System is operational during 100% of the time Comfortable handling Performance! Fast reaction time (ms). Repeat sequences at a rate of  1s with a granularity of  100ns. Access to and from everywhere

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework SHIPTRAP - motivation

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework STOP- CELL EXTRACTION RFQ BUNCHER &COOLER TRANSFER REGION PREPARATIONT RAP cold ion bunches SHIP extraction to ext. experiments PRECISION TRAP mass measurements 100 * 50 * # of process variables SHIPTRAP – experimental set-up

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework 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 SHIPTRAP – experimental procedure

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Options: fs-Pulse : 500 fs, 500 J  W/(  m) 2 ns-Pulse : 0.5 bis 10 ns, 1-4 kJ (Kilowatt  Megawatt  Gigawatt  Terrawatt  Petawatt)

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Continuous measurements Alignment Stability Energie Mode Vacuum etc. Shot repetition rates fs-frontend 10 Hz, 50 mJ ns-frontend 10 Hz, 50 mJ Preamp 1/min, 10 J Mainamp 1/h, 0,5-4 kJ PHELIX overview

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Laser Diagnostics ~ 30 spatial and spectral beam profiles Digital Cameras (IEEE-1394) ~ 10 temporal beam profiles Fast diodes and Oscilloscopes (GPIB) ~ 10 Pulse Energy Power meter (RS232) HV Control (discharge in ms) 12 Power supplies, Ignitrons, Dumps ~ 100 digital outputs ~ 10 DACs ~ 260 digital Inputs ~ 50 ADCs (Beckhoff Bus Terminals, Profibus, OPC) NI-DAQ 6071E Motion ~100 Axis for alignment etc. Trinamics SickPack Slow Control Vacuum N 2 -Flow Temperatur Crosshairs, etc (Beckhoff Bus Terminals, Profibus, OPC) Other Subsystems Timing, SR535 Safety System Pump Laser Accelerator Control PHELIX parameters (a couple of thousand)

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework High performance but too special General, but weak performance Optimal A framework with high performance? Let´s limit ourselves to process variables in the first stage!

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Cooking recipe for the CS framework One development tool  LabVIEW Fast learning curve Multi threading Event driven communication … Object oriented approach  ObjectVIEW Create objects (processes) on the fly Encapsulate data and their treatment “information hiding” Create high level classes by inheriting from base classes … SCADA functionality (alarming, trending, …)  LabVIEW DSC module Distributed system on several nodes  TCP/IP Scalability Remote access …

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework A simple control system – the LEGO ® principle User PC n Control GUIOn-line Analysis GUI Central PC Sequencer DataCollector DSC EngineDSC Interface SR430PPG100DS345 Frond-end PC 1 Data Acquisition DataAcq. Instr. Driver Timing Timing Instr. Driver AFG AFG Instr. Driver High Voltage HV Instr. Driver IHQF015p HardwareSoftware (Proc)Software (Lib) Exp. SpecificGeneral PartBuy! EventOPC Frond-end PC n DiscArchiver

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Provides basic functionality to 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) Notifier (like “Simple”, but unbuffered) Query event names and parameters  THE base class of CS!!! The BaseProcess class

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework The core system… Device Process DSC Engine DSCIntProcSuperProc “Boss” watchdog set tagsset watchdog alarm set status and error BaseProcess inheritance create/destroy To create an instance the “SuperProc” needs to know the instance name, the class of that instance is retrieved from a database via SQL together with instance specific data like the GPIB address of an instrument.

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework {

DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Inheritance with ObjectVIEW “Inheritance by copying”  A change of the object template (like a “bug fix”) of the parent class does not change the child class.  We must fix that same bug manually in all child classes or re-inherit child classes. We don’t want to do this! Object template of the parent class Object template of the child class

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Our solution: Encapsulation of functionality! Object template of the BaseProcess class Object template of a child class Class for AFG DS345 from SRS Adds events and methods Must provide the following methods: 1.DS345.ProcEvents (define events) 2.DS345.ProcCases (handle events) 3.DS345.ProcPeriodic (periodic action) 4.DS345.ProcConstructor 5.DS345.ProcDestructor Encapsulate functionality of the BaseProcess class Call class specific member functions by virtual function calls (still pure LabVIEW)

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework 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 a “Reset” event. Add methods: DS345.ProcCases.vi

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework How to send an event: CallProcess.vi Call the Object “AFG1” (maybe instance of class DS345) on the remote node “abc123.gsi.de” by sending a “Reset” event

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework 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…) Example: A synchronous call

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework }

DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework SHIPTRAP – Status (the GUI problem) CS based control system in use since October 2002 Development of a SHIPTRAP specific UI would take lots of time Example: ISOLTRAP GUI (Borland C++) has consumed a few man years ISOLTRAP and SHIPTRAP are quite similar just use the existing ISOLTRAP UI Central PC Central Process DataCollector DSC EngineDSC Interface SR430PPG100DS345 Frond-end PC 1 Data Acquisition DataAcq. Instr. Driver Timing Timing Instr. Driver AFG AFG Instr. Driver High Voltage HV Instr. Driver IHQF015p Frond-end PC n DiscArchiver PC  CS can be linked to other non-LabVIEW systems

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework PHELIX – Status detailed requirements specifications for the general and PHELIX specific part are finished fs-frontend is operational (Motion, Vision, Oscilloscope, DelayGate,…) Interlock system is finished (hopefully tomorrow) HV system is prototyped synchronization to accelerator is missing for the control system, the rest is straight forward

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework CS – Conclusion I CS is an object-oriented, multi-threaded, event driven and distributed framework with SCADA functionality. It can be used to develop dedicated control systems. Cave A (GSI), data taking SHIPTRAP (GSI), operational PHELIX (GSI), in commissioning ISOLTRAP (CERN), in commissioning LEBIT (MSU), in development HITRAP (GSI), planned It works GPL license, available for download

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework 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 Scaling to large systems (“LabVIEW everywhere?”) process variables  o.k.! process variables  well……………………. > process variables required in 2008 we don´t know the requirements of 2008 yet we would like to know the features of LabVIEW version 11 now! However: Memory management and compiler of LV should be improved! CS – Conclusion II

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, A Control System Framework Near future of CS Hopefully, the standard framework for experiments with up to process variables SHIPTRAP, PHELIX and others will keep us busy for a few years Still to be done: Extension of SCADA functionality like user management To be tried: State machines, object nets for the application layer Far future Framework for small experiments, complementary to a “universal control system” for the big experiments CS as a tool to prototype control systems for “big” experiments Big control systems have sub-systems based on CS, interfaced by TCP/IP So far, we have learnt a lot! CS – Conclusion III