I like the idea of having the Event Structure outside the main while loop and of having multiple producer and producer/consumer loops (some of which live in task specific subVIs) the way the article describes. One of the main advantages of putting the Event Structure outside the main loop above is that it keeps the main loop from free-wheeling just to handle the event structure, which makes debug much easier. Including an IDLE state defeats this advantage. The only reason for IDLE is to facilitate stopping all the loops via global Boolean. Instead, I just enqueue SHUTDOWN to all the loops. If you don’t know how many loops you have before run time (i.e. you are spawning other loops dynamically), this is still easy to do by tracking the queues you’ve created.

BTW, thanks for taking time to understand what I wrote.

@Peter
Consider using User Event architectures in combination with Queued architectures. User Event architectures cause all loops to respond to all messages, which introduces unnecessary complexity (and free-wheeling) in most cases. The important thing is to understand the tools and pull out the right one when necessary. So, enqueue directly to the destination you want and, when necessary, broadcast to all processes via the User Event framework. (Yes, you could just enqueue the same state to everybody as well.)

@String-State-Machine-Folks
I know you favor the use of type definitions elsewhere, so why not take advantage of them and make the switch to enum-based-state-machines (like I did several years ago).

-If you update the name of a state, all case structures and constants update too!
-Stop trying to remember what you called something…. or, worse, stop maintaining lists of state names so you can remember what you called something while declaring that maintaining an enum is too much work. When you have multiple loops and 100+ states, I don’t see how anyone tolerates strings.
-Can the LabVIEW run-time engine switch states (cases) as quickly on a string as it can on a U32? (doubtful)
-Delete that “whoops you mispelled the state name” default state from all your loops.
-Passing data with the state you are enqueueing guarantees another state doesn’t overwrite data you put on the main shift register (yes, some string folks add a “state data” variant or string as well, but most don’t).
-Use a string where it’s really valuable: target to target communication (e.g. PC to cRIO). I don’t advocate using the same type defined enum for multiple targets since each gets it’s own base code. But, enjoy the enum when you’re within the same target. Then, convert the enum to string when sending over TCP/IP, Shared Variable, etc. and back to enum on the other side.

*LabBEAN1 = LabBEAN … forgot password for LabBEAN and cannot receive emails where I created that account.

But I am not sure, whether it can happen, that the Idle-state-Consumer-iteration just ends and you add D right before the next iteration of the consumer starts. You want to add DCBA with the producer at the beginning of the queue, to get an ABCD-queue. Now the consumer works on the Idle state, but RIGHT after the idlestate iteration ends and BEFORE the new iteration starts, you add the D state. The chances for that to happen, should be ultra low, but perhaps it can happen.

To have no problem with that, you could add only A with the producer and let A add DCB within the queue manager. Or like you said, by using a dummy-state. Or you could use 2 queues: One connecting the Producer with the queue-manager. And one connecting the queue-manager with the consumer. This could even solve problems like this: “i added Stop state S at the beginning, while state A was working. Now A is finished and adds B at the beginning, which results in a BQ-queue.”

Beautiful article.
I’ve been using my own LV state machine architecture for a long time. Your architecture is the last leap I needed in order to make them more robust.
Thanks very much.

good luck,
Yuval Yohai

Let’s say one of the producers (see the red “4.1″ in Figure 2 above) enqueues states on the opposite end to the consumer (see the red “3″ in Figure 2 above). When the first state is enqueued, then the consumer will immediately dequeue it because the consumer is waiting to dequeue an element. If you enqueue the elements in reverse order (which I agree *of course* that reversing the order first is necessary since they are each being enqueued on opposite end), then the elements will run in the order “last”, “first”, “second”, “third”, “…”, “next to last”. You need to enqueue a dummy element on opposite end first.

Note: This is not the case when enqueueing within the same consumer (because of data flow) or for any future elements after the first element enqueued on opposite end when enqueueing from producer to consumer (as long as the Q MGR [see red "1.5" in Figure 2] is non-reentrant).

Please reread my previous post.

Take care,
Jason

The need to reverse the order of multiple events added to the front of the queue is correct. This is implemented in Figure 9 of the article. Notice the ‘Reverse 1D array node.’ Thus events are always reversed by the queue manager subVI when added to the front of the queue.

Regarding the implementation of enqueueing on opposite end (front of the queue): When you enqueue multiple items on the opposite end to another loop which is waiting to dequeue elements [where execution order is critical (e.g. State 1, State 2, State 3, State 4)], the waiting loop will dequeue and run State 4 first. Here’s why: Before enqueueing the 4 states on the opposite end, you must first reverse their order. When another loop is waiting to dequeue, it grabs the first item you enqueue (e.g. State 4). It’s not a concern that it grab subsequent items, regardless of execution speed, since all loops share the same non-reentrant Queue Manager, and the only instance of the Queue Manager is busy enqueueing the next three states (in this example). Therefore, you could end up with an execution order of State 4, State 1, State 2, State 3. So, I would suggest enqueueing a dummy state before enqueueing on opposite end your states in reverse order.

Else, odd behaviour can occur (e.g. Stop state occurs before Power Supply Off state *ouch*).

Consider my example again. You have two idle-like loops which place default next-state commands into the queue. Likewise, you have two events which allow you to switch between loops. Each state by itself will not change the size of your queue. However, your queue will continue to fill up with unserviced next-state requests as you switch between states. This is true because the event loop is the primary producer of queue elements and the consumer loop has a net zero loss.

You can confirm this by adding queue status VI’s either in-loop or as a separate loop.

I was able to fix this by adding more functionality to your Q Manager.vi. I’m not completely sold on it being complete, but the idea is as follows: Define a ‘default’ next state transition as a boolean input. Only add the default next-state element to the queue if your queue is empty. Otherwise, don’t add it. This will fix the always increasing queue size problem.

Just wanted to comment on the idle state case. Note that the idle event is added at the end of the array build node. This means that any events added to the array build node, prior to the idle event, will run first.

Also, the idle event should only be added in the idle case to indicate an eventual return to that case for polling or looping purposes. Alternatively you can omit adding the idle event to keep the program ‘silent’ so that it only wakes-up and acts when some new event is added to queue.

Finally, take note that as you add events to the queue in other cases you have the option of adding them to the ‘front of the queue’ so that they get executed immediately. This means that the event will be jumping the queue and will be immediately de-queued for execution.

I hope this further clarifies things