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.

[tst]

People (including NI) really dislike stacked sequence structures and so they don't want to do anything which would encourage people to use them. You can see that they said that where they declined this idea - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Stacked-Sequence/idi-p/918243

Personally, I agree with you, but that doesn't seem to impress too many people.

[Alex.T]

I like the idea, it looks right to me, but I'm not sure if it makes sense. The functionality of Stacked Sequence Structures should remain consistent when viewed like their flat equivalent; if Sequence Shift Registers did exist, what would we see after the conversion? Just tunnels? If that were the case, I don't think that Functional Globals would be functional any more!

Maybe that's just me though. Can anyone clear this up? I'm most likely incorrect.

If these were implemented in LabVIEW, I'd be having second thoughts of whether I thought Flat Sequences were bad programming practice. It'd be way more readable, and from a glance it would seem that there less of a requirement for sequence locals, which is my biggest issue with them.

[David_Ferster]

I still think a neatly arranged stacked sequence with the elements of each frame organized properly is a useful thing. But this is clearly an argument that has been lost long ago. I should withdraw the idea.

[Ironman99]

There are plenty of good reasons for avoiding stacked sequences (even if some sort of shift register for this structure would overcome some of them).

You can  instead use this sort of "sequencer":

For a small increase of complexity you'll get in return a greater flexibility and some (though not immediately apparent) benefits.

For instance:

the ability of easily change the execution's order of the cases (using Rearrange cases menu).
the ability of programmatically prevent the execution of n last cases, simply connecting a boolean variable to the tunnel leading to while's conditional terminal, in the last frame you want executed for sure.
the ability of momentarily prevent from execution some cases, simply moving them after the last one (the one with the TRUE constant)...

...just to mention some.

Hoping that this will be of some help

 

cheers.

[David_Ferster]

That's great, Ironman. I will use this for sure. So there is at least one good outcome of my post, which is that I learned something.

[Jokelnice]

If I think the idea is good, but do not recommend its use, which is why I think that this idea is not effective.

[PaulG.]

This idea needs to be revived. I don't use the stacked sequence because they're useless. One of the biggest reasons they're useless is that you can't use a shift register. But I don't see how a stacked sequence could be any less readable or functional than a state machine. A stacked sequence would have one benefit over a state machine: the sequence is built in, thus simplifying the code. Do we let the stack sequence die because it's useless or do we give it new life and functionality by giving it a shift register?

[SteenSchmidt]

I never use a stacked sequence. It simply obfuscates the sequence - no matter how many times you leaf back and forth through it it's still hard to imagine the action sequence. In part it's due to you also having to comprehend what's actually in those frames. Instead I use a proper sequence for stuff like this, consisting of the prime sequencing candidate: subVIs:

The Owned data is usually a cluster that gets populated along the way with more and more data elements during the setup/initialization sequence, and which can easily be wired around to those other parts of your application that needs the application's "owned data". You can mingle this container construct with other stuff like classes etc., but that would make this example a bit harder to understand.

SubVIs are good for this as they have a nice icon to let you immediately understand the purpose of each step, the contents of each is easy to maintain (you can add or remove stuff from each subVI without having to do a structure resize that'd otherwise affect all the other frames of a stacked sequence), you have built-in documentation features, they are easy to reuse, and if you worry about the subVI call overhead you can just inline them.

/Steen

[David_Ferster]

The drawback of your scheme, Steen, is that most of the elements I am operating on in the stacked sequence I use for initialization are property nodes for controls, menus, User Events, Queue references, etc. I'd have to create literally dozens of references to all of these items and load them into that Owned Data structure. Then in the vi's you'd see generic property nodes wired with references instead of the local, linked property nodes, which I find easier to read.

In almost every other case, I agree with you. This initialization process is the only place I use sequences.

[SteenSchmidt]

Initializing/creating/registering user events and queues are just as easily done in subVIs.

What do you initialize with property nodes for controls? Even if you are setting values I don't find it harder to do in a subVI; you just let the subVI find the control refnums itself, and then you don't have to wire any references to the subVI at all. That works great for reuse too.

If you've seen the TestStand example OIs you'll understand why I'm not so fond of huge arrays or clusters of control refnums .

/Steen