LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Queued State Machine

Solved!
Go to solution

Here is a problem I am having:

 

How to pass data procesed by the Consumer loop (lower) to the Producer?

 

My app is using producer/consumer structure because certain processes are slow and may lock the UI.  However the data processed by the consumer loop is useful for certain events in the producer loop.

 

How to pass?

 

I have considered:

 

1. Local variables (simplest approach)

2. Action Engine

3. User Events (can trigger user event in the producer loop (top) from the consumer?)

4. Queues

5. Shift registers

 

Anyone have any examples?  Is this just bad practice passing upwards?

0 Kudos
Message 21 of 24
(1,817 Views)

You can try to wire the "element" terminal of the Queue VI with a cluster that contains the "enum" (case of the state machine) and a "variant constant" (used to transport your data from the producer loop to the consumer).

 

Then you will use a "to variant" VI to convert your data to variant, and connect it to a bundle VI. Connect also the enum (state of the state machine) to this bundle. Now, feed the queue with the output of the bundle.

 

Don't forget to unbundle your cluster after dequeue it.

 

Dan07

Message Edited by dan07 on 04-11-2010 08:49 AM
0 Kudos
Message 22 of 24
(1,814 Views)

On Events, a wrote a big Community Nugget

 

Felix

0 Kudos
Message 23 of 24
(1,803 Views)

Hi Dan,

 

Going back earlier to the possible problem of having States added out of sequence if plan on adding 1 state from another more then 1 time. You can get around this problem by adding the next state at the front of the Queue. This will ensure that if while one of your states is taking a while and another set of states has been added in the meantime by your event structure, your next state will still happen next and all other states afterwards:

 

State 1 _ 2 queue snippet 2.png

 

State 2 is now enqueued using the 'Enqueue element at opposite end' vi instead. This is ok as you know you want this state to go next. As previously mentioned this will only be a problem if you plan on queueing states from the current state more then once in a row. If your only doing it once there will not be enough time for another event to fire and insert other states as in the above example state 2 will be enqueued almost straight away. If however in state 2 you will enqueue a state 3 but state 1 takes a relatively long time to execute then other states could be inserted during this time between state 2 and state 3. This problem can be avoided by using the 'Enqueue element at opposite end' vi. Hope i am explaining this clearly enough.

 

Rgs,

 

Lucither

------------------------------------------------------------------------------------------------------
"Everything should be made as simple as possible but no simpler"
Message 24 of 24
(1,771 Views)