LabVIEW Queued State Machine as Parellel Process Enabler

[Anthony_L]

Hi

LabVIEWs Queued State Machine Architecture is a detailed article on its application for parallel process programming geared to take advantage of LabVIEWs hyperthreading capabilities and multi-core processor PCs of today.

I am writing future book chapters as blog articles so your critique/comments are appreciated.

Anthony L.

[Bob_Y.]

I have really enjoyed the articles on ExpressionFlow.  I also like this one, but I think it could use just a little work.  I think that the content is good.  However, about 1/4 of the way down, you have:

A general layout of QSM-PC architecture comprises of the four objects annotated by the encircled numerals 1 to 4 shown in Figure 1. These objects are namely: (1) Queue reference object; (2) User events object (optional for head-less embedded applications that require no user interaction); (3) Main state machine object; (4) One or more parallel processes subVI objects.

You then go on to have

Item (1) The Queue Reference

Item (2) Consumer Object State Machine

Item (4) Parallel Process SubVIs

You need to reconcile the two.  I think that a separate (probably earlier??) chapter/article on event structures including dynamic (user) events could be referenced as item 2.

Thanks for the articles and I hope that this helps!
Bob Young

[Neil.Pate]

great article Antony, you have clearly put a lot of work into this.

A few comments, if you don't mind. You seem to prefer hiding the wire for the main queue reference under the consumer states, I know it tidies up the block diagram a little, but this may lead some people to think that it is a good idea to hide wires under other objects!

Also, In your Figure 17, you refer to subVI 1, where is this in the figure? (I am afraid I cannot open the example on the website as I only run 7.1)

Do you have links to any other chapters for me to read? 🙂

cheers
Neil

[Gabi1]

yes i enjoyed very much the reading as well. will definitely use some parts of the template. and i learned some things about coloring loops 🙂

---

@nrp wrote:
A few comments, if you don't mind. You seem to prefer hiding the wire for the main queue reference under the consumer states, I know it tidies up the block diagram a little, but this may lead some people to think that it is a good idea to hide wires under other objects!

---

i saw that too. altough that kind of "break the rules", this still seems to be the better solution, and visibility is actually enhanced. can we say that since we know the rules, we can allow ourselves to bend them?

[Neil.Pate]

cute, bender is happy to bend the rules

[Ben]

"... we can allow ourselves to bend them?"

Just incase someone stumbles across this thread some time in the future...

It is NOT cool* to run wires behind structures.

The article and code are great otherwise.

Ben

* You just have to troubleshoot one application that has a node behind a structure  to appreciate why that rule should never be broken. I hope none of you acquire that appreciatation first hand.

[Anthony_L]

Bob:

Thanks for pointing this out!  The section header that was skipped, i.e.  (2) Event structure; is in fact quite important because the queued state machine is used in part to run events code asynchronously. So I will definitely edit the article to correct this.

Thanks again for this observation.

Anthony L.

[Anthony_L]

Hi Neil:


Thats true! I broke a cardinal rule in block diagram wiring by hiding that queue reference wire behind the consumer state machine. As I did this, I was aware that someone would question this style.

But really this is done to reduce the wire clutter on the block diagram. Remember that the QSM PC code base should really be a template VI  where it is not expected for someone  to need to troubleshoot the wiring of the template itself. Ideally you should make this template into a merge VI that you can quickly include into a new VI. So in that case, the hidden wire will no longer be a questionable feature.

I am assuming of course that the hidden wire feature does not affect LabVIEW performance (i.e. LabVIEW doesn't care) but that it is something to avoid just for simplifying debugging.

I will include a comment on this when I revise the article shortly.

Anthony L.

[Anthony_L]

nrp:

I will include a downloadable link to LabVIEW 7.1.1 QSM -PC example code after I review the article based on the suggestions I got here.

Anthony

[Neil.Pate]

Antony,

I agree with your points, its just that my personal preferance is to not have any wires covered. I suppose that anyone who has enough LV knowledge to follow your example probably already knows well enough the style guide, and can bend it as necessary. I have a chronic aversion to hidden wires as I have had to spend a lot of time refactoring code where nodes/structures had been moved on top of wires and generally complicated everything to the maximum!

One more question I have, in your queue typedef constants on the block diagram, you have the state enum and data variant immediately to the left of it. When I create cluster constants mine always end up with the elements stacked vertically. Do you manually rearrange it, or is it some setting within LV?

Neil