Details
-
Type:
Story
-
Status: Invalid
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ts_main_telescope
-
Labels:
-
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
- relates to
-
DM-31111 MTHexapod reports failure in state transition when it is actually succeeding
- Done
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.