Is the day of the "Queued State machine" behind us?

[shoneill]

QUOTE(Dan Press @ Aug 15 2007, 05:37 PM)

I have been using the pattern shown here for some time now. I have seen many varaitions on this. There is one loop for Events (UI) and another for other processing. I will also usually have a subVI tucked in the upper left corner that runs in parallel and at a different priority. That subVI houses DAQ stuff or other hardware interface code. I still consider this a queued state machine (QSM). The difference between this and the "monster" above is that the data is encapsulated in a cluster and there is an event loop. Still, this has its limitations. I have been guilty of amassing a long list of cases inside both loops!

http://forums.lavag.org/index.php?act=attach&type=post&id=6630''>http://forums.lavag.org/index.php?act=attach&type=post&id=6630'>http://forums.lavag.org/index.php?act=attach&type=post&id=6630

Dan, I do something similar, but I have seperate loops for Event handling (one UI loop), one or more "main" loops, sometimes one loop per instrument and an additional "cosmetics" UI loop. I like being able to define cosmetic states of the FP in a seperate structure. I also don't like property nodes stealing valuable screen space in my main loop. I also make a lot of my programs have optional UIs (mostly reacting to whether they're called as a sub-VI or a main VI). These cosmetic changes can then be really easily switched off when the code is running as a sub-VI.

BTW, I love the "For-Loop" coloured labels. Gives a really nice effect. Consider your style copied from now on!

Shane.

[TG]

QUOTE(Ben @ Aug 14 2007, 08:12 PM)

After some of my fellow wire workers were looking at a very complicated QSM application I explained that architecture was fine if you have spent your whole life doing assebly programming and you did not want to change the way you design applications.

With LV's multi-threading, it seems to me that there is no need to use one of those undocumentable monsters.

So although I have already instructed them to "never develop anything life that" I thought I may want to do a sanity check with Y'all.

So....

Are the days of the QSM behind us?

Please share your thoughts, and I will sit back and learn.

Ben

A well constructed queued state machine with exception handling is a very powerful framework for automation.

I use several flavors. I was originaly leaning toward using arrays of enum in place of the queue. Seemed more readable.

Now I lean towards simple strings. But the queueing framework remains very powerful.

I really like this one as a merged VI and Im starting to use it more for my automation objects. I has everything needed to handle exceptions locally or escalate upwards.

It can be made in many flavors. The simplest is string. Slow but portable.

http://forums.lavag.org/index.php?act=attach&type=post&id=6664''>http://forums.lavag.org/index.php?act=attach&type=post&id=6664'>http://forums.lavag.org/index.php?act=attach&type=post&id=6664

[Grampa_of_Oliva_n_Eden]

Thank you to everyone for their replies.

So it seems like the QSM will live for a while and that 2-10 states are recomended AND that a QSM with 60 states is a nightmare even for the most experienced QSM'ers.

???? Follow-up Q for those that use the QSM ????

Are diagrams ever used to document these critters and if so, could you post a sample diagram (just an image not your code) that illustrates the operation of a semi-complex implemtation?

Thank you,

Ben

[PJM_labview]

Ben,

I will have to disagree that 2-10 state is a max. I do have queue state machine with a lot of states (> 60 and < 100) and it is manageable.

As an example, the first time I look a the state machine of the OpenG Builder (done by Kostya Shifershteyn), it was pretty easy for me to follow what was going on (see screenshot below).

http://forums.lavag.org/index.php?act=attach&type=post&id=6717

• One of the critical issue in my opinion is to organize your state by category that are clearly different one from another. Also using "separator state" (see screenshot again) are very usefull for more that one reason:
  

• They are very nice for category segregation
  
• They serve as a template for creating new state
  

• Another issue is that you have to put some limitation from where you are "allowed" to enqueue more state. If every state can enqueue more state, it becomes very difficult to keep track of what is going on. Typically I limit most of the enqueing to one of the previously mentioned section and from the UI event (Event Structure).
  

PJM

[PaulG.]

Ben: QUOTE(Ben @ Aug 22 2007, 03:48 PM)

Are diagrams ever used to document these critters and if so, could you post a sample diagram ...

I've seen some great Visio/UML drawings that came close. And the mid-level subVI's broke down well into UML's as well. I've created an HTML out of the UML and made it part of my VI documentation. The trick: EVERONE involved with the project has to CARE about the documentation and know how to use the tools available and willing to put forth a little effort. The devil is in the details: accurate and complete signal lists, block and/or UML diagrams, defined states, well-documented VI's, i.e. the basics. An accurately documented 1000-state QMH would be a lot easier to deal with than a 20-state "self-documenting" "string state machine".

PJM: Categorizing states is something I started doing a long time ago. I agree is does make for an easier read. But I've inherited way too much 3rd and 4th and 5th party code. Categorizing states is "survival".

[PJS]

This reminds me of a conversation that went on some years ago petitioning NI to remove sequence structures from LabVIEW as well as another that wanted global variables removed. The core of both arguments was actually due to poor user implementation, and NOT the actual tool itself. This framework, like any other tool works just fine if the programmer has discipline. naming states with some sort of grouping method, logical dividers, a state, for debugging, that catches undesired cases, a cluster that is passed thru so that adding/deleting variables that need to be accessed in every state is on ONE wire, some sort of error handling routine AND the ability to log what the machine is doing are MUSTS. GEE, just like the arguement to remove GOTO statements from basic and fortran when I was doing that in the late 80s. The environment and frameworks are never responsible for making up for poor programming. This is not a criticism... When I look at my original labview code from back in 1993, it is enough to make me puke, but the race conditions, lockups and other problems I had back then were due to my poor programming decisions, and NOT from the ability to shoot myself in the foot! My $.02. No inflation here. LOL

[Grampa_of_Oliva_n_Eden]

QUOTE(Pana-man @ Aug 23 2007, 12:21 AM)

This reminds me of a conversation that went on some years ago petitioning NI to remove sequence structures from LabVIEW as well as another that wanted global variables removed. The core of both arguments was actually due to poor user implementation, and NOT the actual tool itself. This framework, like any other tool works just fine if the programmer has discipline. naming states with some sort of grouping method, logical dividers, a state, for debugging, that catches undesired cases, a cluster that is passed thru so that adding/deleting variables that need to be accessed in every state is on ONE wire, some sort of error handling routine AND the ability to log what the machine is doing are MUSTS. GEE, just like the arguement to remove GOTO statements from basic and fortran when I was doing that in the late 80s. The environment and frameworks are never responsible for making up for poor programming. This is not a criticism... When I look at my original labview code from back in 1993, it is enough to make me puke, but the race conditions, lockups and other problems I had back then were due to my poor programming decisions, and NOT from the ability to shoot myself in the foot! My $.02. No inflation here. LOL

The suggestion to group and organize the steas is a good one. I'll pass that on to the engineer who has to work with that app.

Ben

[PJS]

QUOTE(Ben @ Aug 23 2007, 07:53 AM)

The suggestion to group and organize the steas is a good one. I'll pass that on to the engineer who has to work with that app.

Ben

Not wanting to take the credit, it was suggested up higher. If you click on the link to my samples, there is a template ready to download that provides a base framework. Amazingly similiar to others I have seen. I guess when you are on the right track, you start to see convergence on simularities. It implements all that I have suggested above, And can very easily be modified to a two loop machine. The one feature I have not seen in similiar architectures is using a multiline string to add states rather than the pesky array constant. For me, it makes it infinitly more readable. For all, feel free to comment good or bad.

[Grampa_of_Oliva_n_Eden]

QUOTE(Pana-man @ Aug 23 2007, 08:02 AM)

Not wanting to take the credit, it was suggested up higher. If you click on the link to my samples, there is a template ready to download that provides a base framework. Amazingly similiar to others I have seen. I guess when you are on the right track, you start to see convergence on simularities. It implements all that I have suggested above, And can very easily be modified to a two loop machine. The one feature I have not seen in similiar architectures is using a multiline string to add states rather than the pesky array constant. For me, it makes it infinitly more readable. For all, feel free to comment good or bad.

Like your signature, I'm always willing to learn.

Since I came into programming through the back-door I have never received any formal training in programming (LV courses and intro to C are the exceptions). So rather than getting the "this is a car and it consists of a suspension system, a..... I learned to code by examining first a bolt and then a nut and the two put together are a fastening system...

So hearing this from the "top-side" helps a lot.

Ben

[JDave]

Ben,

I am still curious. One must infer from this thread that you are using something different (and better ) than a QSM. What is it?

David

[LAVA 1.0 Content]

QUOTE(dsaunders @ Aug 23 2007, 03:47 PM)

Ben,

I am still curious. One must infer from this thread that you are using something different (and better ) than a QSM. What is it?

David

Must be the "SEA MONSTER"

some crappy state event archictecture software I once saw on a job from a co. in Chicago

Anyone every heard of it?

[orko]

QUOTE(NormKirchner @ Aug 23 2007, 02:03 PM)

Must be the "SEA MONSTER"

You mean like http://muppet.wikia.com/wiki/Cookie_Monster' target="_blank">C-Monster?

[PJM_labview]

One thing I forgot to mentioned in my previous post.

Having the ability to log your state name to file (as they got fired) does wonder for debugging.

PJM

[Neville D]

QUOTE(PJM_labview @ Aug 23 2007, 02:37 PM)

Having the ability to log your state name to file (as they got fired) does wonder for debugging.

PJM

I usually like to display the state history in a listbox like so:

http://forums.lavag.org/index.php?act=attach&type=post&id=6740''>http://forums.lavag.org/index.php?act=attach&type=post&id=6740'>http://forums.lavag.org/index.php?act=attach&type=post&id=6740

I remove the property node and the auto-indexing for the final exe.

Neville.

[PJS]

QUOTE(Neville D @ Aug 23 2007, 06:36 PM)

I usually like to display the state history in a listbox like so:

http://forums.lavag.org/index.php?act=attach&type=post&id=6740''>http://forums.lavag.org/index.php?act=attach&type=post&id=6740'>http://forums.lavag.org/index.php?act=attach&type=post&id=6740

I remove the property node and the auto-indexing for the final exe.

Neville.

my architecture allows for logging. But the listbox control is interesting... could setup an input on the initiialize of my queue to open a clone front panel, and then use that listbox idea to display a state history, so to speak. hmmm, interesting idea. It might get a bit complicated since the manager can handle multiple queues running at once... but a debugging tool to look into non, the less. Might be nice to use a multi-column list box, with iteration next to it... so that the number of duplicated states are not adding to the list. In that I mean, if you keep going back to the same state, a counter would run up, rather than keep adding the same state. Many times, I have an issue, where I go to the wrong state, over and over... so rather than have 100 lines of "state a", I would have "State a" in once column and 100 in the next. Now if it is ping ponging between two states, then those entries would be logged... Plus I see other benefits of the multicolumn.. which is out of the scope of this conversation at the moment. I may have to play a bit this weekend.

[orko]

QUOTE(Neville D @ Aug 23 2007, 03:36 PM)

I usually like to display the state history in a listbox

I use a SubVI that all of my queueing and state management VIs (or anything else that is interesting really) write into with a conditional disable structure to turn it off when needed. That way I can run normally, or open up this SubVI and change the project condition to DEBUG=TRUE to see stuff happening in real time without changing any code.

Works good for me, especially with multiple producer/consumer loops where there's some sort of timing issue to debug. I put in filtering so that I wouldn't clog up my debug window with stuff I wasn't looking for.

http://forums.lavag.org/index.php?act=attach&type=post&id=6744''>http://forums.lavag.org/index.php?act=attach&type=post&id=6744'>http://forums.lavag.org/index.php?act=attach&type=post&id=6744 (LV 8.2)

Now to combine this with the listbox idea... I like the idea of multiple entries being counted. Thanks Neville & Paul!

[PJM_labview]

QUOTE(Neville D @ Aug 23 2007, 03:36 PM)

I usually like to display the state history in a listbox like so:

http://forums.lavag.org/index.php?act=attach&type=post&id=6740

I remove the property node and the auto-indexing for the final exe.

Neville.

Another thing I am doing (when state logging is not required) is to used a modified version of Daren "String with history probe". This is pretty usefull too.

http://forums.lavag.org/index.php?act=attach&type=post&id=6745

http://forums.lavag.org/index.php?act=attach&type=post&id=6746

PJM

[LAVA 1.0 Content]

Well not for long term monitoring, but as far as short term goes, I've found a custom probe I made 'Logged String' to be very useful.

Logs last 48 elements real time and gives plot of delay between updates, so you can see if you have any states taking really long or whatever you can think of.

Enjoy and use in good health

http://forums.lavag.org/index.php?act=attach&type=post&id=6748

UPDATE: Just saw PJM's post above mine

eh, I like mine more anyways

[Mike Ashe]

QUOTE(NormKirchner @ Aug 23 2007, 09:59 PM)

UPDATE: Just saw PJM's post above mine

eh, I like mine more anyways

They are both nice.

[Grampa_of_Oliva_n_Eden]

QUOTE(Mike Ashe @ Aug 23 2007, 10:18 PM)

They are both nice.

What do I use?

I have used and really like the the State Diagram Editor.

Yes I have to clean-up the messy code it creates.

Watching it in execution highlighting provides the functionality y'all have discussed plus it gives me the diagram so I can look back and forward.

Unfortunately for me, all bugs for the SDE have gone un-fixed and the State Chart is due to be released.

Since that spell the the death of the SDE, I have been madly reading about UML so I can use the new tool kit.

BTW: The SDE lets me remind myself how my code was structured (for that app I develed 3 years ago) when the customer calls and asks about a detail.

Ben

[PaulG.]

QUOTE(Ben @ Aug 24 2007, 06:26 AM)

I have used and really like the the State Diagram Editor ...

:thumbup:

I thought I was the only other LV programmer in the world who didn't cause other developers' heads to spin around and spit up green soup when I started playing around with the SDE. And I, too am looking forward to using the State Chart. So many tools ... so little time to learn how to use them. (sigh)

[Grampa_of_Oliva_n_Eden]

QUOTE(PaulG. @ Aug 24 2007, 01:20 PM)

:thumbup:

I thought I was the only other LV programmer in the world who didn't cause other developers' heads to spin around and spit up green soup when I started playing around with the SDE. And I, too am looking forward to using the State Chart.

See my blog entry from Feb 28 2006 here

http://forums.lavag.org/blog/champions/index.php''>http://forums.lavag.org/blog/champions/index.php' target="_blank">http://forums.lavag.org/blog/champions/index.php?

entitled "Ode to a State Diagram"

Most of the developers I work with use the SDE even with its limitations.

If it really does get droped by NI, I'm going to start begging for the source code of the SDE to be released as open, unsupported code. That thing is so close to the perfect tool for staying out of the dirty little details while still writing LV code.

But I digress from the reason for this thread, sorry.

Ben

[hviewlabs]

My design of universal event-driven state machine (EDQSM) which is capable of asynchronous communications with other such modules:

http://forums.lavag.org/Simple-Event-Drive...imer-t4687.html

This doesn't support hierarchical states though. For that see LabHSM.com