Ref / Act comparison

Meeting 9.7.20

https://www-acc.gsi.de/wiki/FAIR/CCT/Minutes090720

Meeting 12.8.20

Mitschrift PKAIN

• Toleranzbandüberwachung
  • absolut: damit meinen wir den kleinstmöglichen Wert, den das Gerät auflösen kann
  • relativ: Abweichung (in %) vom aktuellen Setzwert, wenn die erlaubte relative Abweichung kleiner ist als die absolute, dann gilt die absolute Abweichung
    (z.B. Gerätemax.=3000A, abs. 3A, rel. 0.1% vom Setzwert
    Setzwert abs. rel.
    3000A 3A 3A
    2000A 3A 2A
    
    ??? den Teil verstehe ich jetzt wieder nicht mehr, weil die relative Abweichung immer kleiner als die absolute ist ????
    Ich werde mal bei EPS nachfragen, wie man sich das vorstellen muss)
  • Konfiguration der erlaubten Abweichungen über die vorhandene 'ValueConfig' im instancefile
• Toleranzbandverletzungen ablegen in std::map
  • BPC dient als key, als value wird eine structure mit Stamp, Soll, Ist u. erlaubter Abweichung abgelegt solange nur 1 Wert abgelegt wird, wird immer der letzte abgelegt (alte überschrieben)
  • map über Property verfügbar machen, falls Anwender das wünschen
  • möglicherweise statt einem Einzelelement einen ganzen Ringbuffer ablegen, falls Anwender das wünschen
• Rücksetzen der gespeicherten Toleranzbandverletzungen:
  • neue Property RESET???? (Namensvorschläge willkommen!)
    • über Filter kann man auswählen, welche Einträge gelöscht werden sollen
    • ohne Filter löscht alle Einträge
• Die erlaubten Abweichungen müssen pro Gerät von EPS bereitgestellt werden (möglicherweise braucht man verschiedene Werte über den gesamten Wertebereich eines Geräts)

Weitere Gedanke U. Krause

Bisher bin ich davon ausgegangen, dass sich die Soll-/Ist-Abweichung eines
Netzgerätes aus einem konstanten Anteil (die Ungenauigkeiten von DAC und ADC
beinhaltet, vielleicht aber noch andere Dinge) und einem Anteil, der
proportional ist zum aktuellen Sollwert.

Also etwa:
Error = C + A*SettingValue
wobei der konstante Anteil irgendwas ist wie 0,001*Maximalwert oder was auch
immer - auf jeden Fall konstant.

Wenn man sich Spezifikationen von (Labor-) Netzgeräten ansieht, wird immer nur
ein absoluter Fehler angegeben - die Angabe eines Fehlers, der proportional
zum aktuellen Einstellwert ist, habe ich nirgendwo gesehen. Spielt ein
relativer Fehler im realen Leben keine Rolle?

Um da weiter zu kommen, sollten die Netzgeräte-Leute gefragt werden, wie sich
der Fehler beschreiben lässt. Ohnehin müssen sie sagen, wie groß der Fehler
sein kann.


Aufgetretene Soll-/Ist-Abweichungen per Property rücklesbar?
Sollten wir von Anfang an anbieten - das wird man haben wollen.

Ich sehe zwei Möglichkeiten:
- In die Status-Property aufnehmen
Der Eintrag ist dann bei vielen Geräten immer leer (z.B. bei Strahldiagnose)
Achtung: Status ist ein eigener Typ, der überall verwendet wird
eigene Property
daran denken: es könnte weitere Chain- oder Beam-Process-spezifische
Informationen / Fehlerzustände geben, die in einer solchen Property
gut aufgehoben wären
Wie soll die Property dann heißen?
MultiplexingStatus ?
MuxStatus ?


Reset der Soll-/Ist-Abweichungen:
Auch hier zwei Möglichkeiten:
- über die Reset-Property
dann muss mitgeschickt werden, was zu resetten ist
- zusätzliche optionale value-Items?
- ein optionales Filter?
Achtung: ResetProperty ist ein eigener Typ, der überall verwendet wird
- eine eigene Property
auch hier berücksichtigen, dass es mal nötig werden könnte,
weitere Infos zu resetten
Name?
MuxReset ?


Beim Stichwort 'weitere Infos' denke ich etwa an Error-Messages. Auch da
könnte es sinnvoll sein, sich die letzten aufzuheben - pro Chain oder pro
Beam-Prozess. Und über einen Property lesbar machen. Und natürlich will man
die dann auch einzeln resetten können.

Im bisherigen Kontrollsystem hatten wir mal beim Gerätemodell MX einen
'dynamischen Status' eingeführt: Property DSTATUS. Ein Bit pro virtuellem
Beschleuniger. Zeigt irgendwie an, dass in dem jeweiligen virtuellen
Beschleuniger etwas nicht OK ist. Leider habe ich keinen Magneten gefuden, der
gerade eingeschaltet ist, kann also nicht sehen, was der gerade so anzeigt.


Nun muss man heute nicht alles vorsehen, was einem vielleicht mal einfallen
könnte. Ich bin aber dafür, z.B. Namen von Properties nicht zu spezifisch zu
wählen. Dann kann man sie später immer mal erweitern, wenn Bedarf besteht.

Bemerkung Alex Schwinn:

Die Property/Value-item API dazu sollte, denke ich, mit in die https://git.acc.gsi.de/schwinn/daq_api

Denn auch für die Digitizer ist Soll/Istwert vergelich vorgesehen.

-- MatthiasWiebel - 12 Aug 2020