What should you use instead of sequences to control execution?

[Knoebel]

I noticed while reading the message board that many of the senior programmers are denouncing the use of sequences. Not being a true programmer, how do I avoid the use of sequences  to control the flow of execution? In the program provided a calibration is being taken on multipe data points.

1. I ask the user to input a concentration.

2. After that the next vi runs without a data flow connection from the first and prompts the user to start the calibration for that data point (I want to use a separate popup box for the start)

3. Data is collected for the calibration point.once the start button is pressed.

4. The process repeats until all calibration points have data collected for them.

The program works, but I'm interested in writing better code. Your comments are appreciated.

[smercurio_fc]

The easiest way to do this is to have VIs with error in/error out clusters. By wiring the error out from one to the error in of the next you've established data dependency, so the second VI has to wait until the first one is done.

This, of course, has the added benefit of writing VIs with error handling should they be needed in the future.


Message Edited by smercurio_fc on 07-11-2008 10:07 AM

[jon_mcbee]

You should acquaint yourself with the statemachine.  Open LabVIEW>>File>>New>>VI>>From Template>>Frameworks>>Design Patterns>>Standard State Machine

Do a search on the forum for statemachine and you should be able to find plenty of literature.

[smercurio_fc]

Good point. That's a more general answer in terms of process execution. I was answering the specific question of VI execution and how to force certain VIs to execute only until another VI has executed.

[Knoebel]

Isn't a statemachine like a sequence on roids? It gives the the option of where to enter and exit the sequence and how to navigate between panes in the sequence. Where as the sequence is more like a chronological order of execution.

[jon_mcbee]

A statemachine doesnt use a single sequence frame, it is a basically a case structure wrapped up in a while loop with with a type def enum holding all available states wired to the case structure.  I dont know if that is equivalent to a flat sequence on steroids or not, possibly on human growth hormones.  Either way, it is a very accepted architecture that should be evoked when needed.  There are also a few bells and whistles that can be added such as a statemachine being driven by events, a statemachine that makes use of a queue...   Regardless of whether or not it is needed for your current app it should be added to your tool box for future use.


Check this page out for more info





Message Edited by jmcbee on 07-11-2008 10:01 AM

[Knoebel]

So based on what your saying, for complex tasks or tasks beyound simple, state machines are the way to go. For simple chronological order, do this then this, a sequence is a good way of doing something.

[jon_mcbee]

For simple chronological order I recommend following Smercurio_FC's post above,

 "The easiest way to do this is to have VIs with error in/error out clusters. By wiring the error out from one to the error in of the next you've established data dependency, so the second VI has to wait until the first one is done.

This, of course, has the added benefit of writing VIs with error handling should they be needed in the future."

Of course sometimes you have to use a function that does not have an error wire included.  There are two ways to handle this.  Either use one frame of a flat structure to enforce the left to right data flow, or wrap the function up in a subvi and include error in and out in that subvi.  I usually go with the subvi as the subvi's icon is a good way to document what is going on.

[smercurio_fc]

---

@Knoebel wrote:
So based on what your saying, for complex tasks or tasks beyound simple, state machines are the way to go. For simple chronological order, do this then this, a sequence is a good way of doing something.

---

Yes to the first, no to the second. Or rather, depends on what you mean by "simple". Part of this has to deal with history. There used to be only one kind of sequence structure: the Stacked Sequence. This has the side-effect of hiding code, and it was over-abused. Thus came the backlash that "sequence frames are evil". NI responded by introducing the Flat Sequence. Purists are never happy, so that was still no good. The "sequence frames are evil" flag kept waving. Personally, I don't buy into that. That said, I avoid sequence frames because I always tend to try to write my VIs with error in/error out unless they are very simple utility functions. 

[Ray.R]

Very well said smercurio.

I'm actually glad that people read what we post and it has an impact. 🙂

Nothing in coding is evil by nature.  People make them evil by constant abuse & overabuse to the point where it takes longer to read the code than to code a solution from scratch.

Concerning Stacked Sequences, I would say that 90% of the code I am called to "fix" or simply add one more feature have them. And they are always 2 screens wide by 2 screens tall.  Most of the time, they have just a little bit of code, like a delay by itself, or one sub-vi surrounded by Local Variables.  You can't follow the code!  Furthermore, I've seen people place a single object at the various corners, randomnly, as if to justify the mamouth sized sequence structure.

I don't like Stacked Sequences and I do not hide that fact.  They should be removed.  I have never seen someone use them appropriately.    I abused them earlier in my coding days just as everyone else..  I'm ashamed of that code...   so we won't go into that..  😉

The State Machine is not necessarily the answer to all VI's.  It depends what you want to do.  It depends on how the sw is expected to behave.  So characterizing how the software behaves plays a large role on how it will be architectured.  Nonetheless, it will often the the architecture of choice.  Another point of influence is how familiar the programmer is with a given architecture or coding style.

R