Russell Owen added a comment - 13/Jul/21 3:17 PM - 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.

Russell Owen added a comment - 13/Jul/21 3:41 PM - 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

Russell Owen added a comment - 29/Sep/21 7:34 PM 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.