The care and feeding of Sequence Structures

[Neville D]

Great defence Aristos! :beer: (Though elegance is sometimes preferable to performance..)

Boy, this place is beginning to feel like info-labview!

Cheers,

N.

[jgcode]

QUOTE (Aristos Queue @ Aug 22 2008, 06:17 AM)

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.

While I agree your other comments but..... I don't think a state machine should be compared to stacked sequence at all

For the following reasons (off the top of my head):

a) It is a design pattern

b) It increases readability (with an enum) - i would say that this is the most important point, seeing a large part of coding is about reading esp when doing maintainence/upgrades

c) Dataflow is not backwards as with sequence structures, as it uses USR/SR

d) It logic is scalable - although it may be sequential in operation now, later on states can be added, and logic does not have to be sequential

e) Its design pattern is scalable - without a doubt a SM + FGV (or whatever nonclementure you will to use) is one of the best design pattern I have found for creating a module (following the rules of encapsulation, loose coupling, high cohesion etc..)

[gmart]

QUOTE (Darren @ Aug 21 2008, 04:36 PM)

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.

This discussion reminds me of a NI Days presentation I did where almost every customer told me that they don't use local variables because NI "told them" not to. Instead many were using control references wired to a property node to read/write the value property. I explained that that method was much much slower in execution. Many were shocked. I stated that locals do have their place in LabVIEW code.

So the same can be said about sequence structures - flat or stacked. They are not intrinsically evil (they're just drawn that way). They are a tool that should be used properly.

So I agree with Darren and Aristos on the Three Button dialog. Yes, it could be implemented another way, but the current implementation is not an abomination. What was an abomination (please forgive me Aristos ) was what that VI looked like *before* a flat sequence was used .

[LAVA 1.0 Content]

QUOTE (mross @ Aug 21 2008, 02:14 PM)

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?

In fact the code, more correctly called the bitstream, that is running on the FPGA is more like a digital circuit diagram (think EE, not CS) , than any kind of program. So in order to preserve dataflow when converting a LV diagram to FPGA, extra code/circuitry is added so that the circuit implemented on the FPGA behaves like a LV VI. The most common part of this process is the Enable Chain. The enable chain enforces data flow from one portion of the FPGA code/circuit to the next by setting an enable flag whenever the data output of one piece of code/circuit is valid. The next piece of code/circuit will not perform its action until the input data is valid as stated by the explicit signal from the previous piece of code/circuit.

Due to the mapping of LV code to the FPGA, any wires and data associated wires take up a signficant portion of the limited FPGA circuit real estate "space", so in LV FPGA programming you always optimze your code by minimizing the amount of data on your diagram. Therefore a sequence structure is preferable to data flow if you don't need the data for something else. In addition error clusters don't exist in LV FPGA and are not an option. FPGA programmers don't make errors.

[Aristos Queue]

QUOTE (gmart @ Aug 21 2008, 06:15 PM)

What was an abomination (please forgive me Aristos ) was what that VI looked like *before* a flat sequence was used .

No offense taken. I was young, and the Stacked Sequence Structure looked so inviting.

[jgcode]

QUOTE (LV_FPGA_SE @ Aug 22 2008, 07:45 AM)

In fact the code, more correctly called the bitstream, that is running on the FPGA is more like a digital circuit diagram (think EE, not CS) , than any kind of program. So in order to preserve dataflow when converting a LV diagram to FPGA, extra code/circuitry is added so that the circuit implemented on the FPGA behaves like a LV VI. The most common part of this process is the Enable Chain. The enable chain enforces data flow from one portion of the FPGA code/circuit to the next by setting an enable flag whenever the data output of one piece of code/circuit is valid. The next piece of code/circuit will not perform its action until the input data is valid as stated by the explicit signal from the previous piece of code/circuit.

Due to the mapping of LV code to the FPGA, any wires and data associated wires take up a signficant portion of the limited FPGA circuit real estate "space", so in LV FPGA programming you always optimze your code by minimizing the amount of data on your diagram. Therefore a sequence structure is preferable to data flow if you don't need the data for something else. In addition error clusters don't exist in LV FPGA and are not an option. FPGA programmers don't make errors.

With a name like LV_FPGA_SE I was looking forward to your explaination ! :beer:

[Michael Aivaliotis]

To Aristos and the other NI folks arguing that the 3 button dialog VI is fine. All I have to say is, you just don't get it. This type of coding is not acceptable in my books regardless of how much pixie dust you sprinkle over it.

QUOTE (eaolson @ Aug 21 2008, 01:38 PM)

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

That's a valid point.

[JiMM]

QUOTE (Darren @ Aug 21 2008, 06:36 PM)

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

Somehow I don't think that the colleague that I inherited this VI from would appreciate (in BOTH definitions of the word) this conversation!

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

[mross]

Thank you, Christian. That was a very informative reply.

Mike

QUOTE (JiMM @ Aug 22 2008, 07:29 AM)

Somehow I don't think that the colleague that I inherited this VI from would appreciate (in BOTH definitions of the word) this conversation!

But each frame is documented as a number...what more could you want?

Seriously, is there a manual or something that goes with this?

Never have redactions been so enticing.

[PaulG.]

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

... The defense rests, Your Honor. ...

Not guilty. :thumbup:

QUOTE (JiMM @ Aug 22 2008, 07:29 AM)

Somehow I don't think that the colleague that I inherited this VI from would appreciate (in BOTH definitions of the word) this conversation!

MY EYES!!!

That's HIDEOUS!

[Francois Normandin]

QUOTE (PaulG. @ Aug 22 2008, 09:17 AM)

Not guilty. :thumbup:

The alternative sentences would be what? House arrest? Curfew?

Whatever the verdict, as long as he can continue working on LVOOP...

[JiMM]

QUOTE (PaulG. @ Aug 22 2008, 09:25 AM)

MY EYES!!!

That's HIDEOUS!

What made it worse was that because of differences in hardware at different stations, there were 4 customized version of the same code! Deciphering it took longer than replacing it (one version, 4 .ini files). :thumbup:

[LAVA 1.0 Content]

QUOTE (jgcode @ Aug 21 2008, 08:15 PM)

With a name like LV_FPGA_SE I was looking forward to your explaination ! :beer:

Thanks. I'm more of an Embedded Control SE now (more application focus, less product focus), but FPGA is still one of my passions.

There is more information on this topic (how LV FPGA code is converted to run on the FPGA) in this http://zone.ni.com/wv/app/doc/p/id/wv-231' target="_blank">video. The video is a bit older, but the explanation of this process is still the same. The relevant portion start at 14:05 in the video.

[crelf]

I'm so glad we broke this into a separate thread

This arguement has been going for years, so what I'd love to see is a list. I want both pros and cons for the sequence structure, which we can later make into a LabVIEWwiki article.

[Darren]

QUOTE (Michael_Aivaliotis @ Aug 22 2008, 03:08 AM)

To Aristos and the other NI folks arguing that the 3 button dialog VI is fine. All I have to say is, you just don't get it. This type of coding is not acceptable in my books regardless of how much pixie dust you sprinkle over it.

Let the record show, your honor (yes, I'm assuming Michael is the judge in this case), that I was not defending the appearance of the 3-button dialog VI, I was merely defending the use of a Flat Sequence in a UI VI. AQ made a perfect argument regarding Flat Sequence usage, and I was affirming that argument.

-D

P.S. - In his defense, though, given the huge amount of initialization required in the 3-button dialog VI, I'm curious how others would design it that it would look so different. Is the issue purely one of modularization? Would y'all be happy if he simply used more subVIs? Because regardless of how it looks, there's no way around the fact that all that code does need to run before you get to the event structure...

[Chris Davis]

QUOTE (Darren @ Aug 22 2008, 10:23 AM)

P.S. - In his defense, though, given the huge amount of initialization required in the 3-button dialog VI, I'm curious how others would design it that it would look so different. Is the issue purely one of modularization? Would y'all be happy if he simply used more subVIs? Because regardless of how it looks, there's no way around the fact that all that code does need to run before you get to the event structure...

I was also thinking that perhaps a LAVA redesign is in order. After all, we all have a known working example to go from. Perhaps a LAVA Coding challenge?

[LAVA 1.0 Content]

QUOTE (Michael_Aivaliotis @ Aug 22 2008, 04:08 AM)

To Aristos and the other NI folks arguing that the 3 button dialog VI is fine. All I have to say is, you just don't get it. This type of coding is not acceptable in my books regardless of how much pixie dust you sprinkle over it.

...

I had never looked at the code in the b-button before today and I have to side with Michael. If all of the prep work had been done using sub-VI's you would at least be able to re-use the sub-VIs in another applcation. And these could have been very handy sub-VI's at that.

Ben

[PJM_labview]

QUOTE (Chris Davis @ Aug 22 2008, 09:08 AM)

I was also thinking that perhaps a LAVA redesign is in order. After all, we all have a known working example to go from. Perhaps a LAVA Coding challenge?

I will have to side with Michael as well on this issue. The main problem about using the sequence structure is maintainability (in my opinion).

In regard to redesign, I went through the excercise a few years ago to create a "n-button dialog" vi (similar to NI 3-buttons but with more functionalities). For more info about it see this blog entry.

I used a state machine like architecture (more specifically a single loop string based queue message handler). Granted it is probably slower than Stephen implementation but I think that the flexibility and simplicity of this architecture outweigh the performance issues.

PJM

[LAVA 1.0 Content]

And before anyone post something to the effect "talk is cheap, show us the code"

I just delivered an app that had about 100-200 controls and indicators (all DSC fancy graphics) that need to update live.

I used a State Machine (State Diagram Editor, remeber that?) to code up a striaght line init before entering the main loop with the event structure.

The benifits I got from this was when I developed the other ten screens (that were variations on this theme) I was able to re-use all of the sub-VI's.

Using this approach I was able to transfer support of this application to my customer with very little training (actually none).

Ben

PS This is what the GUI looked like.

[Neville D]

QUOTE (normandinf @ Aug 22 2008, 06:28 AM)

The alternative sentences would be what? House arrest? Curfew?

Whatever the verdict, as long as he can continue working on LVOOP...

http://news.bbc.co.uk/2/hi/asia-pacific/7576240.stm' rel='nofollow' target="_blank">Re-education would be the best option

N.

[crelf]

QUOTE (neB @ Aug 22 2008, 01:34 PM)

I just delivered an app that had about 100-200 controls and indicators (all DSC fancy graphics) that need to update live... PS This is what the GUI looked like.

Preeeeetty!

Slightly Off-Topic: has anyone else used http://sine.ni.com/nips/cds/view/p/lang/en/nid/12511' target="_blank">Lookout? I did a project with it years ago, and (when used appropriately) it was a great fit...

[eaolson]

QUOTE (Darren @ Aug 22 2008, 10:23 AM)

P.S. - In his defense, though, given the huge amount of initialization required in the 3-button dialog VI, I'm curious how others would design it that it would look so different. Is the issue purely one of modularization? Would y'all be happy if he simply used more subVIs? Because regardless of how it looks, there's no way around the fact that all that code does need to run before you get to the event structure...

I think that all that big mess o' code is a good example of one of LabVIEW's greatest weaknesses: it's hard to build a GUI. Yes, there are lots of great, feature-rich widgets, but it's really hard to put them together in a meaningful way. Compare with Java's http://en.wikipedia.org/wiki/Swing_%28Java%29' rel='nofollow' target="_blank">Swing, for example, then realize that Java is 40% younger than LabVIEW. A simple, four-element window just shouldn't have to build its own layout manager from scratch.

[Aristos Queue]

QUOTE (eaolson @ Aug 22 2008, 04:13 PM)

Compare with Java's http://en.wikipedia.org/wiki/Swing_%28Java%29' rel='nofollow' target="_blank">Swing, for example, then realize that Java is 40% younger than LabVIEW.

Being younger is a major advantage in this regard... no one had the idea of layout managers when LV first started creating user interfaces.

But your point that it is too hard to do GUI layout in LV is well known and a topic of frequent thought around R&D.

[JDave]

Regarding 3-Button Dialog:

I must say that the issue of performance is somewhat out of place when it is specifically stated that the 3-Button Dialog is a UI. Performance is really important for the work code that crunches in the background. But I have always heard that when it comes to user interfaces, maintainability and speed of programming is always more important than speed of execution. Is the user really going to notice the extra 20 milliseconds?

David

[Mark Balla]

QUOTE (Chris Davis @ Aug 22 2008, 11:08 AM)

I was also thinking that perhaps a LAVA redesign is in order. After all, we all have a known working example to go from. Perhaps a LAVA Coding challenge?

You Read my mind.

A New Coding Chalenge has been Created. http://forums.lavag.org/REWRITE-the-3-BUTTON-DIALOGVI-Coding-Challenge-t11789.html&view=findpost&p=50830' target="_blank">See Here