topic Re: Tips to remember when using Queued State machine in LabVIEW

Tips to remember when using Queued State machine

VeeJay — Fri, 09 Mar 2012 15:53:39 GMT

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!

Re: Tips to remember when using Queued State machine

Ben — Fri, 09 Mar 2012 16:09:58 GMT

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...

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

Ben

Re: Tips to remember when using Queued State machine

VeeJay — Fri, 09 Mar 2012 16:47:48 GMT

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!

Re: Tips to remember when using Queued State machine

Ben — Fri, 09 Mar 2012 17:23:20 GMT

@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

Re: Tips to remember when using Queued State machine

SteveChandler — Fri, 09 Mar 2012 17:53:51 GMT

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.

Re: Tips to remember when using Queued State machine

Chingon — Fri, 09 Mar 2012 20:22:51 GMT

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...

Re: Tips to remember when using Queued State machine

SnowMule — Fri, 09 Mar 2012 20:26:21 GMT

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.

Re: Tips to remember when using Queued State machine

SnowMule — Fri, 09 Mar 2012 20:35:21 GMT

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.

Re: Tips to remember when using Queued State machine

Chingon — Fri, 09 Mar 2012 20:47:52 GMT

^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.

Re: Tips to remember when using Queued State machine

VeeJay — Fri, 09 Mar 2012 20:51:04 GMT

@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!

Re: Tips to remember when using Queued State machine

VeeJay — Fri, 09 Mar 2012 20:53:03 GMT

@Chingon I thought I could share a document i found on NI community that describes writing Daqmx to a file using PC architecture. Hope this gives a tip on what you are trying to do.

https://decibel.ni.com/content/docs/DOC-2431

Re: Tips to remember when using Queued State machine

Chingon — Fri, 09 Mar 2012 20:54:08 GMT

^Yes, I also don't really understand the meaning of enqueuing data to yourself.

-sorry for the threadjack, I'll make a new thread regarding my debugging process. Suffice it to say that the enqueuing fix SnowMule provided has worked.

Re: Tips to remember when using Queued State machine

SteveChandler — Fri, 09 Mar 2012 23:07:41 GMT

@VeeJay wrote:

@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!

This is what I mean. I should have elaborated.

Re: Tips to remember when using Queued State machine

Ben — Mon, 12 Mar 2012 12:50:05 GMT

Well there wre not a lot of sugestions by users of QSMs so I'll add what I know and have learned from recieiving them as projects started by my customers.

1) The QSM desgin patern reminds me of "The Worm Orobors" Dragon eating its tail. I mention this bcause like a dragon the QSM can be powerful and at the same time dangerous. If the Dragon eats too much it can slow down further consumption.

This is illustrated by Steve's post above where he warned about queueing update state from within states.

Steve Chandler wrote:

...

But if we takes Steve's suggestion literaly the QSM will simply become a State Machine (with a fancy way of sortin the next case) and defeats the feature of the QSM.

So be very careful in how muh you let the QSM feed itself. If you get to a point wre you want to give it two bytes of the apple, thenk twice (or three times).

On the same token, think about those states that welcome "stacking up the plate" like the sequence of states "Set Path", "Open File", "Write" for example. A QSM can be structured to use those three states in sequence for mot than one file. So instead of pushing three states Set, Open, Write, concider tossing "Set" and "Open" and turn them into sub-VIs that are invoked prior to calling "Write".

So consiering turning states into sub-VI to avoid the defining a bufet for the beast.

2) Analyze your data structures and think about "Who touches what data when?"

WHat you will often find is there is some data that only gets touched in a couple of situations and there fore the data does not have to be available in every state. Concider pusing that datat down into a AE and remove those explicit functions from the QSM (same thoughs apply to SM BTW). When it time to do something whit tht data, use the AE and not a state in the QSM.

3) Document, document document!

QSM's can develop in beasts if you are not careful. If you limit them to a well defined set of tricks and declaw them regualarly, and keep thm hungry, you and your code should benefit.

Trying to help,

Ben

Re: Tips to remember when using Queued State machine

VeeJay — Mon, 12 Mar 2012 13:41:38 GMT

2) Analyze your data structures and think about "Who touches what data when?"

WHat you will often find is there is some data that only gets touched in a couple of situations and there fore the data does not have to be available in every state. Concider pusing that datat down into a AE and remove those explicit functions from the QSM (same thoughs apply to SM BTW). When it time to do something whit tht data, use the AE and not a state in the QSM.

Thanks Ben! That explains quite a bit. I am a little lost on Point 2. I do have data that is only used in certain states. I just wire it up to the case structure and use it only in the required state. For example, My COM Port sends speed and angle data only when we click on a CONTROL. My state machine sits in a wait state until I get the "START boolean", "Speed" and "Angle" data from the COM port. START=TRUE, I enter into an operational state. Is this a wrong way to go about it? (You said, same thoughts apply to SM ) A little more elaboration would be awesome. Thanks!

P.S. I think the architecture I am using is pseudo QSM, I will post my vi once I Clean up a little bit.

Re: Tips to remember when using Queued State machine

VeeJay — Mon, 12 Mar 2012 14:16:01 GMT

Also, I would like some guidance in using shift registers for queues. Sometimes, I see code where shift registers are used for queue name and error, in the enQ loop and not in the deQ loop. Why is it? Is that the right convention?

Re: Tips to remember when using Queued State machine

tbob — Tue, 13 Mar 2012 17:34:29 GMT

@VeeJay wrote:

Also, I would like some guidance in using shift registers for queues. Sometimes, I see code where shift registers are used for queue name and error, in the enQ loop and not in the deQ loop. Why is it? Is that the right convention?

Whenever using a loop, especially a For Loop, there is a chance that the loop will iterate 0 times. Lets say there is an array going into the loop with indexing enabled. Lets say the array accidentally is empty. The loop will iterate 0 times. Whenever this happens, if you use regular tunnels for the queue name, the queue name goes in, but since the loop did not execute, some default value (probably NULL) comes out. So when you try to close the queue name, you will get an error.

If you don't use an array to trigger the number of loops, this point is pointless. But it is a good habit to make to always use shift registers for such things as queue names, VISA handles, etc. As for error in and out, if you use shift registers, any errors that occur in one iteration carries over to the next. With tunnels, this won't happen. Whatever comes into the loop will always be used for the next iteration. You will lose any errors that occur inside the loop, except for the last iteration.

I hope this clears up the shift registery mystery. I always use shift registers, even for While Loops, just to form and keep a good habit.

Re: Tips to remember when using Queued State machine

VeeJay — Wed, 14 Mar 2012 15:22:09 GMT

Thanks tbob! That helps. I always used shift registers for Q's but now am also going to use it for VISA Serial handles and errors. I haven't seen any case in my 2 years where it didnt work without shift registers but it is better to be safe.

One more question. Is it mandatory to run the Q name wire through a case structure or event structure to the other side? I mean, the data that I deQ is used in the case structure/event structure but I do not wire the Q name through. Any repurcussions in not doing this?

Also, highlight execution is so slow that sometimes the I lose track of the logic. And especially with the Software I am using for integration, it pops an error whenever I use highlight execution (perhaps the 3rd party software I am using has a timeout error or something). So, I am unable to step through my code, I am forced to complete the entire code before testing it in which case I am either right or wrong and troubleshooting is getting hard. Is there an alternate to highlight execution?

Re: Tips to remember when using Queued State machine

VeeJay — Wed, 14 Mar 2012 17:45:25 GMT

I have attached my code (simplified version of my humongous application). Main idea is implementation of Qs. Comments on this would help me when I take my CLD next month.

TEAR ME APART! I need to learn. Thanks!

Please excuse the Block diagram. I put it up in a hurry for comments. Basic thing happening there is Serial Port sends commands and accepts Feedback (top 2 loops).

Based on commands, instructions are sent and feedback received. (bottom 2 loops) It looks like a 1-stop flight you take. both ways 🙂 Central loop is the layover.

Any design errors and logic ones? I would really appreciaite it.

I have posted this in many forms before and I think this would be my last one since I would have used Qs. TDML_split ....vi is the subvi in loop1. Inside that vi there are just conversion vis. I don;t think those need to be posted unless they do. Please let me know. Sorry for multiple edits.

Re: Tips to remember when using Queued State machine

johnsold — Wed, 14 Mar 2012 18:17:48 GMT

VeeJay,

First, I have not taken the CLD, so consider my comments with regard to that.

1. Documentation is listed as a major component of the scoring. The scorers seem to want VI documentation, tip strips on controls, description on BD of what various parts of the code do, and a non-default icon. You have a few comments on the BD and none of the others. You do nota have anything which actually says what this VI is expected to do.

2. Make Typedefs of controls and clusters which get reused or which may need to be modified in the future. Your byte count cluster was the one which caught my eye. You have two copies of this outside the the upper loop. One would be enough.

3. Shift registers. Several of the shift registers carry data which is never changed inside the loops. Do you have a good reason for using shift registers rather than tunnels? If so, it should be documented.

4. The TDML_split.... VI is missing. It appears that you read on byte from the serial port and then derive three numerical values from it. I would like to know how you do that.

5. The Queue Status followed by #elements in queue = 0? seems to be redundant with Dequeue with a timeout.

6. Writing data to the Control code indicator will not trigger the Control code value change event.

7. The Unbundle and Bundle nodes in the event structure can be simplified and improved. The image below shows your original code in the center. Below I show wiring the cluster wire into the center terminal of Bundle. When it is wired this way, only elements which change need to be wired at the left side. At the top I show the same thing using Bundle by Name. This has the advantage of bein self-documenting.

Anyone looking at this code knows immediately what is being changed. You code works. The others can save you some time now and in the future.

8. You do not handle or report errors. That is one of the things which I have heard that CLD scorers look for.

Lynn