This includes also short notes that have been collected sometimes to be kept in mind.
Common devices:
FESA: Actually a subscription on change is sufficient, but when opening the status widget the timestamp is updated. So the subscription has to be periodically. (Ask PK: New subscription, additionally? But what is when the status subscription fails. How to handle DeviceAccess devices? I would prefer same subscription types used for FESA and DeviceAccess)
DeviceAccess (S.Jülicher):
Geräte mit einem "?" im Typ (Legacy-operdb) werden nicht bedient - (Beispiel: alle mit Typ "SLI?" (und Subtyp "APER"))
Verstärker (einschalten kann bis zu 9 min dauern, alle anderen PowerSwitch -Vorgänge sind wesentlich kürzer)
HF-Erzeugung
Einstellbare Werte für HF-Geräte: Amplitude, Phasenlage, Pulspause, Warmhaltepuls
nur einschalten, wenn unbedingt notwendig (sehr energieintensiv!)
ProfileGrid:
S.Jülicher: Geräte vom Typ DETE, Subtyp PGT sind Gitter zur Einzel-Teilchendiagnose. Für diese Geräte gibt es kein Gerätemodell, sie gehören in den Hoheitsbereich der Experimentatoren.
Actuators
non-multiplexed selector for moving (except: Event triggered stepper motors: multiplexed context for event-triggered moving.)
Subscription: on change or periodically?
Stepper motor:
FESA:
single motor or motor pair. Solveigh: Different FESA classes, but single motor includes the API for motor pair!?
solange Bewegung andauert, werden andere Kommandos abgewiesen!
Update-Rate
I.d.R. zwischen 4 (default) und 10 Hz
1 Hz, wenn Daten vom PMAC gelesen werden
DeviceAccess:
motor pair (DSK, DSKM) contains either two motor pairs or two single motors
only single motor (DS, DSM (Motor, controlled with uIOC )) is movable at once.
S. Jülicher:
"Kollimatoren: erwartet alle Komponenten auf dem selben PowerPc. Deshalb liefert die Status-Abfrage ggf. auch folgnde Fehlermeldung: "DS-E-KOLL_NOSUB, Die subdevices der Kollimatoren existieren nicht"
"Die Bedeutung der Messagenummer DS-E-ZUWEIT erschliesst sich mir eher nicht. Das Einzige das ich weiss - oder auch nicht - ist folgendes: beim relativen verfahren eines Schrittmotors (Property POSIREL) ist die Anzahl der erlaubten Schritte in meiner Erinnerung auf 200 begrenzt. Würde zumindest zu "200 Schritte" passen."
"Im Unilacbereich gibt es Schrittmotore, bei denen es geht. Das sind die neueren, die am Micro-IOC hängen (Cosylabkiste). Ist das gleiche Gerätemodell wie bei den alten Schrittmotoren, heißt aber DSM statt DS - für Paare entsprechend DSMK statt DSK. Ich meine aber, die sind generell etwas langsamer (entnehme ich einem Kommentar in meinem Sourcecode), da bin ich ber nicht 100% sicher. Die alten Schrittmotoren im Unilac hängen an einem SD-Micro. Und da kommt noch eines beim relativen Fahren bzw. bei der Property STEPS hinzu: Wenn man eine Distanz vorgibt, die eine geraden Anzahl von Schritten ergibt, dann macht der Motor immer einen Schritt weniger als vorgegeben. Bei einer einzelnen Positionierung ist das ja hinnehmbar, aber bei Wiederholungen summiert sich der Fehler. Deshalb kann man über mitgegebene Parameter beim Aufruf der Property ein Offset mitgeben. Das wechselt dann zwischen +1 und -1, womit dann der Fahrweg in der Summe wieder passt - trotzdem passt es oft nicht in meinem Emittanzprogramm."
non-multiplex selector for manual moving, otherwise event triggered moving
FESA: included in single motor FESA class
DeviceAccess: extra equipment model PPOS
Usecases:
G.Riehl:
Manuelles Fahren (eigentlich) nur in der Einstellungs/Experimentphase
evtl. noch „Nachjustieren im Normalbetrieb“ (von Experten)
Das Gerät selbst unterscheidet nicht zwischen manuellem und eventgesteuertem Fahren!
Eigentlich passt das StorageRingMode -Konzept und das von PPOS nicht zusammen. Probleme:
es ist nicht klar, wann das Fahren (manuell oder eventgesteuert) tatsächlich ausgeführt wird. Es kann sein, dass erst im nächsten Gap oder noch später gefahren werden kann. (Deshalb dürfen die Fahrbefehle nicht „zu dicht“ zusammenliegen, das ist aber im Ermessen von Datenversorgung und Experten, die das Programm bedienen)
wie weit liegen die Gaps auseinander? Die Beamprozesse können bis zu 45 (?) Sekunden lang sein. Wie ist da der Timer bei der SE zu setzen?
Der Timer muss dann eigentlich von DeviceControl übernommen werden zur Überwachung des Fahrbefehls. Ist das wegen der Dauer praktikabel?
bisher (ESR und CRYRING):
Usecase (ESR wie CRYRING):
Rein/Rausfahren (letzten Endes wurde ein Event pro Beschleuniger verschickt, und manuelle Eingabe „zu jederzeit“ ((!)so sah es zumindest aus))
Rausfahren, bevor der Strahl injeziert wurde, war aber nicht der Standardzyklus
zu Beginn von Hand an Position gefahren, dann nochmal Feineinstellung (Geräte sind zu langsam, um alles auf einmal zu fahren)
ESR: Events sind wichtig, wenn der Strahl kürzer ist (< 10 Minuten), sonst geht‘s manuell
CRYRING: hier ist es eher umgekehrt
Notes (P.Kainberger):
Wenn (im ESR oder sonst wo) keine Kommandoevents gespielt werden können, bleiben die alten Geräte stehen (die gehen offline, wenn innerhalb einer bestimmten Periode (?16 Sekunden) kein Status gelesen wurde. Und das wird per Kommandoevent gemacht)
Pneumatic actuator:
FESA:
additional „operation mode“: This is a BEA-specific mode that maintains the access of control. Has to be requested if necessary and has to be returned after each execution of command when access is no longer needed, e.g. after beamtime/when control is handed explicitly to device experts while looking for a problem/etc..
DeviceAccess:
executes the moving command only within the gap! (Issue: (Corba-)Response timeout must not have been exceeded. So the timeout value has to be well selected!?)
R.Boywitt: Die Geräte sind immer eingeschaltet und können nicht remote ausgeschaltet werden! Die Fahrzeit der pneumatischen Antriebe ist abhängig von der Konstruktion, dem Druck im Pressluftsystem und dem Wartungszustand. Feste Werte auf die mS kann man nicht bestimmen. Ein realistischer Wert wäre eine Wartezeit von ca. 4 S zuzulassen, bevor man einen Fehler ausgibt. Fragen zu den Fahrzeiten: Jürgen Wohlers oder Kersten Steiner stellen.
Valve:
FESA:
Valve: close/open valve
Gauge: measuring of pressure
DeviceAccess:
VVC: moving AND measuring
Distinction between "Ventil" and "Schnellschlußventil" (the latter is only movable, no measuring. Identified by (operdb-geraete)(typ, subtyp)
some devices are not part of the control system, e.g. (currently) fluorescent screen
devicename of detector system components are reconstructed by devicenames of other detector system components, because currently no persistent location provices this info. (e.g. devicename of ionisation chamber is built from drive devicename)
assignment steppermotor ↔ driven device:
FESA:
named positions
DeviceAccess:
position (one direct predecessor resp. successor of the other, ? Nomenclature)
assignment pneumatic actuator ↔ driven device:
position (one direct predecessor resp. successor of the other, Nomenclature)