The care and feeding of Sequence Structures

[eaolson]

Over at some other thread, crelf said, " I strongly suggest that this topic go to a new thread." And, lo, there was a new thread.

So when is it a good and bad idea to use a sequence structure? Should they be banned outright? Even removed from the language? Personally, I think they should be discouraged, are often bad style, but are occasionally necessary.

Just the other day, I wrote this:

I genuinely don't see any way to guarantee proper execution order without the sequence structure. I usually find the only time I ever use them is when I'm using a LabVIEW node where I can't enforce data flow any other way, e.g. with Wait.

[Omar Mussa]

QUOTE (eaolson @ Aug 21 2008, 08:08 AM)

Over at some other thread, crelf said, " I strongly suggest that this topic go to a new thread." And, lo, there was a new thread.

So when is it a good and bad idea to use a sequence structure? Should they be ?

The are occasionally necessary to help enforce data flow. For this reason alone, they should not be banned. But they should be avoided for almost all other cases in my opinion due to their inflexibility.

[Tom Bress]

QUOTE (eaolson @ Aug 21 2008, 11:08 AM)

Over at some other thread, crelf said, " I strongly suggest that this topic go to a new thread." And, lo, there was a new thread.

So when is it a good and bad idea to use a sequence structure? Should they be ? Even ? Personally, I think they should be discouraged, are often bad style, but are occasionally necessary.

genuinely don't see any way to guarantee proper execution order without the sequence structure. I usually find the only time I ever use them is when I'm using a LabVIEW node where I can't enforce data flow any other way, e.g. with Wait.

I typically take the offending non-error-propagating native function and wrap it in a sub-vi wrapper that has error cluster propagation, like the OpenG Wait function. Then I can use it in the future as well without resorting to sequence structures.

[PaulG.]

Occasionally I will run an output from a subVI into a single frame sequence in order to probe it. STACKED sequences, on the other hand, should be banned outright!

[Val Brown]

QUOTE (Tom Bress @ Aug 21 2008, 08:46 AM)

I typically take the offending non-error-propagating native function and wrap it in a sub-vi wrapper that has error cluster propagation, like the OpenG Wait function. Then I can use it in the future as well without resorting to sequence structures.

I favor this approach as well. In prior versions (LV 5 maybe 6) there were rumors of extra overhead when using this kind of process instead of sequence structures but I don't think the overhead of a sub-vi call is an issue any longer.

[TobyD]

QUOTE (eaolson @ Aug 21 2008, 08:08 AM)

I genuinely don't see any way to guarantee proper execution order without the sequence structure. I usually find the only time I ever use them is when I'm using a LabVIEW node where I can't enforce data flow any other way, e.g. with Wait.

I agree with Tom on this one. It's would be best to wrap it as a subVI, but if you insist on using the sequence structure there is still no need to wrap everything. It is only necessary to place the "offending non-error-propagating native function" inside the sequence structure.

http://lavag.org/old_files/monthly_08_2008/post-8758-1219335175.png' target="_blank">

[mross]

QUOTE (TobyD @ Aug 21 2008, 12:13 PM)

I agree with Tom on this one. It's would be best to wrap it as a subVI, but if you insist on using the sequence structure there is still no need to wrap everything. It is only necessary to place the "offending non-error-propagating native function" inside the sequence structure.

http://lavag.org/old_files/monthly_08_2008/post-8758-1219335175.png' target="_blank">

I don't see why this is any better or worse.

The sequence as used by eaolson has none of the problems associated with sequences, it is simple, it obscures nothing, it saves time in wiring, it doesn't take up useless space, so there is no reason to ban it. Making a wrapper is just anal if there is no re-use planned.

I am betting we all know a bad use of the sequence structure when we see one, this isn't egregious by any means.

I don't use real time so i can't comment about that.

[David Wisti]

If your an FPGA programmer, you know sequence structures are not going anywhere. Having a sequence structure to enforce dataflow uses less space on the FPGA.

[LAVA 1.0 Content]

I still use multi-frame flat seq structure for benchmarking (get time - test - get time). Under most cicumstances the time required to pass an error cluster is small but if I'm trying time something that takes as much time as it takes to pass the error cluster, then it will be hard to determine how much time was taken by each.

And before we get off on another tangent...

I have managed to measure the time difference between using a sub-VI with "extra" connectors and an identicle VI with no "extra" connectors, so for my work, it does make a difference.

Ben

[mross]

QUOTE (David Wisti @ Aug 21 2008, 12:29 PM)

If your an FPGA programmer, you know sequence structures are not going anywhere. Having a sequence structure to enforce dataflow uses less space on the FPGA.

Perahps I will expose my ignorance now, but it won't be the first time...

Are you saying that wires don't work the same way for FPGA?

One generally doesn't "enforce dataflow," one lets it happen, because that is better.

Is this no longer true in FPGA and if so how does FPGA work and why should it be treated differently than "regular" LabVIEW programming which benefits from data flow, not sequencing.

Mike

[TobyD]

QUOTE (mross @ Aug 21 2008, 09:25 AM)

I don't see why this is any better or worse.

I agree that in this example it makes little difference, but I think we have all seen examples where a large vi will be completely "sequence structured" so that a single vi can run at the proper time. Generally this method of wrapping a single vi in a sequence structure is less intrusive to the block diagram and still forces the programmer to be conscious of dataflow in the rest of the program.

[jpdrolet]

When the main loop of a VI doesn't require a state machine, I often put a three frame flat sequence structure |init|doit|exit| even when I could use data flow. That clearly separates the code that doesn't belong to the main work of the VI. However, if the VI requires a state machine, I use init and exit states.

[David Wisti]

QUOTE (mross @ Aug 21 2008, 12:36 PM)

Perahps I will expose my ignorance now, but it won't be the first time...

Are you saying that wires don't work the same way for FPGA?

One generally doesn't "enforce dataflow," one lets it happen, because that is better.

Is this no longer true in FPGA and if so how does FPGA work and why should it be treated differently than "regular" LabVIEW programming which benefits from data flow, not sequencing.

Mike

Wires work the same in fpga. But, if you have a situation where dataflow needs to be enforced, creating a wire and a corresponding data type and in/out terminals would take more FPGA space then just the enable string of a sequence structure. In FPGA, you could be trying to implement your code in the smallest footprint. Using sequence structures would allow you to optimize for size.

[mross]

QUOTE (David Wisti @ Aug 21 2008, 01:12 PM)

Wires work the same in fpga. But, if you have a situation where dataflow needs to be enforced, creating a wire and a corresponding data type and in/out terminals would take more FPGA space then just the enable string of a sequence structure. In FPGA, you could be trying to implement your code in the smallest footprint. Using sequence structures would allow you to optimize for size.

you said:

"a wire and a corresponding data type and in/out terminals would take more FPGA space then just the enable string of a sequence structure."

Just what is this "space" you are talking about? Screen space? The space of available gates? My first thought is that you mean visual real estate on a block diagram.

Is this text programming? Like I said I don't savvy FPGA. I thought FPGA were programmed on a big monitor where wires and sequence structres mean the same thing as they do for regular DAQ equipment and programming. I have no idea what the "enable string of a sequence struture" might be.

Mike

[John Lokanis]

There is always a way to avoid the sequence structure...

[PJM_labview]

QUOTE (mross @ Aug 21 2008, 10:46 AM)

you said:

"a wire and a corresponding data type and in/out terminals would take more FPGA space then just the enable string of a sequence structure."

Just what is this "space" you are talking about? Screen space? The space of available gates? My first thought is that you mean visual real estate on a block diagram.

Is this text programming? Like I said I don't savvy FPGA. I thought FPGA were programmed on a big monitor where wires and sequence structres mean the same thing as they do for regular DAQ equipment and programming. I have no idea what the "enable string of a sequence struture" might be.

Mike

I believe he his talking about space on the FPGA. From what I recall from a training I got on this topic (and this was a while ago), usage of sequence structure is "recommended" when creating code for the FPGA because it will result in more optimized code deployed on the target.

PJM

[Aristos Queue]

The Sequence Structure and Flat Sequence Structure should be placed in a restricted palette that can only be accessed with a security code that is given to you when you complete LV Intermediate. It would also automatically unlock after you have been using LV for one year.

I'm joking, of course, but my point is that sequences are something that should never be used until you know enough to know when they should be used.

[LAVA 1.0 Content]

Back to the topic of seq frames...

I also use them when I am preparing to create a sub-VI. I can wire up all of the inputs that I will need in the sub-VI to the seq frame and then create a sub-VI from the seq frame. This gets all of my controls on the FP of the sub-VI. But after I create the sub-VI I remove the seq frame.

Another case...

I had out-lawed multi-frame stacked seq structures in our shop until I saw how another developer had used a two frame seq structure. She put all of the code in the first frame and she pasted an image of the code's design in the second. This was really clever since all I had to do was reach up and switch frames to refernce her design.

Ben

[Neville D]

QUOTE (Aristos Queue @ Aug 21 2008, 11:36 AM)

I'm joking, of course, but my point is that sequences are something that should never be used until you know enough to know when they should be used.

Heheh... like the http://forums.lavag.org/3-button-dialog-improvement-t2160.html' target="_blank">3-button dialog VI..

Neville.

[mross]

QUOTE (PJM_labview @ Aug 21 2008, 02:01 PM)

I believe he his talking about space on the FPGA. From what I recall from a training I got on this topic (and this was a while ago), usage of sequence structure is "recommended" when creating code for the FPGA because it will result in more optimized code deployed on the target.

PJM

I think get it, we have apples and anchors here? FPGA is not compiled code that is optimized to use dataflow. It is just straight up sequences and go to's?

QUOTE (Neville D @ Aug 21 2008, 02:47 PM)

Heheh... like the

3-button dialog VI

..

Neville.

That is classic. You could delete the sequence and lose nothing, and it adds nothing functionally. So the value added by the effort to apply the structure and work around inside it is purely theorectical. It is more graphic art than programming.

At least it is documented with notes. Come to think of it text notes could replace the sequence, just pull them out to big rectangles and move everything else in font of them.

I think subVis would have been more appropriate.

[Michael Aivaliotis]

QUOTE (neB @ Aug 21 2008, 11:37 AM)

I had out-lawed multi-frame stacked seq structures in our shop until I saw how another developer had used a two frame seq structure. She put all of the code in the first frame and she pasted an image of the code's design in the second. This was really clever since all I had to do was reach up and switch frames to refernce her design.

Not very practical. You can't view the code and the design side-by-side making it very limited.

QUOTE (eaolson @ Aug 21 2008, 08:08 AM)

Just the other day, I wrote this:

Actually, I don't see the point in all that code before the exit. You are exiting. Hiding the panel makes no difference. Just put the exit and that's it. Simplify.

[eaolson]

QUOTE (Michael_Aivaliotis @ Aug 21 2008, 02:51 PM)

Actually, I don't see the point in all that code before the exit. You are exiting. Hiding the panel makes no difference. Just put the exit and that's it. Simplify.

Nope, in fact I went back into that VI and added that code for a reason. It's in a fairly simple application I'm building that will be compiled to an executable. The top-level VI does not display the menu bar or the tool bar (and therefore, it doesn't display the VI icon, either). If you just use Exit, what happens when the VI stops is that (a) the VI stops, (b) the tool bar, menu bar, and icon are redisplayed, and ( c) then the VI window closes. That means that closing the VI or some programmatic closing of the VI causes the window to flicker and resize itself before it closes. I found that unattractive and possibly confusing. It also draws attention to the fact that this is a program written in LabVIEW. (Not inherently bad, just unecessary.)

So this version first hides the window from view, then closes it, and there is no flickering issue.

[Aristos Queue]

I wrote the three-button-dialog... and I don't mind talking about it...

First I'm going to make a small technical correction to a previous comment, and then I'm going to make an Inflammatory Declaration.

First the correction:

QUOTE

That is classic. You could delete the sequence and lose nothing, and it adds nothing functionally. So the value added by the effort to apply the structure and work around inside it is purely theorectical. It is more graphic art than programming.

Actually, if you simply remove the sequence, you would get different behavior. You would need to wire a lot of error cluster wires that are currently missing and you would need to change the local variable that writes to "message" into a Value propoerty. So to be clear, it is currently adding functionality, but it is functionality that could be obtained otherwise.

Ok... with that out of the way, let me move on to the real reason you're all still reading this post...

Now, recall that I did say this is a VI I wrote eight years ago, one of the first VIs I ever implemented. I used the stacked sequence in the first version without questioning its use. I used a lot of sequence structures at first, and most of those have been removed as the years have gone by. I would now consider more carefully before deciding to use a flat sequence structure. And, so, with careful consideration, here is my inflammatory declaration:

I believe that this dialog is an appropriate use of a flat sequence structure.

And now, in this brief time while crelf, gmartinez and the other Guardians Of Diagrams (G.O.D.) are sharpening their machetes and prepping their missile salvos, let me present my defense...

Part 1: Alternate implementations

Three alternate implementations of this diagram have been proposed.

1. SubVIs
   
2. State Machine
   
3. Just wiring all the error clusters
   

Regarding SubVIs:

QUOTE

I think subVis would have been more appropriate.

It is UI code on tightly linked property/method nodes. Creating subVIs would construct a nest of control references going into a subVI, definitely less readable than the code as it stands today. I don't think that would be more appropriate at all.

Regarding State Machine:

QUOTE (Michael_Aivaliotis @ Oct 24 2005, 05:25 PM)

Hasn't NI learned about the state machine?

I've actually given some thought to Michael's suggestion made back in 2005 about how this should be a state machine. I've come to the conclusion that if the sequence structure is bad then the state machine is worse. Why? Because in this case the state machine would be nothing more than a stacked sequence structure with more runtime overhead. If a flat sequence structure is considered better than a stacked sequence for readability, then turning the sequence into a case structure is a step backwards. And because the cases run in the same sequential order every time, then you've added the overhead of the while loop and the case selection without any benefit.

Regarding Wiring All The Error Code Clusters:

So from a "clean code" point of view, it seems that the only correct solution is to wire all the error cluster wires to enforce dataflow everywhere. We might then draw picturesque boxes around parts that are related for documentation purposes. I have no objections to this implementation. I think it would be fine for this diagram to have been implemented that way.

Part II: Why The Flat Sequence Is Better Even If All The Error Terminals Were Wired

So if I've conceded that wiring the error code clusters would be a fine implementation, isn't this discussion over? We found an acceptable alternative to the flat sequence. Case closed, right? No. Even if you wired all the error clusters, I think there would still be value to having the flat sequence around in this case.

1. The minor reason not to use flat sequence structures is that they lead to code that runs off the side of the screen. However, as noted above, the only "good" implementation of this VI is one where all the error code clusters are wired and we still end up with a long string of code that runs off the side of the screen. So the minor negative is going to be encountered one way or another.
   
2. The major reason not to use sequence structures is very clear -- it eliminates the ability of the compiler to take advantage of natural dataflow parallelism. It is a performance penalty. That isn't happening in this case. In every individual frame of the structure, there is stuff that is allowed to go on in parallel. But none of it can be made parallel because all of it is in the UI thread. Every property/method node on a control requires the UI thread. There cannot be any parallel advantage when doing UI programming. So the use of the flat sequence takes nothing away from the diagram. Indeed, if anything is wrong with this VI, it is that the VI itself is not marked as having the UI thread as its prefered execution system. It might run faster if we said, "just force the whole thing into the UI thread". LV's compiler might be making that choice for us anyway given the high number of property nodes.
   
3. The value of the flat sequence is when you are editing this diagram.
   1. 
      
   2. Suppose we drew rectangles around related sections of code for documentation purposes. Those rectangles would drift as you work and may not stay lined up around the nodes that they were first put around. The flat sequence delimits regions of the code in a way that it is part of the diagram.
      
   3. You really find value in the flat sequence when you need to remove a section of the code. When you're adding code to the diagram, you can use ctrl+drag to make space. But there's no remove space unless you use the new 8.6 diagram clean up tool, but that tool has its own rules for what clean means, and those rules may not be ones that you like. The diagram cleanup tool is meant for disasterous VIs that need *some* order brought to them, not for essentially orderly VIs that you're just trying to adjust. Now, if we were using a state machine with the attendent case structure, we would also have this advantage. But as I said above, the case machine hides code and adds overhead, both for no benefit. A previous post called the flat sequence on this diagram little more than graphic art. Yes. But it is *functional* graphic art to the artist.
      

So, in summary, I claim that

a) The only good alternative implementation has the same code-runs-off-the-right-side-of-screen issue that the flat sequence has

b) the usual negatives of the flat sequence do not apply and

c) the editing behavior of the flat sequence provides a positive.

Thus it is correct and acceptable to use a flat sequence in this VI.

The defense rests, Your Honor.

[Darren]

QUOTE (Aristos Queue @ Aug 21 2008, 05:17 PM)

The defense rests, Your Honor.

Not so fast...before the defense rests, you should call your first witness, Darren, who has advocated Flat Sequences as a perfectly legitimate UI programming structure for many years (when was the 7.0 release?), for the very reasons you have cited.

-D

P.S. - Stacked Sequences, however, are pure evil. Just want to make sure there's no question on that.

[jgcode]

QUOTE (mross @ Aug 22 2008, 01:46 AM)

you said:

"a wire and a corresponding data type and in/out terminals would take more FPGA space then just the enable string of a sequence structure."

Just what is this "space" you are talking about? Screen space? The space of available gates? My first thought is that you mean visual real estate on a block diagram.

Is this text programming? Like I said I don't savvy FPGA. I thought FPGA were programmed on a big monitor where wires and sequence structres mean the same thing as they do for regular DAQ equipment and programming. I have no idea what the "enable string of a sequence struture" might be.

Mike

Another great point that FPGA uses them alot.

Check out the demos in Example Finder, if you can, and you will see that when you are programming nodes on the FPGA, flat sequence structures are used alot.