Combine While Loop and Case Structure into new "State Machine" Structure

[dthor]

First of all, I know I'm going to get a heck of a lot of flack for this idea. I know how you guys hate changes or additions to core structures

State Machines and Abortable Sequence Structures are very, very powerful. In my opinion, their only downfall is the fact that they require two structures surrounding the code: a Case Structure and a While Loop (or sometimes For Loop) surrounding that. This takes up diagram space (albeit not an absurd amount) and it is annoying when needing to resize the structures. If you add more code (and are OCD about everything matching up on the BD grid like I am), then you need to resize 2 structures instead of one.

My suggestion is to create a new structure that combines these two structures. I believe that this new structure, if implemented correctly, will reduce the number of overused stacked sequence structures by providing a simple yet intuitive core structure that offers the same functionality with more power. This new structure will also make it easier for non-programmers to become familiar with State Machines and their power.

Here is what the "State Machine" structure would replace:

      --->     becomes  --->           

The S input is a right-click option "Enable State Machine Input" which acts as a shift register and also as the case selector for the state. If "Enable State Machine Input" is disabled, then the iteration terminal i is used as the case selector. The i and Stop If True terminals are shown in every case, and the Stop If True has the option to use default if unwired (False) through another right-click menu (you can see this icon in the 1st "Abortable Sequence" structure). In my example I used an enum as the input, but any valid state machine input would work (string, DBL, boolean, etc.)

This would not be a full replacement for the original architecture: sometimes there is code that needs to be run before or after the state, on every iteration. This new structure would not be able to handle that in a nice way (you'd have to copy the code to every case, and that's just silly).

So, what does everyone think? Where are the flaws? What parts do you like?

[Philbot]

I like this idea.    The normal State Transition code has always seemed a little "forced" to me.

I'm not sure I see the use for the "I" Terminal in the State Transition Structure (why do I want to know how many times I've looped?) it's just something that needs to be moved out of the way.

However, In the Abortable Sequence it seems like the "I" terminal should be on the border of the block (like a case selector) possibly in place of your "S" terminal.  This then relates it to the selector value showing up at the top of the block.

10c

Phil.

[dthor]

While I too do not care about how many times my state machine has looped, I can guarantee that there is some code and coder out there that does care. I don't want them to have to resort to adding their own iteration code 

[EricC.]

good idea

i suggest a variation : When you create a state machine for manag hmi, it can be a littel different.

i use a array of condition because we can activate some condition by different way.

(menu file>Save; button save; test if need to save; etc.)

it be wonderful if the new struct manage this special case !

see exemple please.

[AristosQueue (NI)]

This idea is prompted by some of the "diagram maintenance" effort required to keep a clean block diagram when working on a state machine. Now, I rarely put on my NI Sales hat (my R&D hat is much more stylish), but in this case, there's a tool from NI that I think is really great and negates the need for the features this idea is proposing. The State Chart Module from National Instruments allows you to write code into a state machine-like diagram and which manages the structure nodes behind the scenes so you don't have to worry about resizing structure nodes, minimizing terminals, etc. You declare your states and the transitions between them, then you fill in the actual diagram code for each state, and LabVIEW handles translating that state diagram into an actual block diagram, and manages that diagram as you make further changes. Highlight execution shows the actual state transitions in the state diagram. And it can handle the complex transition rules that the previous post is asking about. It's pretty cool.

[dthor]

It's just too bad that I haven't been able to get my boss to sign off on that module! 

[smmarlow]

You might want to consider having the iteration and conditional terminals as part of the structure's border, rather than appearing in every frame.  The iteration terminal might be locked to the left border, the conditional terminal the right, and both might slide along the borders.  You might also consider combining the case selector and shift register graphics of the two structures into a single graphical object that would be recognizable, rather than adding a new graphical element.  This alternative might look like the following:

:

You might also consider a looping Event Structure as well.  

[Philbot]

>>  While I too do not care about how many times my state machine has looped, I can guarantee that there is some code and coder out there that does care. I don't want them to have to resort to adding their own iteration code 

I still think any data in a state block should be state specific.

OK, How about I becomes the "number of iteration in the current state". 

Resets back to zero each time the state changes.

[jmorris]

The majority of the state machines that I implement read their next state from a queue (producer/consumer model), and that falls under the "extra code that would have to be in every iteration" case mentioned in the original post, and therefore not applicable with this idea.

However, I do have multiple little state machines lying around that would still benefit from this concept.  I certainly like the idea in general; if this is such a great design model, let's make the concept more built-in rather than having to reconstruct it every time (even if we are using something like the example finder).

Would it be possible to include the concept of optional "Execute before every loop" and/or "Execute after every loop" code, either in a stacked-sequence sort of implementation, or as specially-labelled cases?  If that was built-in, it would cover the majority of situations that would otherwise not be applicable, I think.

[F._Schubert]

My major pro for this idea is, it would face 'noobs' with that concept right away from the first day.

Felix

[John_Deans]

Add an "epolde" operation that replacess the new cobined loop with the old style structure