Handling of Command execution

Common command property execution

Command properties are used to invoke an action on a device (e.g. Init, Reset, PowerOn /Off, Drive). Put simply, at frontend level a command is executed by two levels:

1. Server-level: Acceptance of command request and launch an action
2. Action-level: command execution

Command requests are forwarded from DCL via JAPC. Reversely, feedback from JAPC is only communicated in case of a command rejection and reversed to DCL including feedback for the request.
Following proceeding for the communication procedure between client and frontend controller for command execution via JAPC are possible:

The communication procedure depends on the frontend type (comment of Peter Kainberger):

• Devacc: beauftragt die Server-Ebene (USR) eine Realtime-Action (EQM auf SE-Ebene) und wartet auf den Abschluss des Autrags (oder timeout).
• FESA (e.g. PowerSupply): In PowerSupply unter FESA beauftragt die Server-Action eine Rt-Action mit der Durchführung des Vorgangs und ist damit schon fertig und wartet nicht auf das Ende der Auftragsdurchführung. D.h. der Auftraggeber bekommt eine Rückmeldung, wenn der Auftrag weitergereicht wurde, das eigentliche Auftragsende bekommt niemand mit. Da könnte man aber vielleicht noch was nachrüsten.

Hence a result (confirmation/exception) should be concern to two different points in time:

• command request (accepted/rejected)
• command execution (successful/failed)

V.Rapp: Feedback by JAPC in case of a successful execution is not foreseen. It is assumed that either all went well or an exception is thrown!

Common command restrictions

There are some restrictions on the frontend level (comment of Dominic Day): Ein FESA Set kann entweder ein Befehl sofort im Set Action erledigen, oder fuer Befehle mit lange Laufzeit einen RT Action abrufen. Ein Set Action darf nicht lange warten - es gibt einen festen Limit von 10 Sekunden, danach wirft das Middleware einen Timeout Exception. Wenn einen Set Action laenger als 10 Sekunden läuft, kann FESA keine weitere Rückmeldung zum Client geben.
Die Rückmeldung vom Set-Action ist entweder OK oder einen Exception. Fuer mehr Information muss der Client einen Status Property lesen oder subskribieren, der am ende des Antrags notified wird.
In sum there are different points of time when the user (= initiator of command) should be informed.

Power switching

Specially the durance of the power switching procedure is very different. In particular some devices needs a time range up to some seconds (e.g.Maximum execution periods) or even some minutes (SIS18 h=2 cavities). Generally a power switch command has to be confirmed.

Command communication result

The use case predetermines which result type (command acceptance or command execution) is required for command execution in the application. Some use cases require the execution command (e.g. DeviceControl: "Drive"-command for pneumatic actuators: is time monitored). For other use cases it is enough to confirm the command acceptance at Frontend level. E.g. the IonSource application defined some maximum execution periods. In any case: Is it correct to say that the command result depends on the device and not on the command (e.g. the pneumatic actuators have different maximum driving execution periods)? The following items should be considered:

• concrete use cases
• should the command execution be handled completely by the DCL?
  • the user has to know if the result means a command acceptance or command execution result
  • some additional requests have to be invoked (e.g. status subscription for powerOn/Off. Perhaps another status subscription is already running by request of )
• if not, should the application decide finally how to hanlde command executions?
  • if this is device dependant this would have to be done in every application (s.a. DCL motivation arguments)
  • should the application invoke additional requests (e.g. status subscription for powerOn/Off)

Command communication handling depends on the use case. The complexity of device command varies according to the command property, e.g. (classification in SH's estimation):

• Reset, Init (normally low level)
• PowerOn /Off (moderate level)
• Drive (high complexity)

If there is no possibility to get the command execution result directly the device status details (i.e. reading the status property) have to be provided additionally. So it has to be evaluated which functionalities should be part of the DCL and what has to be handled by the application (command request initiator) in consideration of the DCL motivation arguments.

Protokoll Meeting 2020-08-05

IQ Fortran Analyse

Tabelle aus dem Wiki https://www-acc.gsi.de/wiki/Applications/Intern/IonSourceApplicationExecution ist auch im Code wiederzufinden in command.for

https://www-acc.gsi.de/viewvc/view/opera/trunk/op-aps/iq-co/main/src/command_button.for?revision=1&view=markup
https://www-acc.gsi.de/viewvc/view/opera/trunk/op-aps/iq-co/lib/src/com_command.f?revision=1&view=markup
https://www-acc.gsi.de/viewvc/view/opera/trunk/op-aps/iq-co/lib/src/command.for?revision=25&view=markup
https://www-acc.gsi.de/viewvc/view/opera/trunk/op-aps/iq-co/main/src/check_command.for?revision=1&view=markup
https://www-acc.gsi.de/viewvc/view/opera/trunk/op-aps/iq-co/lib/src/ufc.for?revision=1&view=markup#l584

https://www-acc.gsi.de/viewvc/view/opera/trunk/op-aps/iq-co/lib/src/qu_values.uih?revision=29&view=markup#l339

Grober Ablauf:
Absenden:

Command Button -> Command | Cmd[st_ein (cmd index)] -> UFC$W... -> UFC$Access -> UFC_EquipmentAccess

Ausführung Prüfen:

Check Command | Cmd[st_ein (cmd index)] -> Staus_Command / UFC$W... 'POWER'

Offene Fragen bzgl. Geräteverhalten bei Commands

siehe Questions about device command behaviour

-- SigridHeymell - 04 Aug 2020