Devicetype Specific Characteristics

info 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"))
    • Legacy (S.Jülicher): In https://git.acc.gsi.de/sv-commons/conditions-compiler/src/branch/master/conditions-compiler-tools/conditions-legacy-importer/import_files gibt es 2 Unterverzeichnisse, eines für Frontend. Da steht dann im Verzeichnis import_fe in der Datei facilities für jedes Gerätemodell die Facilitienummer, und in der dazugehörenden Datei die Messagenummern sowie die Texte. Für DS demnach die Datei 1061.
  • PowerSupply:
    • FESA: no initial update. When starting the status subscription at first the status has to be get once. Then the status subscription starts.
    • Miscellanous info
  • Cavities:
    • non-Ferrit cavities consist of
      • 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."
          • cf. comment in DCL-185 Schrittmotoren: ...
      • Eventtriggered Steppermotor
        • 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)
  • Driven devices
    • Detector system (cf. specific driven devices)
      • 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)

Device Specific Characteristics

Persistent Info used by DeviceControl
  • filter feature
    • ring devices (assigned to accelerator)
  • power switching
    • ring RF cavities (only non-ferrit cavities use power standby. (Do only non-ferrit devices consist of two HW components?)
  • power supplies changing between current and field set values (used in S/I magnet value comparison dialog)

This topic: Applications > WebHome > AppGuidelinesMain > AppGuidelinesGuiMain > CharacteristicsOfDevices
Topic revision: 23 Oct 2023, AnnekeWalter
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback