DeviceControlApp Info: On-call duty / Rufbereitschaft

Annotations to the icons and colors of device status can be found in Status-Guideline.

3.1 Tool To Access To Devices:

(If DeviceControl is connected to the frontend controller, FESA devices and DeviceAccess devices can be distinguished by the status format in status dialog: From Detailed status Bit 8 the status texts have grey background.) The tools can be used for readout, but also for setting. At the latter you have to use the write command instead of read command.

3.1.1 FESA-Explorer (FESA devices)

To use the FESA Explorer proceed as follows:
  1. use script "fesa-device-info -p devicename "
    You'll get a table with FESA info of the device. You need the info on column "Deploy-Unit.FEC"
  2. call the FESA-Explorer: /common/usr/lobi/bin/fex &. (GUI will open)
  3. select pro environment: dropdown-box on top
  4. press icon leftmost ot load model from disk and look for the zip-file. The name is that of the content in the table of the FESA device info in 1.
  5. select the zip-file and confirm with open.
  6. "Device selection" (upper left): all devices being controlled by the selected FEC are visible
  7. select the device by double click
  8. "Cycle selection" (middle left): Select the context required for device access. Use "any" (default) for non-multiplexed, otherwise select the required context details for multiplexed properties.

    Attention: if you change the context, please remember to confirm by click on button "Change" (middle top)

  9. "Property selection" (bottom left): all properties defined for the selected device are visible. Following types rendered by various icons:
    • Command properties (executing has to be confirmed)
    • Setting properties
    • Acquisiton properties (Get/Set/Subscription)
Attention: Remember to change the conext if you look for multiplexed (e.g. Acquisition) and non-multiplexed (e.g. Status) properties.
  • Configuration Select property by double click. "Fields"-view (middle top) with all defined properties and the respective values (if exist) opens. Everything else should be obvious.

3.1.2 Equipstate (start by launcher)

Proceed as follows:
  • select context or accelerator zone, device group, device, and finally the property you want to read/write
  • : Attention: Execute readout request per property before a write request.

EquipState uses JAPC framework, FESA-Explorer does not!

All FESA devices use property Status and Power(if necessary).

Specific FESA devices using setting properties by DeviceControl:
  • MotorClass (Steppermotor):
    • Setting (input: numerical)
    • MoveToPosition (input: named position)
    • ToEndPosition (input: 0 = Outer end position, 1 = inner end position)
  • PneuDrive2018 (Pneumatic drive):
    • SettingMode
    • Setting

3.1.3 pdex

Path to pdex: /common/usr/cscofe/bin/pdex

All DeviceAccess devices use property INFOSTAT (status) and POWER (if necessary).
  • infostat (no selection of virtacc required)
  • power (no selection of virtacc required)

As reference for reading current device' values use
pdex GS12MU3I -d

pdex GS12MU3I a

alert In case of DeviceAccess devices the "STATUS"-property (directly from HW) calling from the prophelper is used here. This status info can differ from that which is used by DeviceControl (INFOSTAT: from FEC)!

3.2 Interesting Code (trunk-version)

model.domain (= JAPC-interface of (FESA) devices]: Devices are roughly structured by (FESA)device types (e.g. PneumaticActuator, exception: DevCtrlMagnJAPC contains several PowerSupplies, e.g. Bumper, Electrostatic septum, etc.). The name of device type should be intuitive (e.g. DevCtrlChopperJapc). :
  • superclass (of device classes): AbstractJAPCDevice: all common methods and definitions (AbstractJAPCDeviceDefinitions) for devices controlled by DeviceControl application
  • deviceAccessControl (DeviceAccess classes) are always nested in the particular "FESA" device class, (.i.e. DevCtrlSlitJapc object generates SlitCollimatorDeviceAccessControl object and should not be used outside these device classes).
  • DevCtrlJapcApi: JAPC-interface in DeviceControl
  • !LsaDeviceWrapper: (DeviceControl-)classification of (LSA-)device.
  • Steppermotor/SlitWidget: SlitWidgetDialog

3.3 Using the PictoView

  • use the filters to reduce the visible picto buttons (e.g. click "Keine Icons auswählen" and click then the devicetype filter of pneumatic actuators (if currently existing))
  • The output "x von y Geräten gewählt": y denotes the number of available devices (i.e. the devices having already responded on subscription. Therefore y can be updated.)
  • Each button in the chain navigator line represents a device being controlled by ACO. (Nearly) each device is characterized by a pictogram icon to facilitate the identification of device. So every drivable device (i.e. gate valves, pneumatic actuators, and steppermotors) do have a fittingly pictogram icon.
    ATTENTION (concerning only DeviceAccess devices): If there is a (drivable!) device button without pictogram button no status type is defined. Instead, only common status details and no current beamline position will be considered. Remedy: An entry in device-control-app-OperdbInfo.csv ( has to be generated. If no specific details are known they can be copied by an equivalent device entry in this file!

3.4 What to do

  • (After selecting another pattern:) PictoLine area (bottom area) invisible, although table area is visible and "Geräteinformationen werden geladen ..." not to be seen any longer: Click Button "Keine Icons wählen" and then "Alle Icons auswählen".
  • Device is not visible in AppApplicationDeviceControl:
    1. check if device is known (Frontend):
    2. if device is known by Frontend, check if device is known in LSA and an "actual" device (e.g. by sqldeveloper)
      select d.DEVICE_NAME, dt.DEVICE_TYPE_NAME from DEVICES d
      where d.DEVICE_NAME like 'GTH2DI2SP%' and dt.LOGICAL_ACTUAL_BEAM like 'A%
    3. if device is known by LSA, check if (LSA-)device type is known
      1. get device type
      2. LsaDeviceWrapper: check in checkDevice() resp. checkDeviceAccessTypes(), if devicetype is supported by AppApplicationDeviceControl
  • Device status not updated:
    • if possible verify the device status by
      • FESA: pdex
      • DeviceAccess: DeviceControl uses the INFOSTAT_-property for the device status. So compare the info of _STATUS (rstatus) and of INFOSTAT (rinfostat) in prophelper. IF INFOSTAT-status and DeviceControl differ from each other this might indicate to an issue within the application, differences between both status bits within the prophelper means an inconsistency between FEC and HW.
    • select device PictoButton and click "Status": Current status timestamp is shown (Hint: at least when opening the status dialog the timestamp should be the most current, received by DeviceControl. Until now it has not been checked, if timestamp is always updated, so performance issues cannot be suspended then. It can definitely take a long time (ca 30 sec) to update the timestamp!)
  • Driving job is hanging (i.e. rendering of throbber icon table view is not stopped). Select another context and reselect then the previously selected context (to cancel the request). If this does not work (then it is a bug I have to fix) restart DeviceControl.
  • SlitWidget: driving impossible: drive actuator (DeviceAccess, FESA see next item)/gate/steppermotor/slit devices by alternative tools (prophelper (DeviceAccess), EquipState (FESA) by using setting properties described above.
  • SlitWidget:
    • Drive button is disabled after having sent a moving command: close and reopen the slit widget dialog.
  • Antriebe/Schrittmotor (DevAcc): Position (Innere/Äußere Endlage) nicht bekannt. Im Statusdialog überprüfen, ob das Gerät der Status mehr als 8 Detailed-Statusbits besitzt. Wenn nicht (ist bisher in einigen Fällen passiert!), wurde der zugehörige Statustyp nicht an die Service-Gruppe (Susi) übermittelt. Statt dessen wird der Default-Status Typ verwendet. In jedem Fall kann der Status (und damit die Position) über pdexbzw. den prophelper ermittelt werden. Dazu kann der Status (z.B. pdex -d GTS1VB4FP), bei den Schrittmotoren zusätzlich die genaue Position über rposits(Soll-Position) und rpositi(Ist-Position)abgefragt werden. Die Statusbits sind hier beschrieben, so dass eine Interpretation des Status möglich ist.
  • GHTYVV1T (im Pattern vom ESR zum Cryring) in der Ventilzeile der Tabelle nicht sichtbar: DeviceControl unterstützt eigentlich keine kombinierte (d.h. FESA- und DevAcc-) Ventilsteuerung innerhalb einer Chain. Es ist beabsichtigt, die DevAcc-Ventile im SIS18 und in der HEST auf absehbare Zeit durch FESA-Steuerungen zu ersetzen. Da es aber aktuell vom ESR zum Cryring beide Ventiltypen verwendet werden, gibt es beim DeviceControl aktuell (ab Version 16.0.16) ein Workaround: Für den Fall einer kombinierten Ventilsteuerung werden nur die Ventile eines Typs (FESA oder DevAcc) dargestellt. Damit sind z.B. bei Patterns vom ESR u.U. zunächst nur die DevAcc-Ventile sichtbar (GHTYVV1T mit dem zugehörigen Messgerät GHTYVM1G befindet sich ebenfalls in dieser Chain, werden aber als FESA-Geräte nicht zusammen mit den DevAcc-Ventilen dargestellt). Durch Rechtsklick auf die beiden Ventilgerätespalten (die ersten beiden Zeilen der Tabelle) wird ein Popup geöffnet, der einen Wechsel zwischen beiden Ventiltypen ermöglicht.
    • ALERT! Falls bei DevAcc-Ventilen über das DropDown die Messfunktion ausgewählt wurde , muss diese nach erneutem Wechsel wieder ausgewählt werden!
    • Die Version 16.0.16 ist zwar bereits ausgerollt, aber noch nicht mit "current" verlinkt, da die Version erst noch beim HKR erläutert werden muss!
    • Alternative zum Workaround: Grundsätzlich kann ein FESA-Ventil über den FESA-Explorer bedient werden: z.Bsp.:
      • GHTYVV1T (VALVE): Öffnen/Schließen per Setting-Property
      • GHTYVM1G (GAUGE): Druckwertauslese per Acquisition-Property

3.5 Error messages

  • "XML for ...xml could not be found": can be ignored (minimum version of equipment model is not available)
  • "Ungültiger Prozesskey":
    • FESA device: Process key of device and of fair-selector do not agree
    • DevAcc device: Sequence ID of device and fair-selector sequence ID do not agree
  • "The field 'acqDataArray' has no data for the cycle selector ... (no set was done before calling get)..." (Status- resp. ValueWidget) No data supply had been done until now for the device.
  • GS00ZGT unsupported device type: TGX: latestVersion=DeviceTypeVersion[deviceType=TGX, versionNumber=4.0, implementation=DEVACC] can be ignored (no need of device in DeviceControl)
  • GS09DT_S unsupported device type: ACCT: latestVersion=DeviceTypeVersion[deviceType=ACCT, versionNumber=0.1, implementation=FESA3] can be ignored ((at least currently) no need of device in DeviceControl)

3.6 HowTo

  • check, if device is FESA or DeviceAccess:
    • search device in FESA tool (e.g. FESA explorer) or DeviceAccess tool (e.g. prophelper) or[deviceName]
    • click on "Status"-Button: Status dialog opens. If detailed status texts are to be seen: German texts = DeviceAcces, Englisch texts = FESA. Besides FESA devices have detailed infos to module status.
  • driving steppermotor/slit device by slit widget (only horizontal or vertical axis): ---+++ 3.7. What's new

3.7.1 Eventtriggered Steppermotor Systems (Single motor, FESA)

Schrittmotorwidget für eventgetriggerte Schrittmotoren (FESA). Diese (FESA-)Schrittmotoren werden z.Zt. aussschließlich am Cryring verwendet. Das zugehörige Schrittmotor-Widget im DeviceControl wird geöffnet durch Anwahl auf ein entsprechendes Gerät in der Tabellenzeile (Schlitz/Scraper). Um event-getriggerde Fahraufträge durchführen zu können, mus der Schrittmotor entsprechend konfiguriert sein.


Zusätzlich zum bereits verwendeten (durch den User veranlassten) manuellen Fahren werden die Informationen zum event-getriggerten Fahren in einer Tabelle dargestellt. Für jeden Beamprozess, für den ein eventgetriggerter Fahrauftrag aktiviert ist, wird die Sollposition und die aktuelle Position dargestellt.

Java-Klassen: Folgende Punkte sind zu beachten:
  • Wenn das Widget keine Tabelle enthält, wurde der Schrittmotor nicht entsprechend konfiguriert (wird von der Strahldiagnose erledigt.)
  • Fehlen Angaben in der Spalte "BP-Purpose", so waren zum Zeitpunkt der Anwahl des Schrittmotor-Widgets keine Events für einen Beamprozess aktiviert. (FESA)
  • Die Angaben sind chronologisch sortiert!
  • Falls bei der Datenversorgung für die eventgetriggerten Schrittmotoren Änderungen bei bereits geöffnetem Widget vorgenommen wurden, ggf. das Widget schließen und erneut öffnen. (Auf jeden Fall, wenn Aufträge bei Beamprozessen definiert wurden, die bis dahin nicht berücksichtigt wurden.)

3.7.2 Valve Control Devices (FESA)

In contrast to DeviceAccess valve devices there are two different FESA classes:
  • gauges (get pressure measurement data)
  • valve (open/close the valve)
These classes are shown in the table in the first two rows instead of the first two rows useing DeviceAccess devices (Fast closing gate valves, gate valves). The fast closing gate valves are not movable by the HKR, only providing pressure data. Gate valves are able to move and also provide pressure data. It is not intended to mix FESA and DeviceAccess devices. Currently only the current value is read by clicking on the "Update" button.

ALERT! Valve devices are moved (like pneumatic actuators) immediately by left-clicking on the device icon in table area. Only if the device is not ready to move (i.e. undefined position) an actuator dialog is opened.

info To get the single pressure measurement value left-click on the gauge device icon in the table area. The info in the gauge devicetype column provides the value for all (sorted) gauges of the chain.

TIP In case of an inconsistency of a dialog content it should help to reopen the dialog!
-- SigridHeymell - 03 Feb 2021
Topic revision: r14 - 11 Feb 2022, SigridHeymell
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