This bugfix might be super important #621
@@ -205,7 +205,8 @@ bool DualLaneAssemblyBase::checkAndHandleRecovery() {
|
|||||||
opCode = pwrStateMachine.fsm();
|
opCode = pwrStateMachine.fsm();
|
||||||
if (opCode == OpCodes::TO_OFF_DONE or opCode == OpCodes::TIMEOUT_OCCURED) {
|
if (opCode == OpCodes::TO_OFF_DONE or opCode == OpCodes::TIMEOUT_OCCURED) {
|
||||||
customRecoveryStates = RecoveryCustomStates::POWER_SWITCHING_ON;
|
customRecoveryStates = RecoveryCustomStates::POWER_SWITCHING_ON;
|
||||||
pwrStateMachine.start(targetMode, targetSubmode);
|
// Command power back on in any case.
|
||||||
|
pwrStateMachine.start(HasModesIF::MODE_ON, targetSubmode);
|
||||||
gaisser marked this conversation as resolved
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
if (customRecoveryStates == POWER_SWITCHING_ON) {
|
if (customRecoveryStates == POWER_SWITCHING_ON) {
|
||||||
|
Reference in New Issue
Block a user
Is this working in combination with the call to
opCode = pwrStateMachine.fsm();
directly afterwards (line 213)? (I haven't checked the fsm() call, so this might be perfectly fine.)In line 215 (
customRecoveryState
will be set toRecoveryCustomStates::DONE;
if we entered the "if" in line 206 withOpCodes::TIMEOUT_OCCURED
, is this expected?Why shouldn't it work? This mechanism has always worked properly when
targetMode
is correct. The immediate fsm call will send the swtich commands, the replies take some time.Ok