Shift register for Stacked Sequence Structure

[asper]

Using the Stacked Sequence Structure can be an option to perform sequenced coding in a reduced space.

Usually some data, typically the error cluster or other wiring, have to be passed frame by frame for all frames.

A the present, the only option available is the "Sequence Local" and, in case of many frames, this becomes difficult to read and to maintains, and fills a lot of space.

In "While loop" the "Shift Register" passes data from an iteration to the subsequent iteration, in similar way, I suggest to introduce a "Shift Register" for "Stacked Sequence Structure", where the data are passed from a frame to the subsequent frame.

In my opinion a "Shift Register" could simplify and clarify the use of "Stacked Sequence Structure".

Regards,

Asper

[wiebe@CARYA]

>It works like a charm.

For an error cluster it isn't too bad... Indeed much better than sequence locals.

The locals will prevent the FP to be removed in executables though. Updating the locals is slow compared to a wire.

Each local is a copy in memory of the data, so if the value isn't an error but a large array, you'll definitely start to see effects.

Using value properties will prevent copies, but will limit speed and also force to keep the FP in executables.

I personally don't mind if what is a large sequence ends up as a large sequence on my diagram. It would become a wide VI, so you'll loose the overview, but there's no overview in a SM or SSS either... Even putting stages in subVIs (a pretty solid solution) will reduce overview.

A 'Darren sequencer' is somewhere between a state machine and a stacked sequence structure:

You get some benefits of a state machine:

+ Stop the sequence at any time (e.g. on error).

+ Documented state names.

+ No locals to pass data.

But:

+ No reason to type def the enum (one less file).

+ No way to screw up the sequence.

+ Easy to rearrange the cases.

+ There's two structures, while a SSS only uses one...