Shift registers for Stacked Sequence Structure

[David_Ferster]

The one place I use Stacked Sequences is for setting up various parameters at the start of a vi. I usually have several frames, especially if the setup is complex, with each frame performing a different class of operations (reading from config files, checking for hardware, setting control appearances, etc.). And often, I find that multiple frames need to plug values into clusters at different points in the setup sequence. Sequence Locals for passing these clusters from frame to frame are terrible since wires have to backwards to come out of the locals, and the result is ugly and non-intuitive. So why not not have Shift registers, just like in loops. Much nicer. It might make Stacked Sequences more acceptable.

[elset191]

---

@Greg S wrote:

Oh, I like that idea.  Remove the Sequence Local, and turn the Stacked Sequence into a Stacked Concurrent.  Or just add an optional "P" box (as in the For Loop, which also has similar checks for dependency). 

---

FYI

[PaulG.]

Wow! Another holy war over the stacked sequence structure. 

SSS were poorly designed at the beginning. The sequence local is an aberration and not being able to use a shift register should have not made sense to someone in the early days before the dang thing was even released.

If the SSS had never had the sequence local and had a shift register and sequence label we might have had something a lot more useful and a lot less abused.

[AristosQueue (NI)]

Darin.K wrote:

> I suppose Error wires are bad because they encourage serialization

> of operations that do not have data dependencies and create an implied

> connection between chunks of code that do not have anything to do

> with each other.

Although you meant this as sarcasm, you are absolutely correct.  For operations that do not involve reference data types, yes, error wires are bad, for exactly the reasons you state. Additionally, unnecessary case structures around your operations make it much harder to apply certain compiler optimizations. They can lead to a significant performance hit -- not significant in any single function, but over the course of an application, checking the error clusters repeatedly can make a notable difference.

I've tried to remove as many error terminals as I can from APIs over the years where they are not necessary.

And, again: Bad is not the same as forbidden. They are problematic for reasons that are subtle and sometimes hard to explain. Same as with the sequence structures. They fall in the category of "things we would like to remove from LabVIEW by introduction of new techniques" as opposed to "things we would like to improve in LabVIEW".

[Darin.K]

> Although you meant this as sarcasm

For the record, there was no (ok, maybe very little) sarcasm in that remark.  Much, much less than my usual amount anyway.

Error wires are the duct tape of LV. 

I have two rules for connecting error terminals 1)  The source VI must actually be able to generate an error  2) The sink VI must actually care.

[David_Ferster]

So, if no SSS, and no error terminals, how do you force a sequence on pieces of code with no data dependency?

[SteenSchmidt]

With the FSS.

/Steen

[AristosQueue (NI)]

> how do you force a sequence on pieces of code with no data dependency?

First, ask the question: "Does it *need* serialization?" If the answer is no, then the answer to your question is "You don't."

If it needs serialization, that means it is doing some sort of by-reference operation or operation with side-effects (like Wait Milliseconds), in which case it does have a dependency on the errors upstream, so using the error wire or a sequence structure are fine. The trick here is that this use case for a sequence structure does not result in a gigantic structure surrounding mamoth amounts of code. It generally surrounds one or two nodes.

Now, are there cases for using the big mammoth structures? Yes. But in those cases, where you are flowing from one frame to the next, the flat sequence structure is generally regarded as much more readable than the stacked and is strongly preferred by most LV users we have asked.

[Darren]

The Stacked Sequence Structure was removed from Quick Drop/palettes in LabVIEW 2014, and NI has no plans to include it in LabVIEW NXG.