How do you model this?

[Daklu]

I've been working on developing a state diagram to document what our application has morphed into.* The main loop uses a QSM architecture with ~35 states. Some of the states queue up several states to execute in sequence. (Woo hoo! A queued sequence machine! ) Some of the states don't queue up any states after executing, relying instead on a previous state to drop enough states on the queue. (This is the kind of thing I was thinking of when I referred to a "procedure machine" here.) Some states queue up a new state under certain conditions, but drop to idle under other conditions. Trying to map it all out is dizzying.

My question is about those states that do not queue up a new state. As I understand it a state diagram shouldn't have a single state listed more than once. How do you go about diagramming a situation where the previous state is one of many possible states and the following state depends completely on what was already put in the queue? I have the distinct impression what we ended up with may be a state machine architecture but it's not really a state machine. For one, I assume that for it to be a state machine you have to be able to model it. Nevertheless, I still don't grok the Moore vs Mealy state machine models or how they apply to software, so maybe what we have is a Mealy machine and it is possible to model it clearly...

*Yes, I know the diagram is supposed to come before the code. Managing this headless chicken of a project was out of my hands. Best I can do at this point is try to contain the blood.

[Grampa_of_Oliva_n_Eden]

I've been working on developing a state diagram to document what our application has morphed into.* ...

*Yes, I know the diagram is supposed to come before the code. Managing this headless chicken of a project was out of my hands. Best I can do at this point is try to contain the blood.

This question illustrates why I don't use a QSM. All but the simplest can become impossible to diagram.

But to help you...

I'd start but putting names on the pseudo-sequences that are possible. By pseudo-seq, I am thinking about the string of state that get queued up. Draw them up as flow diagrams ("a little Mealey a little Moore" Head of software Engineering at a lage company). To help flesh what I am trying to get at... In some ways a QSM almost reads like text language, where the developers code up states that are called like sub-routines and the order is as queued with parameter passing being implied through the common SRs'.

Done thinking, I hope that gives you some ideas.

Ben

PS Just noticed the sub-heading and No, i am not a SD expert. I have just been using them for 30 years and I feel very comfortabel with them.

Edited December 15, 2009 by neBulus

[Mark Smith]

So, to me this type of QSM is really just a huge function library where

1) the function calls are the case names

2) the queue becomes the "script" that defines what function is called

The problems here are that

1) There may not be any explicit arguments (or there may be, if the queue contains variant data or such) but there are probably many implicit arguments to each function (case) and they're often hard to track down

2) There are probably no explicit return values to the function calls (if you're luck there's at least error handling) but there's lot of data generated or changed

3) The script is not immutable - the queue (script) could be changed at any point in the run sequence (at runtime) and you can't usually tell what might or did change the queue by examining the queue itself. Self-programming applications can be kind of cool but they're not typically suited to reproducible, reliable test and measurement software.

So, I think the most one could do in documentation is treat this "state machine" like a function library and document what each function (case or "state") does - as you've already realized, you can't possibly document every flow thru the "states" since one could easily write code that puts functions on the queue in an endless, random loop. If that's not adequate (you have to know what the sequences will be) then throw away the code and start over.

And don't let those guys use QSMs again! If you need a test sequencer, try TestStand or if you want to script your applications (which I prefer) LuaVIEW is great.

Mark

[Daklu]

Just noticed the sub-heading and No, i am not a SD expert. I have just been using them for 30 years and I feel very comfortabel with them.

Actually you are one of the people I was specifically hoping to get some feedback from. 30 years of state machines is way more experience than I have.

This question illustrates why I don't use a QSM. All but the simplest can become impossible to diagram.

Yeah, I've come to the conclusion they don't scale well at all--though I wonder if it is more a matter of ill-defined states rather than an inherent problem with QSMs. I did try modelling it by abandoning the 'each state only appears once on the diagram' restriction. I'm guessing this is what you mean by a "flow diagram."

I discovered a case of 'QSM parallism.' What I mean by this is that a state queues up more states with the expectation that they will be executed immediately, but the queue still had states on it that it needed to execute to complete a previous process. That essentially (unintentionally) splits the execution into two separate paths that are interleaved on the queue, which of course leads to unpredictable behavior. The odd thing is the software seems to be working okay. I suspect dark magic is at work but I loaned out my copy of "Software Exorcism for Dummies" and haven't got it back yet.

In some ways a QSM almost reads like text language, where the developers code up states that are called like sub-routines and the order is as queued with parameter passing being implied through the common SRs'.

Yes! This is exactly what I was trying to describe with the term "process machine." You know how when you're watching a scary movie you can tell when something bad is going to happen? That's kind of how I felt, but I couldn't identify what the consequences were going to be or why it was going to happen. Just a nagging sense that it wasn't right.

"a little Mealey a little Moore"

I'm still struggling with Mealy vs Moore as they apply to Labview state machines. From what I can find online the main difference between the two is that in a Moore SM the output depends only on the operations performed in that state while in a Mealy SM the output depends on the operations performed in that state and on the inputs themselves. If that's the case, I believe a non-queued SM in Labview would be a Moore SM. Does it stand to reason that a QSM in Labview is a Mealy SM since the output (next state) depends not only on the operations in the state, but on whether or not there are any states remaining on the queue?

So, to me this type of QSM is really just a huge function library where

Oooo... a "Function Machine." I like that better than "Process Machine."

You did an excellent job of concisely articulating what's been rattling around in my head. Clarity is a wonderful thing.

And don't let those guys use QSMs again!

Ahh... I neither have the influence nor the position to enforce this.

[jzoller]

mesmith is right: this is a function library, not really a state machine.

I wouldn't try to diagram it. Rather, I'd describe each "function" (or case), with pre- and post-conditions expected. If it modifies a variable with multi-function scope, I would add that as well. I would also document typical use cases for each function and for the program flow as a whole.

However, I see nothing wrong with this style of programming: it's powerful and flexible. The problem with inserting states into other state sequences can be solved by adding a batching mechanism to the architecture (I use a second queue).

I've found the licensing limitations and additional software requirements of TestStand and LuaVIEW are really restrictive in the environments that I work in, and a native LV solution is usually easier to handle.

... then again, I like to build compilers, so maybe this should be taken with a grain of salt

Joe Z.

[asbo]

I'm still struggling with Mealy vs Moore as they apply to Labview state machines. From what I can find online the main difference between the two is that in a Moore SM the output depends only on the operations performed in that state while in a Mealy SM the output depends on the operations performed in that state and on the inputs themselves. If that's the case, I believe a non-queued SM in Labview would be a Moore SM.

Obviously, it's rarely that will you ever see a pure Mealy or a pure Moore SM in LabVIEW. In general, your code will tend to be more-Mealy - when's that last time you built a VI that had no sequence deviations/condition handling/etc?

As for Mealy versus Moore, I would classify a state/SM to be Mealy if there's more than one possibility for the next state, strictly from the scope of that state. If decide if you have a "pure" Mealy, simply see if all your state qualify as Mealy. In your instance of states which *don't* queue a state, they can't really be classified as either, I wouldn't think.

Does it stand to reason that a QSM in Labview is a Mealy SM since the output (next state) depends not only on the operations in the state, but on whether or not there are any states remaining on the queue?

Mealy machines depend on the current state and *input to that state* - whether or not there are other queued states shouldn't change the classification of the SM. I think because it's more a level above the behavior of the state itself, it should be removed from the consideration.

[Mark Smith]

...I've found the licensing limitations and additional software requirements of TestStand and LuaVIEW are really restrictive in the environments that I work in, and a native LV solution is usually easier to handle....

Joe Z.

I know any time one makes a blanket statement about any architecture being "good" or "bad" that there's room for real disagreement - I don't use QSMs but I am sure that there are people (like Joe) who know exactly what they're good for and how to make them work so they shouldn't be dismissed out of hand.

However, I will take exception to the statement about the licensing limitations of LuaVIEW (can't speak to TestStand - I don't use it). With LuaVIEW, the license is per project (or a site license, which I have). At any rate, all deployed apps built under this license are covered under the development license cost - no additional deployment license required - and all developers on the project are covered under the single license. Also, all license management is "honor system" - there's no license management software mucking things up so you don't have to worry about licenses expiring at your customer's site (or for your developers) and getting those angry phone calls. Also, the entire Lua interface is accomplished thru a CIN so there's no additional dll's or run times or anything else that needs to go with the deployment. It's really pretty simple.

Mark

[jzoller]

I know any time one makes a blanket statement about any architecture being "good" or "bad" that there's room for real disagreement - I don't use QSMs but I am sure that there are people (like Joe) who know exactly what they're good for and how to make them work so they shouldn't be dismissed out of hand.

However, I will take exception to the statement about the licensing limitations of LuaVIEW (can't speak to TestStand - I don't use it). With LuaVIEW, the license is per project (or a site license, which I have). At any rate, all deployed apps built under this license are covered under the development license cost - no additional deployment license required - and all developers on the project are covered under the single license. Also, all license management is "honor system" - there's no license management software mucking things up so you don't have to worry about licenses expiring at your customer's site (or for your developers) and getting those angry phone calls. Also, the entire Lua interface is accomplished thru a CIN so there's no additional dll's or run times or anything else that needs to go with the deployment. It's really pretty simple.

Mark

The issues aren't technical (well, primarily, since I've seen LuaVIEW's daemon cause some stability issues), they're financial and company cultural. And (rewrites post 7 times) ...a bit too detailed to go into here. PM me if you're really interested in details.

Joe Z.

[Daklu]

Obviously, it's rarely that will you ever see a pure Mealy or a pure Moore SM in LabVIEW. In general, your code will tend to be more-Mealy - when's that last time you built a VI that had no sequence deviations/condition handling/etc?

As for Mealy versus Moore, I would classify a state/SM to be Mealy if there's more than one possibility for the next state, strictly from the scope of that state.

So a Moore SM always proceeds sequentially from one state to the next with no decision branching? Are you sure that's right? That definition seems to trivialize Moore SMs to the point of being useless. I've know I've seen state diagram examples claiming to be Moore SMs that do have branching...

Mealy machines depend on the current state and *input to that state* - whether or not there are other queued states shouldn't change the classification of the SM. I think because it's more a level above the behavior of the state itself, it should be removed from the consideration.

This is a good point. The queue isn't part of the data used to make decisions on what the next state should be; it's just part of the framework that allows the QSM to work.

On the other hand, one could argue that the queue is the ultimate decider on the next state. I guess it depends on what you consider state inputs and outputs. Is the state output only the data and the state(s) it put on the queue? Or can the queue itself be considered an input/output. If you're simply adding states to the end of the queue I can see the states themselves being the output. If you're flushing the queue or adding states to the front of the queue I would lean towards calling the queue itself an input/output.

Still puzzled. I'll have to ponder it for a while.

[asbo]

So a Moore SM always proceeds sequentially from one state to the next with no decision branching? Are you sure that's right? That definition seems to trivialize Moore SMs to the point of being useless. I've know I've seen state diagram examples claiming to be Moore SMs that do have branching...

I thought about that as I wrote it up, and unfortunately came up with no good absolution. The way I see it, if a Moore machine can only progress based on the current state, how can it possibly do any decision branching?

On the other hand, one could argue that the queue is the ultimate decider on the next state. I guess it depends on what you consider state inputs and outputs. Is the state output only the data and the state(s) it put on the queue? Or can the queue itself be considered an input/output. If you're simply adding states to the end of the queue I can see the states themselves being the output. If you're flushing the queue or adding states to the front of the queue I would lean towards calling the queue itself an input/output.

Yeah, I could see that as well, particularly with sticking states on the front of the queue. Perhaps Moore and Mealy didn't think that there would ever be such a thing as a QSM - 640K ought to be enough for anybody, right? It's entirely possible that it succeeds definition by Moore or Mealy.

As a hilarious aside, it seems some vandalism has escaped the WP nazis ... for now:

[Grampa_of_Oliva_n_Eden]

RE: the differnce between the two versions...

THe guy I quoted earlier is on one of those positions people dream of when is comes to software positions. I can't think of a more lofty postition than he has. When he looked at my designs and commente "a little Mealy a little ...." it did not matter for him. Before I heard him say that, I din't know there was a difference so I just did what came naturally to heel with whatever it is called.

RE: the current state Q

If you look at how the new SM toolkit works, it appears to be a fancy interface that lets you configure nested case structures. Everytime it's loop iterates it evaluates all of the conditons gurads etc. to decide what state it is supposed to be in. I don't use that tool since it prevents me from stay in a state to keep up with queues but rather I have to poll the queue, but I digress.

Ben

[GoGators]

I was pretty sure that a QSM, no matter what you did, was going to difficult to model using Meally-Moore state machines. The reason is that the Queue essentially makes it event driven, and that events break the predefined transition from one state to another. The way I look at it is with the three cases below.

1) Basic Case. Enqueue state A, state A is processed, wait for next state.

2) Compound-State case. Enqueue state A, state A is processed but at the end of the state it enqueues state B. State B is processed, wait for next state.

3) Interrupted Compound-State Case. Enqueue state A, state A is processed but before the state finishes state C is enqueued, at the end of the state A it enqueues state B. State C finishes. State B finishes. Wait for next state.

Essentially that could go on forever with events queued up, so that nothing processes sequentially like a SM needs to be modeled, and every thing is at the mercy of the queue. I would say to enforce the flow of the program if you need to model it.

If a Sequence is running only allow states to be queued up to a secondary queue (or more). That makes it so that sequences must finish before moving on to other operations, thus the wait state must be preformed before operating on another sequence. I think that makes modeling much easier. Drawback is that new events have no priority and you have to wait for sequences to finish before responding.

Event based modeling is difficult, and always makes me do star-type diagrams.

[Grampa_of_Oliva_n_Eden]

I was pretty sure that a QSM, no matter what you did, was going to difficult to model using Meally-Moore state machines. The reason is that the Queue essentially makes it event driven, and that events break the predefined transition from one state to another. The way I look at it is with the three cases below.

1) Basic Case. Enqueue state A, state A is processed, wait for next state.

2) Compound-State case. Enqueue state A, state A is processed but at the end of the state it enqueues state B. State B is processed, wait for next state.

3) Interrupted Compound-State Case. Enqueue state A, state A is processed but before the state finishes state C is enqueued, at the end of the state A it enqueues state B. State C finishes. State B finishes. Wait for next state.

Essentially that could go on forever with events queued up, so that nothing processes sequentially like a SM needs to be modeled, and every thing is at the mercy of the queue. I would say to enforce the flow of the program if you need to model it.

If a Sequence is running only allow states to be queued up to a secondary queue (or more). That makes it so that sequences must finish before moving on to other operations, thus the wait state must be preformed before operating on another sequence. I think that makes modeling much easier. Drawback is that new events have no priority and you have to wait for sequences to finish before responding.

Event based modeling is difficult, and always makes me do star-type diagrams.

Good point! many of my GUI's apps are of that form with a single event state taht transitions to a state then return to the event state.

The following ideas are based on the QSMs that I have seen...

I thought about this modeling Q and what I suggested earlier to draw-up the stacks that are queued up as individual diagrams. If you complete this work for your app I suspect you will find the the states that are called in more than one of these diagrams (example File Open, just guessing) could be turned into a sub-VI that could be used before exiting the state that calls them .... with the intent to eliminat that state from the stack that is queued up. If this process is repeated for all of teh "shared" states, and extended for the one-off states, a QSM can be converted to a normal state diagram.

But the above is just a thought exercise and I am not telling yo to rewrite your code just so you can model it. But if you do the re-write in your head or on paper, you may be able to draw up the moel after all using "macro states".

But then again if the QSM is pushing at both the front and the back of teh queue... I don't think the above will work.

Ben

[Daklu]

For your viewing amusement, here's the diagram I came up with after the parallelism problem was fixed. (Zoomed out to obscure the details.) Note this is only the part of the program that runs when the "Start Test" button is pressed. I haven't bothered with the rest of it.

Yeah, there's definitely room to condense the number of states used. The pre-test validation process can be compressed into a single state with multiple VIs. Odd design decisions early on make the execution loop harder to refactor. In truth I probably won't do either unless someone specifically asks me to. I'm ready to get off this merry-go-round. (Either that or given ownership of it.)

As long as I'm complaining... has anyone ever noticed that it's way easier to develop software for someone who doesn't know Labview than it is to develop software for someone who does know Labview but doesn't understand application development?

Edited December 18, 2009 by Daklu

[harbenger]

My (limited) understanding of state machines requires that the next state logic be well defined. The QSM seems to create a hybrid state machine where the next state logic is an array. So, each state has an input which is the queue and then outputs it as next state logic. Luckily, I don't think this will change whether or not it is a Mealy or Moore machine. However, the utility of a next state array comes with the cost of increased complexity. I'm not sure you can use the traditional state machine representations as the queue allows any state to transition to any other state. And, as you mentioned, states can exist with no next state logic. This notion is completely against traditional SM design. If you have large SM's and/or want to regulate the transitions, I would be weary of using the QSM. If you have to use a QSM, I would try and model it as close to a traditional SM as possible. Hopefully you can eliminate any major vulnerabilities in your code.

As for the Mealy/Moore question, one good place to look for information is in university course notes. Here is a >10 year archive for some good holiday reading. I'm sure there are better places for this, but this this one is familiar to me. http://www-inst.eecs...0/archives.html

There is a primary difference between Mealy and Moore machines, which comes from the digital logic world: synchronization. In Moore machines, the output is dependent on only the current state. This means that the output changes at the clock edge when the SM transitions to a new state. This is not true for a Mealy machine. If the input changes inside a state of a Mealy machine, the output CAN change before the clock edge. Other side effects: Mealy machines typically have fewer states, but have synchronization problems when combining multiple SM's. I would say that we mostly program in a Moore-like structure: at a fairly high level, our states perform a specified function with little consideration of changing inputs. However, if your state's function (output) depends on inputs to perform, it would be a Mealy machine.

Interestingly, the state transition is the same for both Mealy and Moore machines. It can be a function of inputs and the state. However, a decision must be made on the next state. In the digital logic world, the next state logic is traditionally synchronized to the clock. This means that the next state logic can change where the state will transition up until the clock edge. This can be lost in the software world, especially when event structures and queues throw out fixed timing altogether.

I think there is a common misconception between how state machines transition and how the output is generated. The Mealy/Moore difference is really about how the output is generated, NOT how the states transition. My guess is that this confusion comes from moving a hardware defined (digital logic) concept to software. Outputs are now more than just digital bits as we have our states doing much more sophisticated things. If the function of our state depends on any kind of input, then technically it is a Mealy machine.

I see two kinks in using QSM's: 1. Event loops break regularly (this is a loose term) scheduled state transitions. 2. There are queue management issues abound. My current favorite is when one state machine has two independent idle loops. If there are two events which cause the SM to switch between loops, it is possible that the queue will grow with state transitions that will never be serviced.

[Black Pearl]

I found a general way to model the QSM, although it is impractical for description (but might be useful to remodel a QSM).

Consider a simple state machine, with an dequeue element state. After every state it transits back to the dequeue state. From there it might transit to any other state depending on the queue element.

From the modelling side, the queue is now a history data (remember the QSM architecture based on arrays?) and not part of the transition logic.

Felix

[Daklu]

It's apparent lots of people don't like using the QSM because of the same problem I ran into. Personally I'm leaning towards calling the QSM an oxymoron. It's not a state machine at all; it's a mislabelled Queued Message Handler. (I thought the QSM was one of the design templates included in Labview, but it's not. The QMH is though.) Some might consider this a minor semantics issue. I do not. If I'm working on a "state machine" I expect certain behaviors and I write my code around those expectations. A QMH has a different set of expected behaviors. Calling it a "state machine" is confusing and leads to disjointed code.

[Thinking out loud...]

I think any QSM can be refactored into a standard SM with many of the QSM states turned into sub vis. The refactored application should be easier to maintain. Many apps will require more than just the SM to replicate the original behavior, and I'm not sure how much additional framework will be required. For example, in my DequeueState sub vi I often have checks for specific errors that need unique handling. Maybe the SM should continue the process, maybe it should abort, maybe it should restart. Handling mulitple options within a standard SM could be difficult.

Something else I've come to realize after thinking about GoGators' and harbenger's posts is that the QSM couples the message receiving code and the state transition code into a single loop. Given a queue reference, other processes can put arbitrary states on the queue. The same queue is used for internal states to queue up the next states. This makes it impossible to enforce specific calling sequences within the QSM loop. Looking at it this way I'm more inclined than ever to believe the way we are using the QSM in this application is bad, bad, bad. The internal state transitions need to be handled separately from the external transition requests. (Maybe this is what jzollier meant by using a "batching mechanism?")

The only way the SM can work reliably is if you enforce where (on the state diagram) external actions can trigger new states and what states external actions are allowed to trigger. Failing to enforce either of these opens the door for particularly nasty bugs. A QSM with an event structure in an idle state addresses the first constraint as long as no parallel processes have a reference to the queue. New states are only added from the idle state. It does not prevent the second. To enforce the second you would have to create states only for the idle case and to respond to external actions. If my app responds to a 'Load' command and an 'Exit' command, there are only three states in my diagram: Load, Exit, and Idle. Any utility or intermediate states need to be made into sub vis instead. What you end up with is a star diagram like GoGaters mentioned.

I dunno... the more I think about it the less I like the QSM. Personally I'm about ready to file it under anti-pattern, right next to action-engine. I might consider it for prototyping something or a quick and dirty tool, but I wouldn't want to base an application on it.

[Black Pearl]

Somewhere I read (can't reference) that you should NEVER let the message consumer enqueue elements on it's own message queue.

There have been several designs of SM's which fall on this category of anti-pattern: Using arrays (that was even on NI if I remember correctly), queues and the event-queue. There is even a worse example in the LAVA 1.0 (and presented as very bad) of a 'SM' that had two stacks and push/put operations on them.

I've previously fallen into this trap, so I stick with the simple SM's either using enums or strings. If they need to receive data/messages/events, they handle it in an 'idle' state.

Or I use some kind of message handler (which originates from producer/consumer and not SM design), which never writes back on it's own queue.

I think on a more abstract level, this anti-pattern allows to create a positive feedback and thus has the ability to get unstable (like exploding the queue, getting into an oscillating state or even chaotic state). But other than in other systems with instability (filter design, OpAmp's), I have no idea how to model such a system and 'prove' if it's stable or not.

Felix

[Grampa_of_Oliva_n_Eden]

It's apparent lots of people don't like using the QSM because of the same problem I ran into. Personally I'm leaning towards calling the QSM an oxymoron. It's not a state machine at all; it's a mislabelled Queued Message Handler. (I thought the QSM was one of the design templates included in Labview, but it's not. The QMH is though.) Some might consider this a minor semantics issue. I do not. If I'm working on a "state machine" I expect certain behaviors and I write my code around those expectations. A QMH has a different set of expected behaviors. Calling it a "state machine" is confusing and leads to disjointed code.

...

I dunno... the more I think about it the less I like the QSM. Personally I'm about ready to file it under anti-pattern, right next to action-engine. I might consider it for prototyping something or a quick and dirty tool, but I wouldn't want to base an application on it.

Here at home I am trapped at LV 8.5. So I checked out the Singleton design pattern that shipped with 8.5 and there it is, an Action Engine at the heart of the Singleton.

Types and Anti-types can both be useful, so I'll use them where appropriate.

The QSM was taught as part of the orginal LV advanced course and was presented as "the type".

I have a customer (may be a past customer of someone else here) that was originally based on the QSM and he (the customer) was sold on the QSM being the only "right" way to code large apps (old advanced course).

After 6-7 years of enhancing and adding to it resulted in a monster that he could not maintain, so he hired us. We now have two developers working 3/4 of thier time on that app. We need two because the code changes are so complicated that one guy does that , and the other runs through the 93 pages of acceptance testing for each release.

The reason I sahre this story is to illustrate that the QSM simply does not scale well. The inability to document the flow is a major factor.

Ben

[PaulG.]

... I might consider it for prototyping something or a quick and dirty tool, but I wouldn't want to base an application on it.

Indeed. Large applications built around the QMH can be nightmares, but there is nothing more useful when you need something quick and dirty. I most often use the QMH when my vi starts taking on too much room on my screen but it wouldn't make logical sense to create a subVI. I whip up a QMH then just start adding states.

[Daklu]

We now have two developers working 3/4 of thier time on that app.

And they haven't quit yet? Kudos to them...

Types and Anti-types can both be useful, so I'll use them where appropriate.

My biggest issue with both the QSM and the AE is that you are coding yourself into a dead end that is time consuming and difficult to get out of. I maintain that the AE is an anti-pattern because a better (IMO) solution exists. I'm not sure if there's an adequate alternative to the QSM so until one is found it escapes the scarlet A. (Secretly I know it's guilty and I'll continue to give it the evil eye whenever I see it.)

The QSM was taught as part of the orginal LV advanced course and was presented as "the type".

I hope the new courses don't teach that. Or at least teach the limitations of the QSM.

Indeed. Large applications built around the QMH can be nightmares, but there is nothing more useful when you need something quick and dirty. I most often use the QMH when my vi starts taking on too much room on my screen but it wouldn't make logical sense to create a subVI. I whip up a QMH then just start adding states.

So what do you do when your QMH starts to get too big to manage? Stop and rebuild it with a different architecture? Is there another architecture you could have started with that is nearly as easy to implement and scales better or is easier to refactor when the need arises?

[crelf]

The QSM was taught as part of the orginal LV advanced course and was presented as "the type".

That was a loooooong time ago and that course has been several times, including very recently by Nancy Hollenback. I'm not saying that a QSM or QMH pattern isn't appropriate in some cases, but a lot of things have changed in the LabVIEW world in the last 10+ years

[PaulG.]

So what do you do when your QMH starts to get too big to manage? Stop and rebuild it with a different architecture? Is there another architecture you could have started with that is nearly as easy to implement and scales better or is easier to refactor when the need arises?

That hasn't happened yet. But if it did, yes, I would probably switch over to a typedef enum state machine if I started creeping towards, say around 10 states or more.

Whatsamatta? You never had to re-write your own code before?

[Daklu]

But if it did, yes, I would probably switch over to a typedef enum state machine if I started creeping towards, say around 10 states or more.

Heh... you just wait...

Whatsamatta? You never had to re-write your own code before?

Yeah... too often for my liking. But that's not the real problem. Once the application framework is put in place it's nearly impossible to convince anyone who is not directly involved in coding that it needs to be restructured. I need to start with something flexible enough to adapt to different change requests because I'm sure not going to have time to add the flexibility later.

Edited December 30, 2009 by Daklu

[styrum]

Here is an implementation of a queued Mealy State Machine.

Updated for 2016:

https://forums.ni.com/t5/Reference-Design-Content/Event-Driven-Queued-State-Machine-EDQSM/ta-p/3841938

Original LAVA thread:

https://lavag.org/topic/4623-simple-event-driven-queued-state-machine-with-front-panel-events-and-a-timer/

 

Edited December 12, 2018 by styrum