This doesn't seem like a fix to root cause - may not work if user clears alarm quickly. Suggest looking at valve driver where alarm 62 is detected/triggered and maybe zeroing positionOutOfRangeCounter (reset 1 sec persistence) if AC power is out. That way, when AC is restored, valves will have a whole second to get where they're supposed to be before alarm is triggered.
I know we've tended to only mention data that is static to this unit in the Input/Output sections, but I think we should also mentions important inputs from outside the unit (e.g. FPGA readings in this case).
Is this intended to be a terminal state? If so, add comment here noting that. If not, we need a way to exit this state and recover (handling here should look a lot like start state handler where we would act on a homing request which would take us to homing state).
Alarm descriptions and trigger conditions calls out "more than 4 minutes" and Instructions says, "nearly 5 minutes". is this intended to display this way?
The root cause is that abnormal AC power loss on the HD causes abnormal operating conditions and spurious errors. The valves return to position after the alarm is cleared, not when AC returns. The timer gives a ten-second window following removing the power fail signal and the alarm condition, where the alarm block is active. The original block used the alarms alone, we changed to the CPLD power loss detection - which returns with the return of AC. Clearing the alarms late means removing the block before the valves return to normal operation.
I think there are two approaches. We already have distributed failsafe that is entered on power fail, which we recover from after the alarm is cleared. 1. Create a pervasive state that affects every operating mode, allowing transitions to "safe" states during alarms, then back to the original operating state. The safe state would not register errors until after the transition back to normal operation. 2. Block errors until both AC is returned and the alarm is cleared when normal operation is restored.
The second approach is much simpler and addresses the root problem: odd control configurations resulting from having alarms with conflicting controls. In this case, the secondary alarms are spurious since they result from the valves dropping into a safe position, for instance, on the loss of AC. We also have a handful of other errors that occur under these conditions, fan speed, for instance, as well as valve positions,
Updated to do this. To me it seems counter intuitive. If the user opens door when UF or BP screen is showing, then Open door screen come up, user opens door and gets alarm. If they hit next, it shows flip dialyzer screen but still alarms if door opened.
