Using multiple (2) event structures in 1 VI

[ShaunR]

A state machine "should" (with a captial SH) be used to allow branching and "break" dataflow, not enforce it (dataflow does that implicitly). And you "SHould" only break dataflowas a last resort (it is after all LV biggest asset). A sequential statemachine is no different from a stacked sequence (in fact it is worse since it is more complicated). A procedural state machine not only flattens the hierarchy reducing abstraction and code re-use. It also hides functionality (making reading more difficult), is more difficult to debug and prone to transitional errors. Used sparingly, it is a powerful tool. Used excessively, well, you might as well write C.

With the exception of message handlers, I've yet to come accross a state machine that requires more than 10 states. I have however seen many with 30+. (In fact, the last time I saw that many I made him re-write it in 5....lol)

The readablilty issue is clear (as it applies to stacked sequences).

Here is a dataflow implementation:

Same thing written as a state machine:

[jzoller]

A state machine "should" (with a captial SH) be used to allow branching and "break" dataflow, not enforce it (dataflow does that implicitly). And you "SHould" only break dataflowas a last resort (it is after all LV biggest asset). A sequential statemachine is no different from a stacked sequence (in fact it is worse since it is more complicated). A procedural state machine not only flattens the hierarchy reducing abstraction and code re-use. It also hides functionality (making reading more difficult), is more difficult to debug and prone to transitional errors. Used sparingly, it is a powerful tool. Used excessively, well, you might as well write C.

With the exception of message handlers, I've yet to come accross a state machine that requires more than 10 states. I have however seen many with 30+. (In fact, the last time I saw that many I made him re-write it in 5....lol)

...

I agree with the comments on the sequential state machine: its use is primarily as a teaching tool.

The rest: nonsense.

A procedural state machine (PSM) doesn't break dataflow (certainly not the way locals, globals, refs and property nodes do). A PSM does allow much more flexibility over how the dataflow occurs, and that admittedly does increase complexity.

However, saying there are too many states is like saying something is "too pink": purely stylistic. After all, changing the structure of well written code doesn't result in any less code, or necessarily any more readability. Particularly where decision making is involved.

Better criteria for state machines: Are the states well factored? Single responsibility? Grouped by purpose? Well named and well commented? Is the code properly contained in sub-vi's for re-use? Are the states given some forethought, or just thrown out as they occurred to the developer? Can you shoot yourself in the foot by calling them in the wrong order?

The only time I've had difficulty with errors in PSM's is when they're interacting asynchronously with each other.

I'm still not particularly convinced that deep hierarchies have anything to offer besides complexity and brittleness. Do you happen to know any good references on the subject (seriously )?

Coding in C... nah, too harsh. Coding in Python is closer.

Joe Z.

[Grampa_of_Oliva_n_Eden]

... I don't think I've ever heard of a developer actually sitting down to figure out what the valid states of his application are and developing around that.

Then it is time to update your journal.

See here.

http://forums.ni.com...=257955#M257955

Ben

PS: The designs I posted in that thread just used SMs. Some before the SDE and some after.

Edited November 4, 2009 by neBulus

[crelf]

I don't think I've ever heard of a developer actually sitting down to figure out what the valid states of his application are and developing around that.

Um, I know plenty of them. That's what a state transistion diagram is for, and we use them.

Here is a dataflow implementation:

Same thing written as a state machine:

I don't like that you're suggesting that the second implementation isn't dataflow - unless you've got some hidden references, globals, etc then it *is* dataflow - you're using shift registers.

I *think* what you're argueing is that having your subVIs flat on a diagram is more intuative than a sequence machine (definition already exaplained by others in this thread), which I cautiously agree with. It makes little sense to use a state machine in this case, and I don't think there's much arguement there.

[ShaunR]

The rest: nonsense.

A procedural state machine (PSM) doesn't break dataflow (certainly not the way locals, globals, refs and property nodes do). A PSM does allow much more flexibility over how the dataflow occurs, and that admittedly does increase complexity.

I would disagree. The premis behind dataflow is that the change in value in one variable will cause a cascaded re-calculation in others. In a state machine, the change in value is dependent on "which" states and the "order" of the states that it passes through before another value is re-calculated. Whilst you may argue that "which" states is equivelent to the wired vis, with wired vis, the order is fixed by the wires and a value can only be modified by passing through a vi. The state machine releases you from the ordering restraint enabling branching backwards against dataflow.

However, saying there are too many states is like saying something is "too pink": purely stylistic. After all, changing the structure of well written code doesn't result in any less code, or necessarily any more readability. Particularly where decision making is involved.

Well. If you had ever worked for a defence company or a large corperation then there is only 1 "pink" and it has a specific RGB value.

Better criteria for state machines: Are the states well factored? Single responsibility? Grouped by purpose?Well named and well commented? Is the code properly contained in sub-vi's for re-use? Are the states given some forethought, or just thrown out as they occurred to the developer? Can you shoot yourself in the foot by calling them in the wrong order?

I would proffer that most of that is just good engineering principles. Although I'm not sure how you "group by purpose" a case statement

The only time I've had difficulty with errors in PSM's is when they're interacting asynchronously with each other.

I'm still not particularly convinced that deep hierarchies have anything to offer besides complexity and brittleness. Do you happen to know any good references on the subject (seriously )?

Not off-hand. I was brought up in a formal design environment so it became aparent to me very early on that LV was very appropriate for "top down" and "bottom up design". Those methodologies naturally yield "deep" hierarchical structure.

Coding in C... nah, too harsh. Coding in Python is closer.

Joe Z.

I don't know python so can't really comment (9 languages is enough my for tiny brain )

Um, I know plenty of them. That's what a state transistion diagram is for, and we use them.

Amen!

I don't like that you're suggesting that the second implementation isn't dataflow - unless you've got some hidden references, globals, etc then it *is* dataflow - you're using shift registers.

I *think* what you're argueing is that having your subVIs flat on a diagram is more intuative than a sequence machine (definition already exaplained by others in this thread), which I cautiously agree with. It makes little sense to use a state machine in this case, and I don't think there's much arguement there.

Indeed.

It was a rather a feeble example, since each state would only have 1 vi in it (but thats because of the hierarchal design). But it was more to demonstrate readablility.

I did try (miserably by the sounds of it) to make that clear by saying "The readablilty issue is clear" . But the point was that a state machines readability suffers from the same issues as stacked sequences.

What is your definition of dataflow? I don't think that just because shift registers are used makes it any more "dataflow" than using an "object" makes a program "object orientated".

[Grampa_of_Oliva_n_Eden]

....

...

...

...

Indeed.

It was a rather a feeble example, since each state would only have 1 vi in it (but thats because of the hierarchal design). But it was more to demonstrate readablility.

I did try (miserably by the sounds of it) to make that clear by saying "The readablilty issue is clear" . But the point was that a state machines readability suffers from the same issues as stacked sequences.

...

This is one of the reason I lamented the passing of the State Diagram Editor. I just had to right-click to bring up the SDE screen to see it in SDE form, I could watch the states transition in execution highlighting mode, and could click on the state in the SDE and the associated case was selected.

Lacking the SDE, I just paste my SD images into the BD for ready reference.

Ben

[Cat]

Lacking the SDE, I just paste my SD images into the BD for ready reference.

I've been thinking about doing this. Where do you paste the images? Off to the side somewhere? I'm thinking about wrapping a stacked sequence structure (gasp!) around the SM and putting the SD in frame0. Mostly because I really really don't like a BD being more than one (1024x768) screen.

[Grampa_of_Oliva_n_Eden]

I've been thinking about doing this. Where do you paste the images? Off to the side somewhere? I'm thinking about wrapping a stacked sequence structure (gasp!) around the SM and putting the SD in frame0. Mostly because I really really don't like a BD being more than one (1024x768) screen.

Have you been reading my posts on the Dark-Side?

This thread (on the Dark-Side)

http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=230782#M230782

shows different ways that I have documented SDs and if you read that thread that you will read that I used to work with a developer that taught me the only legitimate use of a multi-frame stacked seq structure was to include the documentation. We used to call her the "Architect Supreme" becuase she was the first person in the world to be qualified at the architect level for both LV and TestStand.

I perfer to put the code in frame "0" and the documentation if later frames to speed up execution highlighting.

Ben

[PaulG.]

STACKED SEQUENCE STRUCTURES!?

I use a ton of subVI's since my apps are usually broken down well in the documentation. I'll just cut and paste the section of documentation with the associated code. In main VI's I still like the tried-and-true method of putting a link to source documentation in the VI properties>Documentation>Help path.

[crelf]

What is your definition of dataflow? I don't think that just because shift registers are used makes it any more "dataflow" than using an "object" makes a program "object orientated".

Sure, but the use of shift registers in a sequence machine allows the data to flow between the panes. It's equivalent to the flat diagram you showed.

I've been thinking about doing this. Where do you paste the images? Off to the side somewhere? I'm thinking about wrapping a stacked sequence structure (gasp!) around the SM and putting the SD in frame0.

Put it in a Software Desgin Document (SDD). I think having images in your code bloats the VIs. That said, if you don't follow a documented design process, then maybe it's the best you can do.

This is one of the reason I lamented the passing of the State Diagram Editor.

I thought that the SDE was a good concept, but far too restrictive - it only really worked with one method of state machine, and it was one that I found limiting.

[Daklu]

I don't think I've ever heard of a developer actually sitting down to figure out what the valid states of his application are and developing around that.

Then it is time to update your journal.

Um, I know plenty of them. That's what a state transistion diagram is for, and we use them.

I should have said I've never seen a LV application that started with a state diagram. It doesn't surprise me that VIE and Ben use them; being professional development houses carries with it a different set of expectations than being an internal tool developer. Down here in the mud I just haven't seen them. I actually did try to put one together for an app I built and it turned out to be surprisingly difficult. I haven't found much information on how to best go about creating state diagrams. The examples I've seen online tend to be fairly trivial.

-----------------------

ShaunR and Daklu have me confused. I'm not sure what to ask, but I thought I was following good practices. Can you 'splain?

Well, first let me 'splain that my thoughts are driven primarily by problems I've seen in my own state machine implementations. Some of the ideas I don't like might in fact be good implementation practices... I dunno. I also don't claim to fully understand state machine theory. I've read what I can find on Moore and Mealy State Machines, as well as information on Hierarchical State Machines and various other bits of information. The pieces haven't fallen into place yet.

Sequence Machines seems to have been covered fairly well. I admit that I use them on occasion; however, I do try to make it obvious what it is by wiring a loop index into the case input, as shown below, rather than using strings or enums as inputs. (If a stacked sequence behaved like this they might not have the terrible reputation they have now.)

I use sequence machines primarily as a 'light abstraction' layer in situations where I don't necessarily want to hide what's going on in a sub vi, but I do want to encapsulate and contain the functionality for readability (or I simply need the extra room.) For example, in a current app I use a sequence machine for writing data to a file. Case 0 contains all the logic for obtaining a file reference. Case 1 retrieves and writes the test information. Following that are cases for writing column headers, iterating through and writing the data, closing the file, etc. I believe a sequence machine should be contained in a single state and not built as part of the top level state machine itself. When I have a state that always leads directly into another, predetermined state, I have to ask myself "why do I need two states here?"

What I called a 'Procedure Machine' is different, and I didn't do a very good job of explaining it. All applications have some sort of operations (procedures) they perform. A procedure machine codifies procedures in the case statements rather than states. Is that good practice? I don't really know... I do know my state machines tend to be procedure machines rather than state machines and that is reflected in the names I give my states. ("Init," "Save Data," "Exit," etc.) Intuitively a procedure isn't really a state, so my gut feeling is that I'm not doing it right.

Looking over old code I've written I see states I've built that could (should?) have been a sub vi integrated into other states rather than a unique state called as part of a sequence of states. This is bad on several counts: First, my state machine now has an extra state that unnecessarily complicates the overall application. Second, and more critical, is that I often have to implement extra code to make sure the correct states are executed after my procedure state. Just thinking out loud, but I'll bet if you use a QSM and find yourself queueing up the next several states to be executed you're working with a Procedure Machine.

Like I said earlier, I'm not particularly knowledgable in state machine best practices. I've implemented the state machine design pattern plenty of times but I've always got a nagging feeling that it's not quite right.

Are the states well factored? Single responsibility? Grouped by purpose? Well named and well commented? Is the code properly contained in sub-vi's for re-use? Are the states given some forethought, or just thrown out as they occurred to the developer? Can you shoot yourself in the foot by calling them in the wrong order?

A few of these questions really resonate with me.

• Are the states well factored?
  What makes a state well-factored? How do you decide if you've met that goal or not?
• Is the code properly contained in sub-vi's for re-use?
  What criteria do you use to decide if particular functionality should be contained in a unique state or in a sub vi which you can then use in several different states?
• Can you shoot yourself in the foot by calling them in the wrong order?
  This one sounds important. My procedure machines (and pretty much every state machine implementation I've seen) will break if you get the sequencing wrong. Is this a good indicator of a properly factored state machine?

The others, especially "single responsibility," I'm not convinced of.

[Grampa_of_Oliva_n_Eden]

I should have said I've never seen a LV application that started with a state diagram. It doesn't surprise me that VIE and Ben use them; being professional development houses carries with it a different set of expectations than being an internal tool developer. Down here in the mud I just haven't seen them. I actually did try to put one together for an app I built and it turned out to be surprisingly difficult. I haven't found much information on how to best go about creating state diagrams. The examples I've seen online tend to be fairly trivial.

...

This reply will not be of much educational use but I have to reply/confess.

I was introduced to State Diagrams when I was in the Navy and was being trained in the NATO Sea Sparrow Missle system 33 years ago (peanut tubes were being phased out, see link below).

http://www.fas.org/m...ssile/rim-7.htm

Since I was young and impresionable, I adopted that way of think without question. At that time I was only being trained to read them and not on the theory that goes into devloping them. So SD's just seem to flow such that I find it difficlut to even describe the thought process involved. So this again explains why I miss the SDE since it allowed my to express my designs in the same form as they appear in my head.

What can I offer to help use SD?

1) If your diagram is too confusing to present to the person managing the $$$, it should be simplified.

2) Any time you spot a set of state-trasnisitions that fan-out and them merge again, you have a sub-VI that warrents it own SD.

Just sharing thoughts. Please excuse the noise.

Ben

Edited November 6, 2009 by neBulus

[Cat]

Put it in a Software Desgin Document (SDD). I think having images in your code bloats the VIs. That said, if you don't follow a documented design process, then maybe it's the best you can do.

Our SDD was written 5 years ago and never updated to reflect reality. We are rarely required to do any sort of formalized design documentation -- in fact often no one wants to pay for it. I do rigorously document anywhere I interface with someone else's code, but must admit, should do a better job with my own. That's why I'm trying to figure out the best way to go about it that I will actually impliment and continue to use over the long run. 95% of what I write I write alone, so I've got to be internally motivated to deal with this.

[Grampa_of_Oliva_n_Eden]

... 95% of what I write I write alone, so I've got to be internally motivated to deal with this.

Give it a try Cat!

The first time you open a VI that you have not touched in a long time and the diagram drags the needle of your brain back to the same track it was on at development time, you'll be hooked.

Short G_Story:

A customer called me two years after I delivered an app and asked "Ben!, the app hung right after X, did the data get saved". Biring up the diagram, SD to the right state, I reply "Yes it was saved". Without the visual aids, I would have to start humming and scratching.

Ben

[Cat]

Give it a try Cat!

The first time you open a VI that you have not touched in a long time and the diagram drags the needle of your brain back to the same track it was on at development time, you'll be hooked.

I'm trying! My main concern is the years of code I have out there that has zero documentation.

But I've got A Plan. Everytime I have to reuse/rewrite some piece of code, I'm going to Do It Right as far as documentation and diagramming. Since the majority of my job is adding more features on to software I've already written, this should eventually cover the majority of my sins.