please don't do it

[terrill]

I would just like to make a suggestion to any LabVIEW programmer. I do not know what they are teaching in the Advanced Applications Course but I would like them to note that it is not the best programming practice to use a queued state machine for everything. I know it is a good code structure for many applications and I use it myself but if you do not need it do not use it. It only complicates code and adds overhead if it is not needed. If you have sequential code then code it sequentially. It is easier and faster to read. Sorry about taking out some fustration but it would be nice it they mentioned that it should be used when needed in the class. Almost every person I interact with lately that has taken that course uses that structure for everything. I wish they could teach when to use a structure like that and when to use a plain old sub vi.

[BiomedEE]

Thanks for the post. I don't know why the queued state machine became all the rage in last couple years. I wrote one of my own several years ago but there was one that came out in LTR that many groups push. I don't use that one, but notice many who do. I use mine only sometimes.

I had a big alliance member employee comment that a simple test sequencer program I wrote was so "archaic" when it fit the exact task of the customer who needed a simple sequence of tests. Queued state machines are being pushed heavily, even though they are not always what is needed, and sometimes people just don't know what other ways to develop so they think everything else isn't right.

I agree with you, although I suspect many won't.

All the best.

[Joe_H]

I agree if you do not need it do not use it. I have seen a lot of vi's here lately that use them in simple subvi's. If you need it sequential use the error cluster for dataflow. As taught in LV basics 1&2. When programming we should all KISS (Keep it simple stupid).

[terrill]

I do not think I could post any code as it would be against my companies policies. For an example, I just heard on department in this company took the time to recode all their tests as queued state machine. There are very few reason to code tests as state machines. The flow is: set switch path -> set instruments -> set UUT -> Make readings ->determine pass fail. Any repeat on failure can be accomplished with a while loop. I am new to this company and I know I have a battle on my hands trying to eliminate the one vi does everything coding. I believe in function blocks that lend themselves to code reuse.  I am actually in a group that used stacked sequence structures(reading this is my real frustration) for everything and now wants to move to the message handler structure. I guess I'll have some good debates in the weekly meeting.

[Joe_H]

Save the words show the code is part of my signature. I got tired of saying if we could see your code we could help better. I was not implying for you to show your code it is just part of my signature.

[Dennis_Knutson]

I'll agree that state machines do not need to used everywhere but replacing them with stacked sequence structures is not the best alternative, imho. I too do a lot of tests with flow like yours but I think having an error in frame 0 and then having to go to frame 1, frame 2, ad naseum until I get to the last frame is a waste of time. I want to immediately branch to an error handler. I think that using a lot of sequence locals makes for confusing wiring. I think that stacked sequence structures promote the unneccessary use of local variables. Stacked sequence structures hide code just as much as a state machine but I don't think there are any benefits. I believe that it's much better to just lay the code out in a linear fashion of the diagram.

[terrill]

Ha ha. It looks like part of the message because of the spacing. I needed to laugh even if it was at myself.

[Ray.R]

What's up with queued state machines these days?

Half the afternoon, the guy next to my cube was complaining at how "whoever implemented the queued state machines did a bad job"...  And the program is in C++ !!!!  😮  !!! 😮

And now I read this thread... It seems like it's the new trend.. 

Why?? Did I miss some sort of "DaVinci's SW Code: Using queued state machine "  ???

Yikes

😮

[shoneill]

I was just reviewing some code the other day and wanted to make a change to the program.

After a while I got fed up trying to implement the change (Without unwanted side-effects) so I changed to a state-machine architecture.

OK, this isn't a queued state-machine, but since it basically has no UI (The user points it at a folder and tells it to go  - kind of like a golden data retriever) so it doesn't need a queued state machine.

What I like about queued state machines is that the abulity to capture events and send commands via queue basically frees up the consumer loop from the UI thread.  Personally, I try to keep ALL UI accesses out of the consumer thread, sending the updates to a third loop to perform the display.  If the display isn't important, I can simply ignore the third loop.

I've become a friend of queued state machines because I believe that for certain types of programs (perhaps I just happen to be caught in that type or programming) it really promotes code-reuse, even for dis0play purposes.  I find it much easier to debug and modify than a simply "linear" program.  But the real strength in the queued approach is when implementing a UI.  Users aren't linear, so a non-linear programming approach is better.

Shane.

[TiTou]

Hi all,

Like many of you I do like and use a lot of queued state machines, not always of course, but maybe more that absolutely necessary ; sometimes a basic state machine would do the job and still I use my queued state machine. Why ? Well... tell me one thing that can be done with a basic SM and that can not be done with a QSM ??
In some cases the QSM might be a little bit too sofisticated for the job but what's wrong with it ?
THe same about stacked sequences, I totally agree with Dennis : tell me why I should use a sequence and not a simple SM with error handler ? That make no sense !
I am not saying sequences should never be used, I just don't use them for the main architecture but in my subVIs when there is nothing to pass from a bit of code to the next.

KISS (Keep It Simple Stupid) is a nice catch phrase but don't forget to keep it scalable and maintainable... and that can require more "sofisticated" code !


BTW : Dennis... first time I see a mistake in a post of yours but it is not about programming 😉  ; you wrote "ad naseum", correct spelling is "ad nauseam" 😛
For those who are not natural latin speakers it means "so as to disgust"