Shift registers in Case Structures

[soren_jensen]

Dear NI

I would like to have the possibility to add shift registers to case structures, either when used as state machines or true/false cases. There should be two options, namely a shift register that works as a normal shift register, as we know fro while loop/for loop, and then a new type of shift register that's specific for a particular case/state - sort of a LV2 global in disguise as a shift register for one particular case.

In a state machine the shift registers are often wired to the outside while loop, why not just use the case structure as the carrier of the **bleep** register. 

keep up the good work.

/soren

[wiebe@CARYA]

If the case selector was the left part of a shift register, I don't see how it would work.

The shift register would need to be initialized, or it would retain state over different calls. But if it's initialized, it will be initialized every iteration. As it would need to live in a loop, that loop would need another shift register, and the case selector shift register wouldn't do anything..

As for a state specific shift register, isn't that just a feedback node?

If you feel different, please share some graphics. I'm not entirely sure I got the picture.

[soren_jensen]

The case structure case selector is left as is. The suggestion is for shift register functionality to be added to a case structure, not the case selector. While loops and for loops have options for shift registers, why should case structures not have it ?

It makes no sense to have an shift register that perpetually initializes, so the initial value would be the default value. 

[thols]

"While loops and for loops have options for shift registers, why should case structures not have it"

- Because they are two completely different things.

I cannot see the point for having it and I don't see how it would work. 

[wiebe@CARYA]

>The case structure case selector is left as is. The suggestion is for shift register functionality to be added to a case structure, not the case selector. 

Well, how is that going to work in a state machine? The state is the only thing that is required to go from iteration to the next. And it is wired to the case selector.

So is the example of a state machine just a bad example for this idea?

>It makes no sense to have an shift register that perpetually initializes, so the initial value would be the default value. 

90% of the time, I'd require a way to re-initialize...

[soren_jensen]

While loops and for loops are also quite different, and they both have optional shift registers. Its hardly an argument that just because things are different, they should not support the same features.

In a typical state engine, the sates are handled in a case structure and the variables used are carried from case to case using shift registers on the encapsulating while loop. However, sometimes a variable is only needed in a specific case, and here a shift register in a case structure would make a lot of sense, even if the variable was only used inside the case structure it could make sense. Since all wiring to/from the rim of the while loop could be omitted. 

The only alternative is LV2 style globals, local values, globals, shared variables (I call the feared variables), variant attributes, queues and a few others. For instance in LabVIEW NXG web, a lot of those are not available. In regular LabVIEW, it would often save a usage of a local variable or having to wire-clutter the inside of the while loop. LabVIEW embedded could also benefit from this. 

Thats all I have to say on that matter. 

Happy LV'ing since LabVIEW 4.1

/soren

[wiebe@CARYA]

>The only alternative is LV2 style globals, local values, globals, shared variables (I call the feared variables), variant attributes, queues and a few others.

I'd say feedback nodes, if you must preserve state locally.

A much better option is to arrange things in a class and use it's private data to store state.

Global resources are a bad idea, although there are a few corner cases where it isn't evil.

Local state is often a bad idea too. PtByPt VIs for example are completely useless to me, as the force the entire hierarchy of there call chain to be either reentrant have unique call.

[soren_jensen]

Well, my take on it is, that Classes have their use-cases, but for many smaller LV projects its overkill. I briefly worked for Endevo back in the early 00's when GOOP was initially released, back then OO and Classes was not really a LabVIEW way of programming. Still today, I enjoy the simplicity of creating simple specific designs in LabVIEW. Sometimes the prototype program survives 10+ years, for the simple reason, that it was good enough, and there were other things more important to perfect.

I still would like an easy way to pass variables from one state to the next in a state machine and/or case structure. 

PtByPt : agree.100%

stay safe...

/soren

p.s. Personally I always hated feeback nodes. They are just ugly in a data-flow environment. The best LabVIEW programmer I have ever met, a guy from Russia, said the same thing about OO 😉

[wiebe@CARYA]

Well, I use classes because they're easier, not because they're harder! It's not overkill if you're 100% comfortable with them. Anyway, that's not the topic.

To me, the idea doesn't seem that much easier in practice (not that I've made a state machine in the past 10 years):

[wiebe@CARYA]

BTW

Related (10 years old, but still 'new' and open):

Combine While Loop and Case Structure into new "State Machine" Structure

Mildly related (you brought them up 😉😞

Shift Registers on Stacked Sequence