Ideas for DC-Mode properties for the PowerSupply class

Erst mal Stichpunkte in deutsch.

Idee

Im CCT-Meeting vom 27. Apr. 2017 zum Thema FRS washing procedure stellte sich heraus, dass die Korrektur der Hysteresefehler, also das mehrmalige kontrollierte Rauf- und Runterfahren der Magnete vor dem eigentlichen Einstellen des Sollwertes, wahrscheinlich am einfachsten mit Geräten im DC-Betrieb machbar ist. Das widerspricht allerdings der Anforderung von LSA, dass alle Geräte multiplexed sein sollen.

Eine Option ist nun, eine Property DCCurrent oder DCValue für die gepulsten und die gerampten Varianten von PowerSupply zu erfinden, mit der man die "Washing Procedure", ganz ähnlich wie bisher, von einer Anwendung (dem Sequencer) aus vornehmen kann.

Auch für die Inbetriebnahme, oder in Phasen wo es kein Timing gibt, wäre eine solche Property hilfreich. Bei MX hatten wir mal die Properties MAGNSVCS und MAGNSVCI genau dafür erfunden.

Die prinzipielle Vorgehensweise wäre etwa so:

1. dem Gerät sagen: Höre nicht mehr auf Events
2. per DCCurrent die gewünschten Sollwerte schicken (die washing procedure ausführen)
3. dem Gerät sagen: Höre wieder auf Events

Für die Funktion "Höre nicht/wieder auf Events" wäre eine weitere Property, etwa DCMode, sowie ein entsprechender interner Zustand in der FESA-Klasse notwendig. Ist das Gerät nicht im DC-Mode, muss der Zugriff auf DCCurrent abgelehnt werden.

opReady

Laut Definition muss ein Gerät opReady = false melden, wenn es nicht betriebsbereit ist. Die gemultiplexten Varianten von PowerSupply sind wahrscheinlich nicht opReady, wenn sie im DC-Mode sind.

Was das genau für's Interlock bedeutet, oder ob zumindest das "Washing" ein erlaubter Betriebszustand ist, muss noch genau bedacht werden. Evtl. muss es dann drei interne Zustände geben, z.B. "ready" (= pulsed/ramped), "washing" und "commissioning", wobei die letzen beide DC-Mode bedeuten.

Paralleler DC- und Pulsbetrieb auf einer SCU

Ein Problem ergibt sich, wenn Magnete einer SCU zum Teil gemultiplext (sie hören auf Timing) und zum Teil im DC-Mode (sie hören nicht auf Timing) betrieben werden sollen. Die gemultiplexten müssen zeitgerecht bedient werden, besonders die gerampten. Die im DC-Mode dürfen beim Zugriff auf das Equipment die gemultiplexten nicht stören.

In Device Access ist das kein Problem, da Kommandos (Zugriffe auf das Equipment, die nicht event-gesteuert sind) auf SEs, die im Event-Mode laufen, automatisch nur im Gap ausgeführt werden.

Im neuen Timing gibt es kein Gap mehr. Hier ist (noch) nicht klar, woher die FESA-Klasse wissen kann, wann sie diese Kommandos ausführen darf, ohne die zeitkritischen Zugriffe zu stören.

Erweiterte Property DCValue

Eine weitere Idee wurde im Meeting entwickelt, die insbesondere für gerampte Geräte interessant wäre für die Inbetriebnahme oder für Zeiten ohne Timing.

Mit der Property DCValue würde man nicht den Strom schicken, sondern die BPID. Damit holt man den Sollwert für diese BPID aus dem lokalen Speicher und schickt ihn zum Gerät. Der eigentliche Sollwert wird also nicht mit der Property geschickt.

Im Falle von gerampten Geräten könnte das bedeuten, das tatsächlich die für die BPID abgelegte Rampe einmalig gefahren wird.

Um maximal flexibel zu sein, könnte man sich DCValue mit zwei value-items denken, current und bpid, die ausschließlich alternativ benutzt werden dürfen.