Introduction to the CS framework Definition of a

Introduction to the CS framework • Definition of a framework • Requirements • Example • Idea • Cooking recipe • Some statements Dietrich Beck, d. beck@gsi. de http: //www-w 2 k. gsi. de/labview/CS/cs. htm

A framework. . . • provides features that are commonly needed by many experiments. • can be maintained be a dedicated and central group. • allows for exchanging software and know-how. • saves man power. • should scale with future experiments. add-ons may become part of framework bug reports, new features requested control system = framework + add-ons bug fixes, new features, maintenance 01. 11. 2004 ECOS Dietrich Beck, d. beck@gsi. de experiment

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 10 Hz and a granularity of 1 ns. Access to and from everywhere 01. 11. 2004 Dietrich Beck, d. beck@gsi. de

Example 1: SHIPTRAP 100* STOPCELL EXTRACTION RFQ cold ion bunches * # of process variables SHIP 01. 11. 2004 50 50 BUNCHER &COOLER TRANSFE R REGION 50 PREPARATION PRECISION TRAP extraction to ext. experiments Dietrich Beck, d. beck@gsi. de 50 mass measurements

Complex timing scheme Cycle: 1 s 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) 01. 11. 2004 Dietrich Beck, d. beck@gsi. de

Idea behind the CS framework GUI • Distributed, individual objects are responsible for subtasks, as: –User interface –Cycle control –Acquisition –Devices Cycle Control Timing+DAQ AFG • No intrinsic bottleneck: Everything can talk to everything Using ‘standard’ pieces: Flexible system, that can even during runtime be adapted to the experiment 01. 11. 2004 Dietrich Beck, d. beck@gsi. de HV

Cooking recipe • One development tool Lab. VIEW – Fast learning curve – Multi-Threading – Event driven communication … • Object oriented approach Object. VIEW – Create objects (processes) on the fly – Create high level classes by inheriting from base classes – Encapsulate data and their treatment “information hiding” … • SCADA functionality (alarming, trending, …) Lab. VIEW DSC module • Distributed system on several nodes TCP/IP – Scalability – Remote access – … 01. 11. 2004 Dietrich Beck, d. beck@gsi. de

Statements • • Each object represents a hardware device, an application layer item or a GUI. send event Typically, objects are not static. They contain active code. Each Lego brick corresponds to an object. Lego tubes and studs are realized by an event mechanism: (Of course, an object can send an event to itself. *) (Of course, one can also use direct method calls. ) Objects are created and destroyed on-the-fly*. wait for event Different experiments may still use the same binary. exe. * much better than Lego 01. 11. 2004 Dietrich Beck, d. beck@gsi. de

. . . more statements. . . • Our OS is neither Windows, nor Linux, nor. . • Our OS is Lab. VIEW! • Active objects are no processes in the OS, but threads within the Lab. VIEW environment. • Multi-threading/tasking is organized by the internal scheduler. • If Lab. VIEW crashes, everything crashes. • Events/semaphores are only valid within one Lab. VIEW runtime/development system, but: • Several runtime/development systems can be coupled together via a CS server and client. But: • Only one CS system per node. 01. 11. 2004 Dietrich Beck, d. beck@gsi. de

. . . even more statements. . . • A Lab. VIEW "*. exe" file is not an executable. It requires a Lab. VIEW runtime system. • Neither a Lab. VIEW ". exe" nor the Lab. VIEW runtime system contain drivers. They must be installed separately on the target system. • If one uses the Datalogging and Supervisory Control (DSC) module, one must install the DSC runtime system seperately. • If one uses OPC servers, one must install. . 01. 11. 2004 Dietrich Beck, d. beck@gsi. de

. . . statements continued . . . • So far, CS is device oriented. – high performance, no intrinsic bottlenecks – no security or user management implemented (yet) • CS. . . : – was: based on third-party toolkit Object. VIEW – is: based on core developed at GSI – will be: what about Lab. VIEW 8? 01. 11. 2004 Dietrich Beck, d. beck@gsi. de

. . . final statements • Lab. VIEW is more expensive than emacs and gcc. • PCs are cheap, but. . . • control software is using more resources than office software – I/O – CPU – memory • control software is a good test program for PC hardware • PCI or c. PCI/PXI? • commodity hardware or industrial PCs? 01. 11. 2004 Dietrich Beck, d. beck@gsi. de

Example for a simple control system User PC n On-line Analysis GUI Control GUI DSC Interface Data. Collector Central PC DSC Engine Sequencer Disc. Archiver Data Acquisition Timing AFG High Voltage Data. Acq. Instr. Driver Timing Instr. Driver AFG Instr. Driver HV Instr. Driver Front-end PC 1 SR 430 Hardware 01. 11. 2004 Front-end PC n PPG 100 DS 345 Software (Proc) Software (Lib) Exp. Specific General Part Dietrich Beck, d. beck@gsi. de IHQF 015 p Buy! Event OPC

Usage of the CS framework today • experiments requiring high flexibility • experiments with a large variety of hardware types • experiments with up to 10, 000 process variables Motion Cave. A SHIPTRAP LEBIT PHELIX ISOLTRAP GSI, Germany CERN, Switzerland REXTRAP data taking commissioning MSU, USA development 01. 11. 2004 Dietrich Beck, d. beck@gsi. de