Jump to content

The care and feeding of Sequence Structures


Recommended Posts

  • Replies 61
  • Created
  • Last Reply

Top Posters In This Topic

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..)

Link to comment

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 :unsure: ) was what that VI looked like *before* a flat sequence was used :o .

Link to comment

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. ;)

Link to comment

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:

Link to comment

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.

Link to comment

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.

Link to comment

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

MY EYES!!! :blink:

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:

Link to comment

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...

Link to comment

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?

Link to comment

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

Link to comment

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

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.

post-29-1219426422.png?width=400

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.

post-29-1219426406.png?width=400

Link to comment

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

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.

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.