State machine architecture

[newman3108]

Hi, im still pretty new to labview, I have built a program that is functional just wondering how to make it better and more efficient. Someone told me to use a state machine architecture with my program but not too sure how to implement it/ if it would be beneficial.

Thanks 

[wiebe@CARYA]

18 is pretty new. You might get better\faster response if you save to a previous version (or even a screenshot).

[crossrulz]

First of all read this: Application Design Patterns: State Machines

Secondly, start by thinking about the stages your code goes through.  I immediately see "Start up", "Initialize Equipment", "Shutdown". "Take Readings", "Adjust Current".  I would also add a state with a dialog to let the user input the desired settings instead of waiting for the start button to be pressed.

[newman3108]

what are the benefits of doing this? Essentially just rearranging my program.

[wiebe@CARYA]

---

@newman3108 wrote:

what are the benefits of doing this? Essentially just rearranging my program.

---

The computer couldn't care less of course how things are arranged. "It works, why bother?" is heard often. But that "it works" for the computer (it does what it is told) doesn't mean "it works" for (other) programmers.

In general, rearrangements are useful if the changed code better reflect 'reality'. Afterwards, it better tell (other) programmers what the program is doing. It becomes more 'self documenting' (although it should of course follow from a design and be documented).

This is only important if you care about maintainability, readability, documentability (is that a word?), traceability, and programmers, including (future) you...

[mcduff]

---

@newman3108 wrote:

what are the benefits of doing this? Essentially just rearranging my program.

---

The biggest benefit, in my opinion, it is easier to maintain and add features for the inevitable code creep.

Most LabVIEW examples go through a series of Init, Set, Get, etc, all in a linear fashion. Not being a programmer, that is how I modeled my first programs. You hit the run arrow button and let the program go. It was always through the IDE interface, never an exe. In fact, it took me a few years to realize LabVIEW could make exes, I thought everything went through the IDE.

Those programs worked, but were a pain to modify. If you have a case structure with a bunch of states, it is much easier to modify the execution order of the states, and add/remove states. It is also easier to turn that type of architecture into an exe.

mcduff

[RTSLVU]

---

@newman3108 wrote:

what are the benefits of doing this? Essentially just rearranging my program.

---

Because someday sometime in the future someone might have to expand on your program.

And that someone could be YOU!

By using a proper architecture from the start, it makes scaling up or adding features a lot easier

[wiebe@CARYA]

In retrospect, I haven't made a state machine in years. It's not the holy grail of architecture, but it is a nice 'step in' architecture.

Usually, a SM turns out to be a) an event driven loop or b) a sequence. If it is a sequence, I don't want to implement a SM but a sequence (not a FSS\SSS of course), for the same reason that when it is a SM I don't want to implement a bunch of loose code but a SM...

If I really need SM-like functionality, I go for the OO state pattern nowadays. Disclaimer: not the easiest OO pattern...

[ikaiser]

One thing not mentioned yet: Normal LabVIEW code is just sequential - you program things to happen one piece after another - Part1 (P1), P2, P3, P4 etc..

If your code shall react on things while running, and then decide what part to execute next (either a result of an calculation or a button pressed), you need a state-machine architecture. This allows arbitrary reordering at run-time, e.g. P1, P2, P2, P3, P1, P4, etc...

[wiebe@CARYA]

---

@ikaiser wrote:

If your code shall react on things while running, and then decide what part to execute next (either a result of an calculation or a button pressed), you need a state-machine architecture. This allows arbitrary reordering at run-time, e.g. P1, P2, P2, P3, P1, P4, etc...

---

'Need' is a bit strong. I do well without SMs. But if that is the situation, a SM would be a good fit.

Alternatively, you could simply put an event structure in a loop, skipping the traditional SM case structure and enum all together.

If P1, P2, P3 and P4 are not states, but VIs (or better: class methods), an event can simply call those VIs in the desired sequence... No more states required! At least not 'states' as in a traditional state machine. Or 'fake' states can be called with a user event or value signaling event.

An event structure in a while loop is of course still some sort of SM, as it is a 'machine', and has 'state' (classes or clusters in shift registers). But traditionally, a LabVIEW state machine is a case in a loop, and an type def enum to switch state.