Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-31075

Camera hexapod state machine does not reject enable command in enabledState

    XMLWordPrintable

    Details

    • Team:
      Telescope and Site
    • Urgent?:
      No

      Description

      When in enabledState sending the enabled command the state machine makes a soft state transition and executes the enabled state entrance behavior again.

      The entrance behavior includes reloading the configuration.

      Both should not happen.

      – The state machine should reject enable command when in enable state.

      – The state machine should only load a configuration when transitioning from standbyState to disabledState.

      Code example:

      sending first

      await salobj.set_summary_state(r.mthex, salobj.State.ENABLED, settingsToApply="default")

      and then

      await salobj.set_summary_state(r.mthex, salobj.State.ENABLED) 

      leads to a situation where the setCompensationMode command does not work. While sending only the first command leads to the situation where setCompensationMode works.

        Attachments

          Issue Links

            Activity

            Hide
            rowen Russell Owen added a comment - - edited

            I tried to duplicate this using the commander and found that the MTHexapod CSC does reject the enabled command when in the enabled state:

            $ command_mthexapod.py 1
            current_tai uses current_tai_from_utc; clock_gettime(CLOCK_TAI) is off by 37.0 seconds
            Waiting for MTHexapod:1 to start.
            1626188905.128: authList: authorizedUsers=, nonAuthorizedCSCs=
            1626188905.126: commandableByDDS: state=True
            1626188905.118: compensationMode: enabled=False
            1626188905.123: connected: command=True, telemetry=True
            1626188905.125: controllerState: controllerState=3, offlineSubstate=1, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0]
            1626188905.129: simulationMode: mode=1
            1626188905.129: softwareVersions: salVersion=6.0.0, xmlVersion=9.1.1, openSpliceVersion=?, cscVersion=?, subsystemVersions=
            1626188905.125: summaryState: summaryState=<State.OFFLINE: 4>
             
            enterControl
             
            1626188960.907: summaryState: summaryState=<State.STANDBY: 5>
            1626188960.908: controllerState: controllerState=0, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0]
            Finished command enterControl
             
            start
             
            1626188962.772: settingVersions: recommendedSettingsVersion=heads/develop-0-g9b8e039, recommendedSettingsLabels=default, settingsUrl=file:///home/saluser/tsrepos/ts_config_mttcs/MTHexapod/v1
            1626188962.776: settingsApplied: settingsVersion=:heads/develop-0-g9b8e039, otherSettingsEvents=
            1626188962.776: appliedSettingsMatchStart: appliedSettingsMatchStartIsTrue=True
            1626188962.777: summaryState: summaryState=<State.DISABLED: 1>
            1626188962.777: controllerState: controllerState=1, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0]
            Finished command start
             
            enable
             
            1626188964.921: summaryState: summaryState=<State.ENABLED: 2>
            1626188964.921: controllerState: controllerState=2, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0]
            Finished command enable
             
            enable
             
            msg='Command failed', ackcmd=(ackcmd private_seqNum=756775848, ack=<SalRetCode.CMD_FAILED: -302>, error=1, result='Failed: Rejected: initial state is <State.ENABLED: 2> instead of <State.DISABLED: 1>')
            

            I can't see how the "enable" command can possibly modify configuration because that step only occurs when executing the start command to transition from standby to disabled.

            Is this reproducible? Can you give me more detail as to how to reliably produce it?

            It would also help to have a log showing logMessage, controllerState and summaryState events while you make this problem happen.

            Show
            rowen Russell Owen added a comment - - edited I tried to duplicate this using the commander and found that the MTHexapod CSC does reject the enabled command when in the enabled state: $ command_mthexapod.py 1 current_tai uses current_tai_from_utc; clock_gettime(CLOCK_TAI) is off by 37.0 seconds Waiting for MTHexapod:1 to start. 1626188905.128: authList: authorizedUsers=, nonAuthorizedCSCs= 1626188905.126: commandableByDDS: state=True 1626188905.118: compensationMode: enabled=False 1626188905.123: connected: command=True, telemetry=True 1626188905.125: controllerState: controllerState=3, offlineSubstate=1, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0] 1626188905.129: simulationMode: mode=1 1626188905.129: softwareVersions: salVersion=6.0.0, xmlVersion=9.1.1, openSpliceVersion=?, cscVersion=?, subsystemVersions= 1626188905.125: summaryState: summaryState=<State.OFFLINE: 4>   enterControl   1626188960.907: summaryState: summaryState=<State.STANDBY: 5> 1626188960.908: controllerState: controllerState=0, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0] Finished command enterControl   start   1626188962.772: settingVersions: recommendedSettingsVersion=heads/develop-0-g9b8e039, recommendedSettingsLabels=default, settingsUrl=file:///home/saluser/tsrepos/ts_config_mttcs/MTHexapod/v1 1626188962.776: settingsApplied: settingsVersion=:heads/develop-0-g9b8e039, otherSettingsEvents= 1626188962.776: appliedSettingsMatchStart: appliedSettingsMatchStartIsTrue=True 1626188962.777: summaryState: summaryState=<State.DISABLED: 1> 1626188962.777: controllerState: controllerState=1, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0] Finished command start   enable   1626188964.921: summaryState: summaryState=<State.ENABLED: 2> 1626188964.921: controllerState: controllerState=2, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0] Finished command enable   enable   msg='Command failed', ackcmd=(ackcmd private_seqNum=756775848, ack=<SalRetCode.CMD_FAILED: -302>, error=1, result='Failed: Rejected: initial state is <State.ENABLED: 2> instead of <State.DISABLED: 1>') I can't see how the "enable" command can possibly modify configuration because that step only occurs when executing the start command to transition from standby to disabled. Is this reproducible? Can you give me more detail as to how to reliably produce it? It would also help to have a log showing logMessage, controllerState and summaryState events while you make this problem happen.
            Hide
            rowen Russell Owen added a comment - - edited

            I have attached a simple script that should show the problem, based on your description. However, it works perfectly for me. Please try to modify the script so it reliably reproduces the problem. (Note: it does not print the summaryState event because set_summary_state requires that the topic not have a callback function. Printing controllerState is probably good enough. Alternatives are to make a second remote or replace set_summary_state with the expected commands.)

            Here is the output that I see:

            $ python DM31075.py 
            enable with set_summary_state
            controllerState=<ControllerState.STANDBY: 0>, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0]
            controllerState=<ControllerState.DISABLED: 1>, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0]
            controllerState=<ControllerState.ENABLED: 2>, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0]
            enable again with enable
            the enable command was rejected, as expected
            go back to offline
            controllerState=<ControllerState.DISABLED: 1>, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0]
            controllerState=<ControllerState.STANDBY: 0>, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0]
            controllerState=<ControllerState.OFFLINE: 3>, offlineSubstate=1, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0]
            done
            

            Show
            rowen Russell Owen added a comment - - edited I have attached a simple script that should show the problem, based on your description. However, it works perfectly for me. Please try to modify the script so it reliably reproduces the problem. (Note: it does not print the summaryState event because set_summary_state requires that the topic not have a callback function. Printing controllerState is probably good enough. Alternatives are to make a second remote or replace set_summary_state with the expected commands.) Here is the output that I see: $ python DM31075.py enable with set_summary_state controllerState=<ControllerState.STANDBY: 0>, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0] controllerState=<ControllerState.DISABLED: 1>, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0] controllerState=<ControllerState.ENABLED: 2>, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0] enable again with enable the enable command was rejected, as expected go back to offline controllerState=<ControllerState.DISABLED: 1>, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0] controllerState=<ControllerState.STANDBY: 0>, offlineSubstate=0, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0] controllerState=<ControllerState.OFFLINE: 3>, offlineSubstate=1, enabledSubstate=0, applicationStatus=[1024, 0, 0, 0, 0, 0] done
            Hide
            rowen Russell Owen added a comment -

            I strongly suspect this was caused by DM-31111. If it reappears with ts_hexrotcomm v0.22.0 then reopen or create a new ticket.

            Show
            rowen Russell Owen added a comment - I strongly suspect this was caused by DM-31111 . If it reappears with ts_hexrotcomm v0.22.0 then reopen or create a new ticket.

              People

              Assignee:
              rowen Russell Owen
              Reporter:
              hdrass Holger Drass
              Watchers:
              Holger Drass, Russell Owen
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.