SlideServe
Menu
Préférences
© SlideServe · v2026

CS – a control system framework

deon avatar
20 diapositives · 370 Views · Oct 23, 2014

CS – a control system framework. Dr. Dietrich Hans Beck, DVEE, GSI 20 November 2002. Why do we need a framework?. Life-time of a control system > 10 years Experiments and their control systems grow in Size Functionality Complexity “Life-time” of a PhD student  2-3 years

CS – a control system framework - slide 1
01 / 20CS – a control system framework
1 / 17

Télécharger la présentation

CS – a control system framework
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation
  1. CS – a control system framework Dr. Dietrich Hans Beck, DVEE, GSI 20 November 2002

  2. Why do we need a framework? • Life-time of a control system > 10 years • Experiments and their control systems grow in • Size • Functionality • Complexity • “Life-time” of a PhD student  2-3 years • Dedicated “special” systems • Limited reusability • Full load of maintenance and development has to be carried by the experiments d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  3. … • A framework • Supplies functionality that is needed at many experiments • Can be maintained centrally and developed further by a dedicated group • Enables experiments to help each other • Requires only little experiment-specific add-ons to implement a system for a specific experiments • Saves man-power • … d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  4. short-lived isotopes gas cell buncher cooler trap prec. trap detector 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 d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  5. Requirements to the CS framework • Developer/Maintainer • Only one software tool that is easy to use • Commercial hardware and software tools • Maintainability • Well structured into small (independent) packages • Applicable to many projects • Documentation • User • Flexibility • Stability • Comfortable handling • High-Performance, we have to run sequences with a precision of 100ns and at 1s intervals • Access from and to everywhere d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  6. A general versus a performing tool Optimal High performance but too special General but too weak performance d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  7. Cooking recipe for the CS framework • LabVIEW • SCADA functionality (alarming, trending, security, …)  LabVIEW DSC module • Object oriented design  ObjectVIEW • Event driven communication between objects • Multi-Threading • Distributed system  TCP/IP • Aimed at ISOLTRAP or SHIPTRAP like systems (1000 -10000 process variables) d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  8. Example for a simple control system Events: Function calls: Process: Library: d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  9. BaseProcess class • Provides functionality for 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) • Query event names and parameters • THE base class of CS d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  10. ... • No further use of wrappers • Directly method calls to BaseProcess class (acquire, release, send msg, ...) • Faster, less problems when re-inheriting, faster mass compile,... • Optional: use no multiwait, but message queues only „OET := FALSE“ (avoid „slow“ multiwait,...) d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  11. Example: DS345 class • Class for AFG DS345 from SRS • Child of BaseProcess class • Adds events and methods Object template of the DS345 class d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  12. Add functionality: DS345.ProcCases • 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 an “Reset” event. d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  13. How to send an event: “call process” Call the Object “AFG1” (maybe instance of class DS345) on the remote node “abc123.gsi.de” with a “Reset” event d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  14. 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 d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  15. 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 d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  16. 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 d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  17. 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 d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  18. Status • It works, but some functionality still missing • Lots of new device classes are being implemented • GPL license (but requires LabVIEW, toolkits (SQL, DSC, …) and ObjectVIEW) • In operation at SHIPTRAP • ISOLTRAP, PHELIX and LEBIT work has started, data taking in 2003 • http://labview.gsi.de/CS/cs.htm d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  19. ObjectVIEW – what could be better? • Directories instead of LLBs (faster, easier handling without VI Library Manager, SSC,...) • „Protected“ methods • Improved creation of run-time environment • OPC (without DataSocket) • Re-Inheritance • Date of class creation in XML description • Duplicate methods in child class: default keep, optional overwrite • Missing methods in parent class: default keep method of child class, optional delete • Select multiple child classes for operations like replace or delete method d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm

  20. ObjectVIEW – what could be better… • Copy class with change of icons • Menu bar • Easy multiple inheritance • Automatic create of method templates • „Copy/move“: target class is nonsense • „Add method“ (and other actions): no change of class • „Add new read method“: without lock d.beck@gsi.de - http://labview.gsi.de/CS/cs.htm