A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, [email protected] A Control System Framework A control system framework for experiments at

A C

ontro

l Syste

m Fra

mew

ork

DVEE Palaver, 4/2003, Dietrich Beck, [email protected]

A C

ontro

l Syste

m Fra

mew

ork

A control system framework for experiments at GSI

Dietrich Beck, DVEE/GSI

http://labview.gsi.de/CS/cs.htmhttp://www.gsi.de

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

Outline

• Motivation

• Requirements

• Design

• {Implementation details}

• Status

Of course, we try some live demo!

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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 10.000 process variables per experiment• LabVIEW as the typical development tool

Tomorrow

• huge experiments• 10.000 100.000 1.000.000 10x process variables • How far can we go with LabVIEW?

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

SHIPTRAP - motivation

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

STOP-CELL

EXTRACTION RFQ

BUNCHER &COOLER

TRANSFER REGION

PREPARATIONTRAP

cold ion bunchesSHIP extraction to ext. experiments

PRECISION TRAP

mass measurements

100* 50 50 50 50

* # of process variables

SHIPTRAP – experimental set-up

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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

134Nd

SHIPTRAP – experimental procedure

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

P H E L I xeta w a tt o ch - n erg ie a ser fü r S ch w er- o n en E p er im en te

Options:

fs-Pulse : 500 fs, 500 J 1015 W/(m)2

ns-Pulse : 0.5 bis 10 ns , 1-4 kJ

(Kilowatt Megawatt Gigawatt Terrawatt Petawatt)

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

2,28

m

2,88 m

5,26 m

3,51

m

10,43 m

22,1

2 m

4,0

0 m

7,5

0 m

13,4

6 m

5,3

0 m

7,4

6 m

1,90

m

2,36 m

5,92 m ,56 m ,63 m ,65 m

1,28 m

2,48 m

,90 m

,75 m

6,25 m

1,7

1 m

2,50 m

fs-Frontend

ns-Frontend

Pre-Amp

elevator to maintananceroom

cleanroom-wall

KDP to turnpolarisation

Midchainsensor

SF6

(exi

t)SF

6 (e

xit)

SF6 (exit)

SF6

(exi

t)

AM

PA

MP

AM

PA

MP

AM

P

AM

PA

MP

AM

PA

MP

AM

P

F R

Diagnostics

injection

SF2exit lens

SF2

15,2

1 m

2,43 m

10,4

0 m

RP1

RP2

RP3

RP0

RP

1,36 m

at (1

33

+3

0)c

m2

815

23

22

24

24

25

26

27

29

Pre

pa

rati

on

La

b

12

3

45

fs-f

ron

t e

nd

pre

am

pli

fie

rn

s-f

ron

t e

nd

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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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 3MJ@24kV 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• N2-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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

High performance but too special

General,but weak performance

Optimal

A framework with high performance?

Let´s limit ourselves to 10.000 process variables in the first stage!

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

A simple control system – the LEGO® principle

User PC n

Control GUIOn-line Analysis GUI

Central PC

Sequencer

DataCollector DSC EngineDSC Interface

SR430 PPG100 DS345

Frond-end PC 1

Data Acquisition

DataAcq. Instr. Driver

Timing

Timing Instr. Driver

AFG

AFG Instr. Driver

High Voltage

HV Instr. Driver

IHQF015p

Hardware Software (Proc) Software (Lib) Exp. Specific General Part Buy! Event OPC

Frond-end PC n

DiscArchiver

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

Provides basic functionality to 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)• Notifier (like “Simple”, but unbuffered)

• Query event names and parameters

THE base class of CS!!!

The BaseProcess class

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

The core system…

Device Process

DSC EngineDSCIntProcSuperProc “Boss”

watchdog

set tagsset watchdog alarm

set status and error

BaseProcess

inheritancecreate/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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork{

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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.ProcConstructor5. DS345.ProcDestructor

• Encapsulate functionality of the BaseProcess class

• Call class specific member functions by virtual function calls (still pure LabVIEW)

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

• 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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

LabVIEW message queue

Caller Callee

localhost

Caller Callee

node1 node2

Client_node2 Server_node1

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

Example: A synchronous call

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork}

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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

PC

VME

MeasurementControl

LogicalDevice1

LogicalDeviceN

Parameter Data

Interface

RealDevice1

RealDeviceN

Central PC

Central Process

DataCollector DSC EngineDSC Interface

SR430 PPG100 DS345

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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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

A C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

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?”)• 10.000 process variables o.k.!• 100.000 process variables well…………………….• > 1.000.000 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 C

ontro

l Syste

m Fra

mew

ork


A C

ontro

l Syste

m Fra

mew

ork

Near future of CS• Hopefully, the standard framework for experiments with up to 10.000 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

Documents

A Control System Framework DVEE Palaver, 4/2003, Dietrich Beck, [email protected] A Control System Framework A control system framework for experiments at