Further Necessary Power Supply Functionality

Weitere notwendige Funktionen für die FESA-Klasse PowerSupply allgemein und speziell für gerampte Geräte.

Table of Contents

1 PowerSupply allgemein

1.1 Acquisition values

• Oszilloskop-Modus (DAQ-Hardware im FPGA)
  • Dieser Modus wird für alle Geräte angewendet, die nicht via MIL-Bus angesteuert werden.
  • Die DAQ-Hardware liefert sowohl Istwerte als auch Sollwerte mit einer einstellbaren Rate.
  • Als Rate ist zunächst 1 kHz angedacht.
  • Die DAQ kann ohne Unterbrechung durchlaufen. Man kann sie aber auch, an Events gebunden, starten und stoppen.
  • Der Oszilloskop-Modus ist völlig unabhängig von gepulsten oder gerampten Geräten. Er kann genauso gut für völlig andere Hardware eingesetzt werden.
  • Für den Zugriff von FESA auf die DAQ-Hardware soll eine entsprechende Bibliothek vom FESA-Framework zur Verfügung gestellt werden (evtl. in die SAFTLib integriert).
  • Im Zyklus (Sequence oder Beam-Prozess) muss genügend Zeit zur Verfügung stehen, um die DAQ-Daten mit einer FESA-RT-Action auslesen zu können. Siehe auch MIL-Bus sharing unten.
  • Siehe auch Data Aquisition (DAQ) für SCU basierte Systeme.

• Istwerte via MIL-Bus
  • Hier kann, wegen der eingeschränkten Bandbreite des MIL-Busses, die DAQ-Hardware nicht eingesetzt werden. Das gilt für gerampte und gepulste Geräte. Siehe dazu die Abschätzungen in MIL-Bus und DAQ-Betrieb.

• Datenstruktur der Property Acquisition
  • Sehr wahrscheinlich wird die Property am Ende anders heißen müssen, da "Acquisition" der Standard-Name für Istwerte aller FESA-Klassen ist. Zum Beispiel bei gepulsten Magneten liest man hiermit den einzelnen Istwert. Vielleicht sowas wie "Scope", "DaqScope", "ActValMonitor", ...?
  • Die Datenstruktur sollte, wenn irgend möglich, für alle gerampten Geräte, also auch für die mit MIL-Bus angesteuerten, die gleiche sein. Vorschlag:

    Startzeit
    Sollwert(e), Istwert(e), delta_t
    Sollwert(e), Istwert(e), delta_t
    ...
    Sollwert(e), Istwert(e), delta_t

    Wobei Startzeit der Zeitpunkt (die absolute Uhrzeit) der Messung des ersten Soll-/Istwertwert-Satzes in der Liste ist und delta_t die relative Zeit bis zur folgenden Messung.
    mit AP klären. Ob diese Struktur die geeignete für JAPC ist, muss noch geklärt werden. Evtl. muss man erst alle Sollwerte, dann alle Istwerte und dann alle delta_t, jeweils in einem Array, schicken. Bei mehreren Ist- und/oder Sollwerten pro Messung wird's dann noch etwas komplizierter.

• mit AP klären. Soll evtl. auch die Abtastfrequenz einstellbar sein?

• Istwerte sollen spätestens mit dem Milestone Release 11 (30.Mär.2018) funktionieren.

1.2 Powerup und Interlock der IFK

• Nach Powerup der IFK müssen eventuelle Slaves neu konfiguriert (von der FESA-Klasse neu programmiert) werden.
• Der Powerup muss quittiert werden.
• Auch Interlocks müssen auf der IFK quittiert werden (alle Geräte an einem MIL-Bus melden Interlocks über dieselbe Leitung).
• Sowohl Powerup als auch Interlock einer IFK wird über die Sumen-Interlock-Leitung des MIL-Busses signalisiert.
  • Alle Geräte an einem MIL-Bus melden Interlocks über die eine gemeinsame Leitung.
  • Die signalisierende IFK muss gefunden werden. Auch bedenken: Hinter einer IFK können mehrere Geräte stecken.
  • Es muss auch festgestellt werden, wenn ein Interlock nicht mehr ansteht (könnte lokal resettet sein). Das geht nur über pollen der IFK.
• Die Behandlung von Powerup und Interlock wird komplett in die FESA-Klasse verlagert. Die LM32-Software muss nix mehr davon wissen.
• Auch diese Funkionalität soll spätestens mit dem Milestone Release 11 (30.Mär.2018) vorhanden sein.

1.3 MIL-Bus sharing

• Periodische RT-Actions wie Status lesen, Interlock- oder PowerUp-Polling können den 'echten', an Events gekoppelte RT-Actions in die Quere kommen.
• Eine 'atomare' Aktion am MIL-Bus darf nicht unterbrochen werden. Ein Datum (in der Regel ein Istwert) lesen besteht aus zwei MIL-Bus-Transfers und bildet zusammen eine atomare Aktion.
  • Bei gepulsten Geräten sind die Zugriffe auf den MIL-Bus alle in der Hand der FESA-Klasse und können durch Mutexe entsprechend geschützt werden. Läuft die periodische Action zeitlich parallel zur 'echten' RT-Action, dann verlängert sich aber die Ausführung der 'echten' RT-Action, was dazu führen kann, dass die letzten Geräte in der Device Collection nicht mehr rechtzeitig bedient wird.
  • Bei gerampten Geräten wird der Funktionsgenerator vom LM32 über den MIL-Bus bedient, die periodischen Aktionen aber von der FESA-Klasse auf dem Prozessor der SCU ausgeführt. Hier sind Mutexe überhaupt nicht möglich. Die FESA-Klasse muss wissen, zu welchem Zeitpunkt Zugriffe via MIL-Bus möglich sind, ohne den LM32 zu stören.
• Derzeit wird das durch die sog. Kommando-Events geregelt (nach einem Kommando-Event hat man garantiert 20 ms Zeit z.B. zum Status lesen). Ein entsprechendes 'Gap'- oder 'Command'-Event auch im WR-Timing wäre gut, das irgendwo im Zyklus (im Beam-Prozess) kommt und in etwa besagt: die nächsten 50 ms ist keine RT-Action notwendig (wird keine Rampe gestartet, kein sollwert gesetzt, kein Istwert gelesen). Dieses Event müsste immer (mal) verschickt werden, auch wenn sonst kein Timing läuft. In der (definierten) Zeit nach dem Event ist dann Status lesen usw. ohne Kollisionen möglich.

1.4 Direct Command Mode

• Oder kurz: DC-Mode. Siehe dazu auch DC-mode properties.
• Wie soll sich der DC-Mode auf opReady im Status des Gerätes auswirken? Vorschlag FE: gar nicht, entsprechend Power on/off.

2 PowerSupply gerampt

2.1 Acquisition values

• Oszilloskop-Modus (DAQ-Hardware im FPGA)
  • Es gibt keinen anderen Mechanismus, um Istwerte von gerampten (non-MIL-Bus-) Geräten zu lesen!
• Istwerte via MIL-Bus
  • Bei jedem Schreiben eines Stützpunktes (eines Polynoms) durch den LM32 wird auch ein (ADC-) Istwert gelesen.
  • Beachtet werden muss, dass zwischen geschriebenem Sollwert und gelesenem Istwert ein Versatz von 1 oder 2 Stützpunkten vorliegt. Der Sollwert, der vom LM32 geschrieben wird, wird vom FG nicht direkt an die Hardware geschickt. Damit gehört der zugehörige gelesene Istwert zu einem bereits geschickten Sollwert und muss entsprechend 'einsortiert' werden.
  • Sowohl Istwerte (ADC-Werte) als auch Sollwerte (das c der Polynome ax2 + bx + c) werden (vom LM32?) gespeichert.
  • Soll- und Istwerte sollen direkt vergleichbar sein für eine (evtl. später zu implementierende) Überwachung von Soll/Ist-Abweichungen.
• Mit der in Kapitel 1.1 Acquisition values vorgeschlagenen Struktur der DAQ-Property können sowohl die mit DAQ gewonnenen als auch die über MIL gelesenen Rampen-Istwerte transportiert werden. Damit hätten wir ein einheitliches Property-Interface, unabhängig davon ob ein Gerät via MIL-Bus oder via SCU-Bus angesteuert wird.

2.2 Ein-/Ausschalten, Reset, Init

• mit LSA/DV-Kollegen klären.
• SIS18- und ESR-AEG vertragen zwar Sollwert-Sprünge, aber keine Spannungs- und Stromrampen, die nicht zusammen passen. In solchen Fällen fällt das Gerät aus.
• Im bestehenden Kontrollsystem kann ein Gerät 'im laufenden Betrieb' ein- und ausgeschaltet werden. 'Im laufenden Betrieb' heißt, alle anderen Geräte hören auf ihre Standard-Events und generieren Rampen als würden sie Strahl produzieren. Die Geräte-Software sorgt dafür, dass das Gerät nach dem Einschalten zunächst in kleinen Schritten und ohne Timing auf den Zwischenzyklus-Sollwert fährt. Erst anschließend wird in einem Gap des Timings der Rampenbetrieb wieder freigegeben. Damit hat man immer einen definierten Beginn des Rampenbetriebes.
• Ausschalten, Reset und Init funktionieren im Prinzip genauso. Alles geschieht im Gap, in dem das Gerät auf seinem Zwischenzyklus-Sollwert steht.
• Wie kann man im FAIR-Kontrollsystem einen definierten Beginn des Rampenbetriebes garantieren? Muss bei jedem Ausfall eines (einzelnen) Gerätes der Datamaster angehalten werden? Also etwas so:
  1. Datamaster anhalten => er durchläuft das Post-Pattern
  2. Gerät einschalten
  3. Datamaster starten => er durchläuft das Pre-Pattern und fährt im Regelbetrieb (mit dem Main-Pattern) fort
• ESR-AEG-Quadrupole: bis zu 4 Geräte teilen sich eine SPS, d.h., nach einem Fehler müssen bis zu 4 Geräte wieder auf Sollwert gefahren werden. Für POWER, STATUS, RESET, usw. gibt es eine Art 'Master'-IFK (nur eine IFK von 8 hat Verbindung zur SPS).
• Was soll ein Gerät tun, wenn es nicht opReady ist? Zur Zeit werden trotzdem die Rampen an das Netzgerät geschickt.

2.3 Powerup und Interlock der IFK

• Nach Powerup ist die IFK nicht mehr im FG-Modus.
• Bevor der Powerup nicht quittiert ist, macht die IFK 'gar nix'.

2.4 DRD- / DRQ-Leitungen

Neben der gemeinsamen Interlock-Leitung gibt es noch die DRD (Data Ready) und die DRQ (Data Request) Leitungen, die ebenfalls von allen an einem Bus angeschlossenen Geräten gemeinsam verwendet werden.

• DRQ-Leitung
  • Bislang hat der FG in der IFK über die DRQ-Leitung signalisiert, wenn neue Parameter benötigt werden - das handelt der LM32 ab.
• DRD-Leitung
  • Ist mit LSA/DV- und LOEP-Kollegen geklärt. DRD wird von der Software nicht mehr berücksichtigt!
  • Über die DRD-Leitung meldet die AEG, dass die Parallel-Einspeisung (PE) aus dem Toleranzband gelaufen ist.
  • Im bestehenden Kontrollsystem wurde daraufhin der Endwert der Rampe direkt eingestellt.
  • Was soll in Zukunft passieren? Der Endwert der Rampe liegt der FESA-Klasse nicht vor.
  • Muss man dabei den Spillabbruch mit den schnellen Quadrupolen beachten oder reicht es, dass die Reglersperre den Sollwert für den Magneten direkt auf Null zieht?
• Gibt es weitere Anwendungen für die beiden Leitungen, die wieder zu implementieren sind?

2.5 Spannungsrampen der AEG

• Ist geklärt. Es werden Spannungsrampen gefahren mit Interpolation zwischen den Stützpunkten, keine Steps mehr.

• Die AEG-Netzgeräte (Dipole in SIS18 und ESR) benötigen als Sollwertvorgabe eine Strom- und eine Spannungsrampe.
• Die Spannungsvorgabe erfolgte bisher im sogenannten Step-Mode. Zwischen den Stützpunkten wurde nicht interpoliert, stattdessen wurde direkt der nächste Stützpunkt angefahren.
• Soll das in Zukunft so bleiben?
• Wenn ja, wie geht das mit dem neuen Funktionsgenerator?
  • Kann LSA schon entsprechende Daten schicken?
  • Wie muss der 'Huhmann'-Algorithmus berücksichtigt werden?

2.6 Error Handling

Fehler, die bereits behandelt werden:

• Start Rampe ohne vorheriges Prep Rampe
• Prep Rampe folgt auf Prep Rampe, Start Rampe dazwischen fehlt
• Start Rampe Y aber Rampe X läuft noch

Fehler, die nicht behandelt werden, weil sie gewollt sein können:

• Endwert der letzten Rampe passt nicht zum Startwert der aktuellen Rampe

Weitere Fehler wurden im Moment nicht identifiziert.

2.7 Persistente Daten

• Ablegen und Lesen der Persistenz-Daten von gerampten Geräten dauert viel zu lange und skaliert auch NFS-mäßig nicht.
• Ist eine Persistierung von Sollwerten überhaupt, also unabhängig von gerampten Geräten, notwendig?
• mit LSA/DV- und FESA-Framework-Kollegen klären.

2.8 Maximale Länge eines Rampenabschnittes

• Daten von 12 FGs auf einer SCU lasten deren Speicher aus, dabei sind Istwerte noch nicht berücksichtigt.
• Auf wieviel Stützpunkte bzw. welche zeitliche Länge kann ein Rampenabschnitt (für einen BP) begrenzt werden?
• mit LSA/DV-Kollegen klären was maximal notwendig ist.

2.9 Einordnung ins Timing

• Datenversorgung des LM32 von der RT-Action mit den Events BP-Start und Sequence-Start.
• Start der Rampe / des LM32 mit dem Event Sync.

2.10 Realisierung

• Obige Punkte sollen angegangen werden, wenn die eigentlichen Rampen fehlerfrei laufen.
• Die Punkte werden, wo nötig, noch ergänzt/verfeinert.
• Für einzelne Punkte muss entschieden werden, wo (FESA oder LM32-Software) die einzelnen Funktionen eingebaut werden. Manche sind bereits realisiert, es sollte aber nochmal überdacht werden, ob sie an der richtigen Stelle implementiert sind.

3 PowerSupply gepulst

3.1 Mehrfaches Setzen des selben Sollwertes

• Verhalten der Netzgeräte beim wiederholten Setzen des selben Sollwertes (multiplexed Betrieb, Setzen in jedem BP) muss geklärt werden. Gibt es dabei ggf. Instabilitäten?
• Ist mit LSA/DV- und LOEP-Kollegen geklärt. Sollwert wird beim Event SEQ_START gesetzt, Istwert bei Event BP_START gelesen.

3.2 Feldgeregelte Magnete

Folgendes hatte wir schon mal diskutiert:

• Uhall(I)- und I(Uhall)-Polynome sind auch in der CDB.
• Properties SETTINGS und ACQUISITION haben ein zusätzliches value-item voltage.
• Eine Anwendung (z.B. LSA) schickt immer beide Werte, also SETTINGS.current und SETTINGS.voltage, und die FESA-Klasse nimmt den korrekten, der aktuelle Regelung entsprechenden Wert. Dann muss eine Anwendung nix von der Regelung wissen.
• Fehlt das entsprechende SETTINGS value-item (partial set), liefert die FESA-Klasse einen Fehler zurück.
• ACQUISITION soll für feldgeregelte Magnete immer beide Werte liefern, unabhängig von der aktuellen Regelung. Annahme: Neben der Hallsonde (für voltage) sollte immer auch ein DCCT (für current) vorhanden sein.
• Feldgeregelte Magnete ohne DCCT oder stromgeregelte Magnete ohne Hallsonde liefern in ACQUISITION nur das entsprechende value-item zurück.
• Die aktuelle Regelung wird als Bit im STATUS abgebildet.

3.3 Degaussing-Magnete

• Diese Magnete regeln das Restfeld des Haupt-Magneten auf Null (deshalb auch Nullfeldregler).
• Sie werden in FAIR mit der selben ACU gesteuert wie das Haupt-Netzgerät.
• Damit läge es eventuell nahe, kein eigenes Degaussing-Netzgerät (XXX1MH1_0) mehr zu implementieren, sondern das Lesen des Degaussing-Strom-Istwertes und des Degaussing-Status (so es einen eigenen gibt) in Properties des Haupt-Netzgeräts (XXX1MH1) zu integrieren.
• Es wird in Reihe geschaltete Magnete geben, die von nur einem Haupt-Netzgerät gesteuert werden, wo aber jeder Magnet ein eigenes Degaussing-Netzgerät besitzt.
  • Alle Netzgeräte (Haupt- und Degaussing-) werden an einer ACU hängen
  • Wie hießen die z.B. 3 Degaussing-Nomenklaturen, wenn die Haupt-Nomenklatur XXX1MH1 ist und es bei eigenständigen Degaussing-Nomenklaturen bleibt?
  • Bzw. wie hießen die value-items, wenn die Degaussing-Magnete property-mäßig in den Haupt-Magneten integriert wären?
• Der neue GTS1MU1 soll mit FESA gesteuert werden. Dieser besitzt auch ein Degaussing-NG und wäre ein geeignetes "Übungsobjekt".

4 Etwas außerhalb der Reihe

4.1 Bestehende Degaussing-Magnete in TK und HEST

• Bei DC-Magneten werden Degaussing-Netzgeräte aktiv, wenn das Haupt-NG ausgeschaltet ist. Das geschieht automatisch, also ohne Zutun der Geräte-Software.
• Bei gepulsten Magneten werden Degaussing-Netzgeräte aktiv, wenn der Sollwert für den Hauptmagneten Null ist. Auch das geschieht automatisch.
• In Zukunft werden all diese Magnete gepulst betrieben. Wenn die Automatismen weiterhin so bleiben wie sie sind, werden wir zwei verschiedene Degaussing-Methoden für gepulse Magnete haben:
  1. Degaussing bei Power = off (bei den ehem. DC-Magneten, Gerätemodell MD)
  2. Degaussing bei Sollwert = 0 (bei den ehem. gepulsten Magneten, Gerätemodell MX)
• Das ist, wie gesagt, völlig transparent für die Gerate-Software. Aber im Operating will man vielleicht mal wissen, mit welcher Methode ein Magnet degausst wird. Und die Frage ist, ob man beide Methoden so beibehalten oder für alle Magnete die Degaussing-Methode für gepulste Magnete realisiert möchte.
• Hier alle dem Kontrollsystem bekannten Degaussing-Magnete:

       DC: GHFSMU1_0, GTS3MU1_0, GTS6MU1_0, GTS7MU1_0.
  gepulst: GHHTMU1_0, GTE3MU1_0, GTH4MU1_0, GTK3MV1_0,
           GTK3MV3_0, GTK3MV4_0, GTS1MU1_0.
  

4.2 LM32 parallel nutzen

• Vorschlag von U.Krause und M.Thieme: Mehrere LM32 nutzen, einer pro MIL-Strang (Zukunftsmusik).