The care and feeding of Sequence Structures
#1
Posted 22 August 2008 - 04:29 PM
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.
#2
Posted 22 August 2008 - 04:48 PM
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?
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.
#3
Posted 22 August 2008 - 05:07 PM
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.
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.
#4
Posted 22 August 2008 - 05:15 PM
#5
Posted 22 August 2008 - 05:17 PM
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.
#6
Posted 22 August 2008 - 05:34 PM
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.
#7
Posted 22 August 2008 - 05:46 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.
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.
#8
Posted 22 August 2008 - 05:50 PM
#9
Posted 22 August 2008 - 05:56 PM
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
#10
Posted 22 August 2008 - 05:57 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
#11
Posted 22 August 2008 - 06:17 PM
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.
#12
Posted 22 August 2008 - 06:25 PM
#13
Posted 22 August 2008 - 06:33 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.
#14
Posted 22 August 2008 - 07:07 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
#15
Posted 22 August 2008 - 07:21 PM
#16
Posted 22 August 2008 - 07:22 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.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
PJM
#17
Posted 22 August 2008 - 07:57 PM
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.
#18
Posted 22 August 2008 - 07:58 PM
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
#19
Posted 22 August 2008 - 08:08 PM
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 3-button dialog VI..
Neville.
#20
Posted 22 August 2008 - 08:35 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.















