When I got here this morning, Nutsinee was reporting that the ISC_LOCK Guardian would get stuck in a few places. Here is what I found and my solutions to them:

ENGAGE_ASC_PART2

Issue: If this state is requested it would get stuck due to self.skipflag returning True. The next time that the run() method would execute, it would jump to the next condition, which would not allow for further movement in the state path when requested.

Solution: I added an extra condition to check if the self.skipflag is True, then return True. This allows for foward movement after a request is put in, while still looking for what it needs to.

ENGAGE_ASC_PART3

Issue: Not all of the logic would run from the run() method, and would get stuck in this state. There are several steps in this method that wait for a timer, do something, then set another timer and wait, before doing more. Problem was that while it would wait for the timer to run out, it would still run through the first step of the logic which included setting the timer. So the timer was set again and again.

Solution: Added a checkpoint flag (self.cp1) so the timer is not set and reset.

ENGAGE_ASC_PART(all)

Issue: No lockloss check decorator in its run() methods!!! Very dangerous, especially since these are requestable states.

Solution: Added the decorator

I hope we are not pushing the commissioners too hard and they are getting sleep...

I have tested this and it has gone through a few times, but now I'm losing lock when it get to DC_READOUT. On to the next mystery!