Jump to content

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


Recommended Posts

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.

Link to comment

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

Link to comment

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

Link to comment

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". :D

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". :)

Link to comment

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

Link to comment

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

Link to comment

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.

Link to comment

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

Link to comment

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

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.

Link to comment

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

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

Link to comment

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 :oops:

eh, I like mine more anyways

Link to comment

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

Link to comment

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)

Link to comment

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

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" :wub:

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

Link to comment
  • 2 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.