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