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.

[Ray.R]

Why do you dislike sub-vis?  Think of them as functions..  A function call that can be re-used.  That's part of good programming practices..  🙂

[David_Ferster]

I don't dislike them at all. I love vi's. But in the SSS's I am referring to, the code never gets reused.

In the meantime, I yield. I will eschew SSS's henceforth and forever more.

[Ironman99]

Very interesting discussions here! In the past I've written lot of bad code, and when I think to all the SSS I've used, I literally feel myself sheepish and red in face... If I had time surely I'd rewrite all that opprobrium. Unfortunately I have no time, and I wish I had learnt earlier some tecniques in my learning path, though I must say I am still able to understand what I did, and able to some extent to quickly modify it. However I understand how David feels. Sometimes, reading this pages, I feel myself the same: "Why NI is preventing me this tecnique? I know what I am doing!". But looking at my old code, I can say that the use of the most flexible and maintainable approach is always a benefit even for myself. Even if I have been a sort of a "cowboy coder"... so far. Just now I am starting to have to teach someone else to mantain my code... sigh!

[Jokelnice]

One idea discussed....

[FlashLV]

Let me see if I have this straight:

Stacked sequences are bad because they hide code and they always execute in the same order. This makes creating and debugging them dull.

State machines are good because they hide code but the order can be altered from within each individual case.  This makes creating and debugging them exciting!  

Got it, makes perfect sense. It's nice to have these sort of things cleared up.

[SteenSchmidt]

State machines can be implemented in many different ways, you may be thinking about the case structure not a state machine? If that's the case, then a case structure only execute a single frame when it's called, and that can be traced through linearly.

The usual incentive to use a stacked sequence structure is to conserve BD real estate - and that is a bad reason standing by itself.

You shouldn't create a subVI just to save BD space either; that should be motivated by code re-use opportunity (either as a dev toolset or reentrant runtime clones), the need for encapsulation, modularization (documentation, interface etc.), configuration condensation (you can set priorities, threading and such on a subVI different from its caller), or for a number of other reasons. If you create a subVI just to save BD space, it's almost as bad as a stacked sequence structure - it just hides your code. You're slightly better off with a subVI though, as the documentation features of a subVI are better than for a stacked sequence structure.

As for so many other things it's a case of choosing option A or B when implementing something, and almost all the time the other option is better than a stacked sequence structure. In the minority of cases where a stacked sequence structure might be fine... should NI really spend resources improving the stacked sequence structure for those, instead of spending the same resources on something much more useful?

/Steen

[AristosQueue (NI)]

> Stacked sequences are bad because they hide code and they always

> execute in the same order. This makes creating and debugging them dull.

No. Stacked sequences are bad just like flat sequences 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. Stacked sequences make it worse by *unnecessarily* hiding code and doing so in a way that makes it hard to manipulate. If you need dynamic ordering, then use a state machine. If you don't, then just spell out your code. If you truly have a functional chunk that should be considered one operation, make it a subVI so you can test it in isolation.

Note that when we say "bad", we mean it in the same sense as saying that sentence fragments in English are bad. Used very precisely, a fragment can emphasize a point. Like this. Whereas used imprecisely, fragment bad communication. Or this reading painful.

[Darin.K]

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.

I have no real beef with either of the sequence structures.  They are syntactic elements with a job to do.  I would rather be able to stack a bunch of property and invoke nodes then stretch them out across two screens.  I would also like to be able to use either structure in multithreaded code.  It is a natural syntax for providing concurrency.  Code inside a frame could operate in parallel as possible, but all threads must complete at a frame boundary.

Unfortunately the abomonitation that is the sequence local prevents the first use, and the LV compiler does not seem to multithread within a frame so the second use is out (maybe the compiler has improved since I benchmarked this).

[FlashLV]

I haven't used a stacked sequence in 4 or 5 years but now that Steen and Aristos are so against it, I have this urge to put one in. 🙂  There are also a bunch of young engineers here just starting to learn LabVIEW here ... Bwahahahahaha

I think, Darrin, we are on the same page here.  Any of the structurs in LabVIEW can be misused, abused and used in unique and mystifying ways.  That doesn't mean we should jettison any of them.  Tools are tools and only should be thrown out with extreme prejudice.  All the tools should be subjected to improvements; even if the current trend is to deemphasize it.

From a purely selfish point of view, I think LabVIEW people writing bad code that needs a lot of work is a good thing ... it  helps that I am a contractor and get paid by the hour. 🙂

There is nothing quite as dull as starting a job with well written, commented code that only has a few wiring errors.  No fun there and the learning potential is generally small.

Anyway fun discussion ... now where should I put that SS ...

Dirk

[GregSands]

> It is a natural syntax for providing concurrency.

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