state machine enum decision

[idjuven1]

When I try to design a state machine enum,

I can make a normal enum.

but Sometimes I read that people use an array of enum..

sometime people use Queues...

anyone can provide advices on these options?

Thanks so much,.

[Gregory]

Hi idjuven,

I think of a state machine as a flow where the previous state, along with some boolean logic or results determines the next state. If you have a predetermined order for several states, this is called a sequencer. 

If your VI generally looks like a state machine, but you have a couple states that always need to be called together in a certain order, then those are good candidates to turn into SubVIs and consolidate into a single state.

For a simple sequencer, you can make an array of your case enum and feed it into a for loop. This begins to look a lot like a stacked sequence structure, although you can use shift registers and have the ability to conditionally stop it before all cases are run.

If you use a queue to hold your states, I would follow the practice where only certain states can add to the queue. (In JKI State Machine these would be called Macro states). Otherwise, you will find yourself quickly confused by where states are becoming enqueued, why your VI is getting stuck in a loop, and generally lose the flow of the state machine.

[idjuven1]

Thanks so much..

but since a normal enum will work, why do they use a 1D array of enum (place the normal enum in an emply array)?? is it because in some states, it will require state manipulations (i.e. the next state is not defined)?

[Gregory]

From your description, it sounds like there would be no reason to do that. Can you post an example in case I'm picturing it wrong?

[idjuven1]

this is the practice for the CLD exam..

please see their solution.. I don't think it needs to be so complicated..

[Gregory]

Sorry I am using LV 2016 and those are saved for LV 2018. You will have to backsave in order for me to open them.

[idjuven1]

2014 version.. thank so much!

[Mark_Yedinak]

---

@idjuven1 wrote:

Thanks so much..

but since a normal enum will work, why do they use a 1D array of enum (place the normal enum in an emply array)?? is it because in some states, it will require state manipulations (i.e. the next state is not defined)?

---

In the "Check Time" case they actually "queue" up to actions to the state machine. If "Has Time Elapsed" is false, they "queue" up the actions "Run State" and "Idle" to the array. The array in this example is basically a queue. In this particular example there is only one situation where they queue up multiple actions so I can see why you might wonder why they are using an array. It is there so that multiple actions can be queued up if necessary such as the "Check Time" case does.

[Gregory]

Hi idjuven,

I agree with you, there is no good reason to use an array of enums here. Maybe the creator did not know about LabVIEW queue functions, but it seems like anyone training for the CLD should be aware of them. All of the array functions could easily be replaced by queue functions, but I would probably just tweak the logic a tiny bit so that the one case where they want to enqueue 2 states instead of 1 is not necessary, and you can just use a single enum instead. 

For anyone interested in how the array of enums is being used like a queue in this solution, here is a small clipping:

[crossrulz]

---

@Gregory wrote: All of the array functions could easily be replaced by queue functions, but I would probably just tweak the logic a tiny bit so that the one case where they want to enqueue 2 states instead of 1 is not necessary, and you can just use a single enum instead.

---

There are a bunch of array constants in there that will completely overwrite what was already in the array.  So a Flush Queue and then an Enqueue would be required for that.  Personally, I think this example could be improved by turning it "inside-out": put the Event Structure on the outside and the state case structure in the timeout case.  Then you could get away with just a single enum (no arrays).