Sequencer: Class-interface adaption
Der Sequencer ermöglicht automatisiertes Testen von Geräten durch den kompletten Stack (siehe AP
https://www-acc.gsi.de/wiki/Service/Intern/Sequencer). Für Frontend-Software und die tatsächlichen Geräte bestehen gewisse Einschränkungen, die durch eine Erweiterung der Property-Schnittstelle abgebildet werden müssen.
Brainstorming
- Beispiel PowerSupplies:
- Es gibt sensible Geräte (dürfen nicht springen, gehen sonst kaputt), z.B.
- Dipol FRS
- Quelle CRYRING
- Kühler
- ...
- Normale Ansteuerung der Geräte kann schädlich sein
- Brauchen eine command-property um von multiplexed Werten / Rampen einen auszuwählen für den Test durch den Sequencer
- "RefValueSet" Prop
- mittels value-item den BP für Sollwerte auswählen und damit aktiv schalten
- timing-unabhängig und on-demand
- Die Erfassung der Aquisition-data ist noch unklar. Mit der vorhandenen Property geht das nicht, das müsste auch was 'onDemand'-mäßiges sein
(vergleichbar mit 'DCValueAcq')
- Soll / Ist-Überprüfung zu einem bestimmten, evtl. noch einzuführenden Event
- Eventuell neuer Value-Type (sowas wie TIMED, etc.): ON_DEMAND -> Settings nur per Command setzen
Das wäre für 'empfindliche' Geräte, die eigentlich DC-Geräte sind, eine gute Lösung. Die Daten sind nach wie vor multiplexed, am Gerät
werden sie aber nur auf explizite Aufforderung gesetzt.
- statt DCMode würde man damit aus einer Menge von schon versorgten Werten wählen
- 'DCMode' und 'DCValue' werden damit überflüssig!
- Beispiel Schrittmotoren:
- Referenz-Positionswerte einstellen; Referenz-Positionswerte anfahren; Ist-Position abfragen
Verallgemeinerung
- Status-Bits auslesen
- Referenz-Sollwerte / -Rampensetzen via Command-Property, Aktivieren der Referenzwerte mit separater Property; Überprüfung der Ist-Werte
Offene Fragen
- Was wird noch alles benoetigt? Was fehlt noch?
--
MatthiasWiebel - 17 Jun 2020