Tips to remember when using Queued State machine

[VeeJay]

I have been able to work through to convert my State Machine architecture to a QSM thereby eliminating using Local variables/property nodes to send values/data to my State machine but instead sending them through queues.

I would like some tips/advice on making use of them perfectly. Especially, "Not to do" stuff with queues and How to efficiently release a queue etc. What is the convention when using queues? Thanks!

V

[Ben]

Before I can reply I must ask a califying question.

Are you talking about a QSM Queued State Machine where the states to be executed are stored in a queue and populated by the SM cases themselves...

OR

QMH Queued Message handler where a secondary loop executes states based on what is queued up from anther source?

Ben

[VeeJay]

Hmmm!! I jumped the gun... I would have to say, Neither... I guess it isn't really QSM or Queued message handler. My State machine is the generic one. But, data for the SM is obtained from a queue and feedback is sent back from the State machine through a queue. Does that clarify ?

BTW, good to know more variations.. Thanks!

[Ben]

---

@VeeJay wrote:

Hmmm!! I jumped the gun... I would have to say, Neither... I guess it isn't really QSM or Queued message handler. My State machine is the generic one. But, data for the SM is obtained from a queue and feedback is sent back from the State machine through a queue. Does that clarify ?

BTW, good to know more variations.. Thanks!

---

That is a QSM.

I will defer to those that use them regularly.

I would only use such a a construct if the queue was limited to a single entry and prevented inserting multiple states at the front or back of the queue.

As long as the queue is limited to a single entry then a State Transition Diagram could be used to described all of the states.

The multiple entry version can be thought of as a method to implement a "goto" statement in LV. Very useful for those that come from a background working with stacks and pushing and popping off work and those that use them often love them.

But for me let me refer to a letter from Dijkstra quote from here

"GOTO Staements Concidered Harmful" goto statement introduces chaos

Ben

[SteveChandler]

Don't enqueue data to yourself. Sometimes it is appropriate but just be careful. This kind of thing can lead to horrible bugs that are difficult to track down.

[Chingon]

I guess I'll jump on this thread.  I'm having some trouble with basic producer/consumer loops.  My goal is to acquire waveforms from a digital oscilloscope and write them to file as quickly as possible.  For debugging I'm using write to spreadsheet, but I ultimately plan to write the data in binary format.

For some reason, the write loop below continues to write waveforms even after I've stopped sampling.  All of the waveforms appear to be identical (first waveform?) as well so I'm clearly not queuing/dequeuing properly.  I've changed numerous things, like adding a timeout to the dequeue but it had no effect...

Any clues?  Thanks in advance...

[SnowMule]

Move the dequeue-element VI inside the lower for-loop.  Without any data there, that VI will hold until there's data there.  When there is data there, that loop is going to execute until there's nothing left in the queue.

And dont' forget to close the queue at the outside of the producer loop, next to the z-scope close VI.

[SnowMule]

Also some other clean-up I'd suggest..

Get rid of the case statement in the producer loop.  It appears the only purpose of that is to turn on/off the saving-to-file VI.  Instead, put that switch in the consumer loop, and put the case structure around the write-to-spreadsheet VIs.  The less tunnels you have into and out of a case structure, the less memory/CPU it requires.

If you're logging a voltage and a time together, why write to two files instead of two columns in the same file?

Dataflow is the reason you see the first element written over and over and over and over.  The dequeue-element executes, pops the first element off the queue and stuffs it through the tunnels on the while-loop.   That dequeue-element never executes again, since its outside the while-loop, so the values of the first element stay at those tunnels and are brought in every time the loop comes around.  Since those values never change, the loop is going to execute infinitely or until the Stop Writing control is true.  The "# of elements in queue" updates because the queue wire is a reference to the queue that you're filling up in the producer and you read the reference to elements-in-queue each time the consumer loop spins around.

[Chingon]

^Thanks for the tips. I did move my dequeue into the while loop and that solved the frozen values.... but only when run in highlight execution mode.  When I run at full speed I get a nonsense repeated waveform.  Debugging to continue.

Also, when I release the queue after the producer loop I error out because my writing loop is still looking at it.  The reason I have a case loop in the producer is because the False state is when I'm graphing the waveforms and not writing them. That part works great.

[VeeJay]

@Steve Chandler, would you mind elaborating on your thought? I don't understand enQ when you have shown deQ element funtion. Do you mean do not enQ inside a case structure after deQing? THnaks!