Why is 2nd While Loop in State Machine generated by State Diagram Toolkit?

[JCC_(SK)]

I generate State machine by State Diagram Toolkit in LabVIEW.
I don't understand why is 2nd While Loop [and Enum to Interger and status's Enum constant] in main State Case. Why is not inside only Case Structure?
Thank you

[SachaE]

Hi,
because of the way the state machine must remain flexible, it iteratively searches through the cases in the smaller (internal) while loop to find a match case to move onto the next state. If it doesn't make a match, it matches on default.
I'm going to use the word "classic" to signify the old layout (one while loop, and lots of case statements).
Essentially, this is where, in a "classical" state machine (before the toolkit) you would have had to return to a "what next" state, like checking a menu or something like that, if you needed to decide between more than one case.
e.g.
state 1 : can go to state 2 or 3 depending on something
state 2 : can go to state 4 or 1
state 3 : goes to state 1
So you have decision making areas, and work areas in each sta
te.
Make better sense now?
To do the "classic" style it's almost impossible to programatically distinguish between where the decision making would take place for the next state in each state case, and where the actual work of each state is. The layout would not be consistent.

Thanks

Sacha Emery
National Instruments (UK)

[JCC_(SK)]

Hi, Thank you for your answer.
But how you do decision and how you after call next new state?
I attach small VI code. Please can you check and repair it? And do it by your mean.

Thank
Peter Juracic

[Ben]

Sacha gave a valid answer but let me try to help.

1st
I do not have LV 7.1 on my machine yet so I can not open your example VI.

2nd
"...why is 2nd While Loop [and Enum to Interger and status's Enum constant] in main State Case?"

The small while loop inside one of your states is the logic used to decide which state your application will transition to next. If your design only has the default transition, this loop does not do much.
If you have a state that can transition to more than one other states, that small loop does the decision making to decide which state we got to next.
Now if you have a state that can transition to one of many other states, AND the conditions (see below) are satisfied for more than one of the transitions, you can define which of those states "wins" by defining the order in which those conditions are checked.

So...
The small while loop determines which state you go to next.
It only makes a difference in states that have more than one state that they can transition to.

3rd
When you have a state in your design that can transition to more than other state, the SD Editor will create a new case in the "little while loop" for your new transition. When it does, the SD Editor will leave the boolean tunnel un-wired. You can then insert the appropriate LV code that will return a "true" when the condition is met.

When I am designing apps using the SD Editor, I will draw-up the design and leave all of those tunnels un-wired until I think I have something worth checking.
At that time I will then copy the name of the transition from the SD and then click on the transition arrow in the SD. This will cause the block diagram to show the code where that transition is located.
I will then right click on the output tunnel and do a "create control". When the new control is created, I will then paste the transition name I copied (see above) into the newly created button.

I will continue this process until I have fixed all of the un-wired booleans.

After the VI is no-longer broken, I will have a bunch of booleans on my FP with names that match up with the transisions.

Now it time for some fun!
I then put the SD in execution highlighting and watch how the program flows using the boolean on the front panel to test all of the code.

This serves a number of purposes;
1) I can think through all of my logic before getting into the low level stuff.
2) The FP booleans serve as reminders that I have to write code to replace the buttons.
3) I think its interesting to watch my designs in action.

If all is OK at this point, I am ready to develop code for each state.

Sorry I drifted off subject a little there. Back to your Q!

4th
The small while loop allows each state to have a unique set of transitions. If it was outside the individual states (as you suggested) the transition would have to be shared.

I hope this answer along with Sacha's answer is valualbe to someone.

Ben

[JCC_(SK)]

Hi,
thank you Ben for answare.
Now, I understand. Thank for good idea how desing application and how testing new Status Machine with highlight.

I creat small example [saved to LV7.0] and any screenshots. Application working good. But it is wrote correct? Corensponding with your idea? It is OK connect TRUE values from outside of small while loop?

Thank you
Your JCC

[Ben]

Good job!

Ben