1 / 20

CS – a control system framework

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

deon
Télécharger la présentation

CS – a control system framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related