LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Remove the stacked sequence structure from LabVIEW.

Perhaps NI should have removed the sequence structure altogether.  I am aware of the conversion from flat to stacked - however converting from one to another is not exactly efficient.  There are a lot of applications already written that require maintenance and update and despite the strives for improvements in coding practice maintaining such code is necessary.  This means conforming to aspects of the code that may be a little passe - such as stacked sequences.  Like with many things, programming goes through changes and what was considered good practice in the past is reviewed and altered with hindsight.  History dictates that what may be prescribed as the best approach today is likely to be thought of as short sighted tomorrow.

0 Kudos
Message 61 of 195
(1,453 Views)

Yeah - but they have.  At least hidden it.

 

Smiley Frustrated

0 Kudos
Message 62 of 195
(1,449 Views)

Again, I see all manner of dogmatic vituperation against a structure that has been there since day one.

 

But the posts all fail (well, I didn't read every single one, I admit) to point out what problems this alleged demon causes.  There is a whole lot of nodding in agreement, but I have yet to see a good explanation of the "problem".

 

I've using stacked sequences since LV 2,0 and don't have a single problem with them.

 

I don't have a problem with sequence locals.

 

I like the idea of shift registers in them, but that's a new idea, not an old problem.

 

This is just to point out to NI, that not everybody agrees with all this dogma.

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 63 of 195
(1,405 Views)

I will admit that I have nothing against the Stacked Sequence Structure itself.  But it is the abuse that newbies use it with.  They jump to the sequence structure and local variables instead of data flow.  And I have ran into a TON of problems trying to debug code that was based on the SSS.  Most of these I was able to make a lot easier to read/debug by removing the SSS and using actual data flow.  They became a lot more efficient too.

 

Yes, there is a use for it.  But it is rare that I would ever actually use one.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 64 of 195
(1,396 Views)

Obvously for backwards compatibility NI can not remove the stacked sequence, but they could deprecate it.

 

Place it in a submenu like they did with VISA open and close. Maybe they should have a "deprecated" catagory in the functions menu.

 

Also stop teaching it beyond what it is for and why it is not recomended.

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 65 of 195
(1,385 Views)

We do need the SSS for LabVIEW FPGA though right. Atleast in 2012 and 2013, LabVIEW did not support data flow via Error clusters for FPGA codes.

 

I do agree with majority of the crowd here. Absolutely detest SL. 


Kudos are the best way to say thanks 🙂
0 Kudos
Message 66 of 195
(1,379 Views)

@Stel wrote:

The removal of the stacked sequence from the palette is something I do not understand.  Those that wish to use it can and those who do not wish to use it can just leave it alone.  It is a useful space-saving format - the only reason why one might not like it is that they might lose sight of what is in the lower layers. In my opinion such individuals need to improve their documentation techniques rather than winge about aspects of the LV environment that can be left alone, and which have no bearing on their productivity - such that it is.


Palette bloat is a problem, so why should we have two different types of sequences if they both do the same thing?

 

Both start out with a single frame, so the initial placement is indentical for both and involves exactly the same mechanics. It is just a "sequence", and one frame is often enough. As Gerd already said, at this point you can now immediately convert it to a stacked sequence and go on coding as before. The SSS is still a fully supported structure (as a sub-form of the generic sequence structure).

 

The time wasted on that little extra step is insignificant, especially since you saved time selecting the structure from a smaller and concise palette without the confusion of near duplicate structures. 😄

 

The SSS is a leftover from a time where most monitors were 640x480 pixels.

0 Kudos
Message 67 of 195
(1,357 Views)

 at this point you can now immediately convert it to a stacked sequence and go on coding as before. 

 

How about making it a user preference?  Make one sequence in the palette.  If you checked "I don't like stacked sequences" in the options table, then you get a flat one.  If you checked "I don't have a problem with stacked sequences", then you get a stacked one.

 

You can still convert, if need be.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 68 of 195
(1,349 Views)

@CoastalMaineBird wrote:

Again, I see all manner of dogmatic vituperation against a structure that has been there since day one.

 

But the posts all fail (well, I didn't read every single one, I admit) to point out what problems this alleged demon causes.  There is a whole lot of nodding in agreement, but I have yet to see a good explanation of the "problem".

 

I've using stacked sequences since LV 2,0 and don't have a single problem with them.

 


You said a lot in this post, but didn't really say anything.  You enjoy the SSS.  But, what is it about the SSS that you find so incredibly useful?  It's a bit hypocritical to claim others aren't describing why they hate it well enough to your taste while you offer no reasoning for why you enjoy it.

 

Here's where I see it as a problem.  There are VERY few use cases where it actually makes sense.  But, a decent sized portion of the LabVIEW users are not experienced programmers.  In an attempt to force things to happen deterministically, they look for the first structure they find that executes in order.  They use the SSS in places where it simply doesn't make sense and tends to complicate their code.  To get around these complications, they start adding more poor decisions to their code.  Then, it becomes frustrating for them to deal with and they seek help. At this point, the code is a mess for anyone to debug.  The SSS enables bad programming. 

 

Programmers that are experienced enough to understand the few use cases for the SSS are also experienced enough to solve their issues quickly without the SSS.  A small state machine can handle any use case I can think of with little effort required for an experienced programmer.  That same programmer likely has experienced more frustration helping someone debug their code with a poorly used SSS than they ever alievate by using the SSS in their own code.  When the net gain from the SSS is a negative value, it's generally a bad idea.

 

You say you've been using them since LabVIEW 2.0 without a problem.  Would you have had any problem without them existing?  Were they necessary for the application you were using or were they just one possible way to do what you wanted, without evaluating whether they would have been more or less efficient than the alternative solutions?

 

It's a tad silly to dismiss the other opinion as "dogma" when both points of view are primarily opinion.

0 Kudos
Message 69 of 195
(1,327 Views)

The idea of user configurable palettes is a good one for two reasons -

 

(1) users could set up their preferences to improve their work efficiency, and in this way palettes could be configured specifically for projects, old and new.

 

(2) newly developed items by NI could be released retrospectively for older versions of LV and added to palettes, so that improved functionality could be added to projects written in older versions without the need to move the entire project to the most current platform

 

0 Kudos
Message 70 of 195
(1,301 Views)