State Chop_Period_5 {
> Laser Command Scan Start
Hold Until (t_z4 && (LVstat_z4 & 1));
Hold Until (t_z4 && !(LVstat_z4 & 1) && !scanning);
Depending on (Full_Shutdown) { Validate Chop_Idle; }
> Laser Command Chop Mode Begin
Hold Until (SWStat == SWS_TIMEWARP) or 5:00;
Validate Chop_Period_5;
}
Problem arises because the Depending statement is evaluated after the > Laser Command Chop Mode Begin as part of the same substate as the following Hold statement. Putting a delay before the laser command resolves the problem here, but what is the real solution?
Since the Depending statement is an untimed-command, it could theoretically run continuously in the time between the preceding and following timed commands. In this case, there is no time allotted, so it would also be reasonable to conclude the Depending statement will never get evaluated (and hence the construct is a user error).
However, in a case like this where there is no time allotted, it might be perfectly reasonable to treat the Depending statement as a timed command, with its own substate preceding the laser command. That would achieve the (perhaps mistaken) expectation of the programmer, incurring a one second delay like each of the preceding Hold statements.
Suppose there was more than a one second delay before the laser command? In that case, a reasonable interpretation would be to evaluate the Full_Shutdown condition throughout that delay. The current encoding of that Depending statement is:
Problem arises because the Depending statement is evaluated after the
> Laser Command Chop Mode Beginas part of the same substate as the followingHoldstatement. Putting a delay before the laser command resolves the problem here, but what is the real solution?Since the Depending statement is an untimed-command, it could theoretically run continuously in the time between the preceding and following timed commands. In this case, there is no time allotted, so it would also be reasonable to conclude the Depending statement will never get evaluated (and hence the construct is a user error).
However, in a case like this where there is no time allotted, it might be perfectly reasonable to treat the Depending statement as a timed command, with its own substate preceding the laser command. That would achieve the (perhaps mistaken) expectation of the programmer, incurring a one second delay like each of the preceding Hold statements.
Suppose there was more than a one second delay before the laser command? In that case, a reasonable interpretation would be to evaluate the Full_Shutdown condition throughout that delay. The current encoding of that Depending statement is:
So the statement is only evaluated at the beginning of the delay period. Perhaps also eliminating the
oncequalifier would also be appropriate.