DeviceControlApp Info: On-call duty / Rufbereitschaft

Note: 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/sd/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

resp.
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.
view
  • 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: Only concerning 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 (https://git.acc.gsi.de/fcc-applications/common-config/src/branch/pro/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

3.4.1 Typical scenarios

  • (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
      join DEVICE_TYPE_VERSIONS dtv on d.DEVICE_TYPE_VERSION_ID = dtv.DEVICE_TYPE_VERSION_ID
      join DEVICE_TYPES dt on dt.DEVICE_TYPE_ID = dtv.DEVICE_TYPE_ID
      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 pdex bzw. 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.
  • Falsche SCU im Statusfenster aufgeführt: Device Control zeigt schlicht die SCU-Informationen an, die LSA bereitstellt.
    Typische Gründe dafür, dass die von LSA gelieferten Daten nicht die gewünschten sind:
    • A. Fehlender Server-Cache-Refresh am LSA-Server nach LSA-Geräteimport (selten).
    • B. Es wurde noch kein LSA-Import durchgeführt, nachdem das Gerät in der FESA DB umgezogen wurde. (D.h. nach dem Umzug wurde dem LSA-Team vermutlich nicht Bescheid gesagt).
    • C. Das Gerät wurde nur physikalisch, aber nicht in der FESA DB umgezogen. (Abgleich pdex vs. Device Control: Wenn auch hier die falsche SCU steht, sind die Daten in der FESA DB auch (noch?) nicht richtig.)
    • Lösung: Korrektes Deployment in FESA DB durch verantwortlichen FESA-Entwickler. LSA-Geräteimport durch LSA-Team. Falls nicht vom LSA-Team mit erledigt: LSA-Server-Cache refreshen (via Knopf im ParamModi).

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 https://asl157.acc.gsi.de/middleware-config/v1/configuration/[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.

SlitWidgetEventTriggered-FESA.png

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 (DevAcc, FESA)

The valve classes are shown in the table at the top. For DeviceAccess, we have fast-closing valvesand 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.There is a button to switch between measuring and moving.

In contrast to DeviceAccess valve devices, the functionality for measuring pressure and moving valves has been split into two different FESA classes:
  • gauges (get pressure measurement data)
  • valve (open/close the valve)
All valve devices are shown in the table at the top.

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: r21 - 11 Jan 2024, MichaelKelnhofer
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