This bugfix might be super important #621
Labels
No Label
OPS TODO
api change
breaking api change
bug
documentation
duplicate
feature
help wanted
invalid
question
wontfix
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: eive/eive-obsw#621
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "possible_bugfix_dual_lane_assy"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
NEEDS_RECOVERY
andcheck the recovery handling works as well.
this bugfix might be super importantto WIP: This bugfix might be super importantWIP: This bugfix might be super importantto This bugfix might be super important@ -185,3 +185,3 @@
triggerEvent(CANT_KEEP_MODE, mode, submode);
startTransition(mode, nextSubmode);
startTransition(targetMode, nextSubmode);
tryingOtherSide = true;
Small notice: the name "tryingOtherSide" is unclear to me. It seems to be more "tried other side" than "tryingOtherSide". Or "triedOtherSideBefore". At least in the check in line 184.
@ -207,2 +207,3 @@
customRecoveryStates = RecoveryCustomStates::POWER_SWITCHING_ON;
pwrStateMachine.start(targetMode, targetSubmode);
// Command power back on in any case.
pwrStateMachine.start(HasModesIF::MODE_ON, targetSubmode);
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