You are here: Foswiki>Applications Web>AppInfoMain>AppInfoDeviceInformation>AppInfoDeviceInformationDeviceCommunicationCommands>AppDevIQ2020DeviceCommunicationConceptOfHandlingCommandsQuestionsAboutDeviceCommandBehaviour (06 Dec 2022, SigridHeymell)Edit Attach
Meeting on 2022-11-01 (JF, SH, CH, BP, JP, AW): (moved AW's notes (DCL-237 Command handling))

  • We think it is probably not feasible to provide generic “command feedback” (that allows us to inform the caller about the successful or unsuccessful completion of the command) for all commands right now.
  • We would like to provide “command feedback” for certain commands, where it seems especially useful and is technically possible:
    • moving actuators: this is already provided by A-DCL, we will continue to add support for more devices there
    • Power command: Whether command was successful can be determined by checking status. While we cannot know if a Power state change was actually caused by “our” command, we can still provide reasonable feedback. => DCL-241: Provide power switching command...​
      • A simple API could just provide a CompletableFuture that completes when the command is successful or a timeout is reached.
      • A more sophisticated API could provide different states, e.g. COMMAND_SENT, COMMAND_EXECUTED. An implementation alternative that we already use in the A-DCL in a similar fashion would be: The command returns a simple CompletableFuture, and the caller can optionally specify a listener for receiving more fine-grained state updates.
    • Ideally, all implementations of “command feedback” should follow the same underlying API structure. E.g. all feedback should work with a simple CompletableFuture, or all feedback should be able to provide states.
  • We do not think we have a technical way (yet?) of determining when a Reset command has been executed. Therefore, we will not try to provide “command feedback” for Reset right now.
    • We should try to talk to the Frontend colleagues to think about ways to detect when Reset commands have been executed.
      • Ideas:
        • Could there be some kind of lastResetTimestamp or something similar?
        • A non-persistent property, e.g. dummyResetValue, that is automatically set to a specific dummy value when a Reset command is received, and loses it value after the Reset.
    • note We have added our ideas/request to the document with FESA questions to discuss in the Standardization Meeting.
  • About exception error messages:
    • We probably cannot influence the content of FESA/JAPC core exceptions, because they are defined and thrown by CERN.
    • For GSI developments, we should ask the Frontend colleagues to be as specific as reasonably possible to make it easy for users to find out what the underlying problem is. E.g. we would prefer a TIMING_DOES_NOT_MATCH_SETTINGS error over a very unspecific NO_DATA_AVAILABLE error.
    • ​note We have added this request to the document with FESA questions to discuss in the Standardization Meeting.
    • For now, we display exceptions as they come from the devices.
    • We must acknowledge that exception error messages may not necessarily be sufficient to determine the true error cause. In cases where users perform action interactively, it probably makes sense to allow them to see the associated device’s status. (We could either find a way to always include status nearby, or we assume that users always have access to a DeviceControl instance.)
  • About the error collection in the Status:
    • For now, we assume that in the general case, we do not have to evaluate error collections.
    • If we should handle error collections for certain devices (or device types), it is the responsibility of the Frontend group / the responsible developer to let us know that we have to do it, and how exactly.
      • Right now, that is the case only for certain actuators
        • Steppermotor (FESA class: Motor, developer: S. Matthies)
        • Valve (FESA class: Motor, developer: A. Schwinn)
      • ​​note We have documented those assumptions in the document with FESA questions to discuss in the Standardization Meeting.
  • We assume that, when we send a synchronous Set or Command to a device, and the call returns without exception, the device has “accepted” our command and will try to execute it (most likely asynchronously at some point in the future (RTAction).
    • alert: If we send an asynchronous Set or Command to a device with a ParameterValueListener as a callback, that listener is only called in the case of an exception (command not accepted). It is never called when the command has been accepted! (As far as we know - ​ )

-- SigridHeymell - 06 Dec 2022
Edit  | Attach | Print version | History: r2 < r1 | Backlinks | View wiki text | Edit wiki text | More topic actions
Topic revision: r2 - 06 Dec 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