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

All I’m trying to say is that I am concerned about poor queue management when the consumer loop creates next state logic. It is very possible to create queue entries which will never be serviced.

Any thoughts?

I have successfully used this specific QSM architecture for a relatively large application and was mostly happy with how things turned out.

Today I read the following comment from an NI employee about using User Events instead of QSMs. What do others think ? Does the proposed alternative below have any downsides compared with QSMs ?

http://pasquarette.wordpress.com/2009/09/

“The powerful thing about User-Defined events is that a developer gets to dictate what information gets sent to that event via the event’s internal terminals. A very simple example of this is: you can create an event called “save”, which has a path attribute. When the event gets called, the path attribute can be accessed using that events terminals, and the application can save its state at the path given. It is the caller of the event who would have gotten to specify what path to provide. Old and alternative ways of doing this was to use a LabVIEW Queue, who’s elements would either be a cluster of the data you wanted to pass around, or a variant so that anything could be passed. Both of these techniques have issues. One places a burden on the type of data that can be passed in the cluster, the other places the burden on the receiver of the data to extract it from the variant. The event structure removes both of these burdens by allowing each event type to have different data passed to them, and by giving direct access to that data within the event case via the internal terminals.”

regards

Peter Badcock
Product Development
ResMed Ltd

Anthony