When using State Machine in LV for machine sequencing I have an issue. There are no issues on the State Machine coding but to reach that point I need to check for about 4 conditions :
1. Is A condition OK ?
2. If A is OK then is B condition OK ?
3. If B is OK then is C condition OK ?
4. If C is OK then is D condition OK ?
If D is OK then enter the State Machine code.
After the SM starts, if any of the conditions A-D fail, abort SM.
Right now condition A is checked in a case structure and in the TRUE state of this , all the other cases reside. The State Machine resides in the inner most TRUE case of condition D. The arrangement is working fine but somehow with so many case structure nesting , it does not seem to be very elegant.
If conditions A-D are from FP then an EVENT struct. could have been used but these are from digital inputs of the machine and not all DIO cards support Event triggers from DI.
Any other options to handle the conditions A-D without True/False cases ?
Solved! Go to Solution.
I don't understand all of your post but why don't you serialize your test (with error cluster)? With a SubVI by test and more, it's easiest to maintain...
Maybe you could use the "Formula node" to write your state machine conditions. It will problaby clean up some wire connections on your diagram.
I see no reason not to build the precondition checking into your state machine itself. In this case your state machine is always running, but it starts in some Idle case that listens for a start event. When it starts, it first cycles through the preconditions for A to D. If any of them fail, it displays a message and returns to Idle, otherwise it enters the first test state of the state machine.
When the test finishes, you don't abort the state machine, it simply reenters the Idle case.
I also see no reason as you've explained it why you can't check conditions A through D at the same time and simply And the boolean results, but maybe there's more to the story.
There are two issues that I want to point out :
1. Arranging T/F cases side by side serves no specific advantage as it is the same as I am doing now - but one inside the other.
2. The conditions A,B,C,D when they fail have to be handled by certain housekeeping functions ( wait for a pressure to decay, switch off solenoids x,y,z etc ) for the SM to abort safely. And as such they cannot be treated like just booleans or flags as somone had done with a "Select" function..
And just to eloborate, each of the state in the SM will have to update a cluster containing 16 boolean vaues that represent solenoids on the machine.
Yes building the preconditions into the SM is an idea. But as you rightly guessed there is more to it ! All the four conditions have the status as "Interrupts" - meaning even when the SM is stepping through its states, if ANY of the 4 conditions becomes false, then the SM has to halt and outputs restored to a safe state.
In that case the four conditions can be checked individually in four different states. If any of them fails, you go immediately to a Restore Outputs/Abort case. Seems like a good fit to me.
If you're starting to use state machines, then I would definitely look into learning a little about queued state machines. Ever since I started using them I've never gone back to using a "regular" state machine. Queued state machines can do everything a regular state machine can by simply enqueuing one state at a time, but they also allow the flexibility of enqueuing a sequence of states and creating macro-type steps.
For instance, you could have two macro steps called Check Preconditions and Start Test. The Check Preconditions enqueues the states [Check A, Check B, Check C, Check D, Start Test]. If any of the preconditions fails, they flush the state queue and enqueue an Abort macro case that will safely shut everything down and then return to the Idle case.
The biggest advantage of queued state machines over regular state machines is that it becomes very easy to reuse states in different sequences. This is very common for utility-type steps such as Show Front Panel, Write Log File, or Report Error. It is very hard in a standard state machine to reuse a state in different sequences, because that state always hard-codes what state they go to next. To reuse a state in two different sequences of states, where that state must transition to different states, you'd have to have some complicated logic to decide what state to transition to. Trust me, it is not fun.
The great thing about queued state machines that solves this problem is that most states generally don't specify what state comes next. For instance, in the case above Check A doesn't specify that Check B comes next. Instead, it just lets the state machine dequeue the next enqueued state. This means you can very easily reorder the precondition checks without actually editing any of those individual states. Or you could enqueue a precondition in the middle of a test if you wanted.
Here are some good links on queued state machines. I especially like the JKI template! They put a lot of thought into how to structure a QSM so that you don't have to start from scratch. You also get things like integrated error handling.