Tips to remember when using Queued State machine

[VeeJay]

@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

[Chingon]

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

[SteveChandler]

---

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

[Ben]

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 

[VeeJay]

---

---

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!

V

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

[VeeJay]

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?

[tbob]

---

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

[VeeJay]

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?

[VeeJay]

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.

[johnsold]

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