Generic shift register initialization

[altenbach]

Sometimes I know I want an initiaized shift register, but I am not sure about the data type, because it might change during program development. Sometimes I have a cluster holding a few variables, but later I need to add a few more elements.

If I initialize the shift register with a diagram constant, things break whenever I change the cluster inside the loop and I need to redo the diagram constant by "delete the constant, right-click the SR,  create constant".

I would prefer a mode where the initialization is generic and simply adapts to whatever type is wired from the inside. This simply ensures that no data is retained between calls, just between iterations of the loop as often needed.

In summary, we should have an option to generically initialize a SR (or feedback node) and it would look different to indicate that fact. For example it could have a small cap as in the attached image.

[crelf]

Could you just create a type-def'd constant and use that?  Then you'd have a more software engineering approach to satatype definitions.  I understand that an auto-typed initialized would be kinda neat, but it'd be obfuscating the type of the cluster (you couldn't just look at the code and know it's structure).  That, in of itself, isn't necessarily a bad thing, but I'm not sure I'd use it very often, if at all.

[altenbach]

It's not just for cluster, but sometimes I am just dabbling with code and might have a simple boolean initialized SR but later decide I actually need an integer to have more than two values.

This feature can also come in especially handy where we are building an array in the SR. Most often, these need to be initialized. Sometimes I start out with an I32 array, but later decide for DBL and even later for CDB. Typedefs would be overkill here.

Yes, for a serious projects it is typically typedefs all the way, of course. 🙂

We often see newbie posts in the forum where arrays grow forever after multiple runs. Wouldn't it be simpler to say "simply initialize your SR generically" instead of having to give instructions on how to make a diagram constant of the appropriate type.

[JimChretz]

I was going to post a duplicate of this idea, I'd like to be able to do as an output tunnel: Right click, Use Default If Unwired.

We could have "initialize with default value" or something like that.

[robdye]

Christian, I like this idea very much. I brought the same idea up in conversation here today (I was unaware of this post) and Darren N tried to shoot it down by pointing out this post and its disappointingly small number of kudos.

I quite often find myself in the exact situation you describe: the types I'm working with are fluid and not yet finalized, I'm experimenting with ideas, and every time I change the type on the inside of the loop, I'm forced to recreate the SR initializer.

The data type is often anonymous and only needed within the scope of a single VI or even a small portion of the VI. Creating a typedef for such a data type immediately gives it a scope that is outside the VI. Sure, that may be necessary down the road, but why should the language insist on it so quickly. The prevalence of type-inferenced "auto" variables in modern languages (C# and C++), and their enjoyment amongst programmers I know, tells me that this kind of ease of use feature is likely to be more popular than your pitiful kudo count suggests.

I'm encouraging all my friends to kudo this idea!

P.S.: Darren suggested this diagram as a workaround (or using "i==0" instead of "First Call"), but I find it noisy and bothersome to create.

[AristosQueue (NI)]

@robdye: The workaround from Darren is incorrect. "First Call" only runs on the first call to a diagram after it is started running. If your While Loop is inside another loop, the code will work like an uninitialized shift register. But what you want is for it to work like a wired shift register, specifically wired with the default value. For that you need to reset on zeroth iteration. (For any LV novices following this conversation, see the image at the bottom comparing the behavior of First Call solution vs the case structure solution in a nested loop.)

Good news: this is easy and requires dropping fewer nodes from the palette than the one Darren suggested.

It's a pretty simple trick to both write and read. That leaves me conflicted about an initializer option -- new syntax for a reader to have to understand always weighs heavily for me against ease of writer writing the code. I like new syntax to have wide application and/or replace significant amounts of existing boilerplate. And there is a case where the initializer would be more value...

Consider how the workaround looks when you grow the left side shift register:

That would definitely be easier to write and to read with an initializer syntax. I just so rarely see grown shift registers that I'm hard pressed to advocate for this.

------------------

Comparison of First Call behavior vs Case Structure behavior:

First Call only resets the first time a given diagram is called during that run of the VI. As long as the VI keeps running (or has callers that are running), it doesn't reset.

[robdye]

@AristosQueue: Good point about how quickly the explicit initialization gets out of hand with depth > 1 SRs.

Darren and I talked about the "First Call" and how it wasn't what I wanted. I thought my parenthetical remark in the P.S. was enough for this crowd, but thanks for leaving a thorough explanation in your comment.

[wiebe@CARYA]

Not sure if I exactly get the problem...

Wouldn't this initialize the SR with the defaults of whatever datatype the SR gets inside:

Not pretty, but prettier that the alternatives.

[AristosQueue (NI)]

Weibe: if it involves the initialization\enable terminals of the feedback node, I'm going to classify it as "never prettier than any alternative". Those terminals are the source of so many bugs I've seen over the years from people misunderstanding or misusing them, I've lost count. I get why the node is designed the way it is designed, and it addresses several FPGA use cases that I can't see any better way to handle, but, in my observation, it is not intuitive to most users. Now, admittedly, this could be biased that I'm one of those users. I had to read the complete docs on the feedback node and then desk trace what was happening in order to figure out how your picture solved this problem.

[wiebe@CARYA]

@AQ:

I'm not FN a fan either. In this example, the FN is always disabled, reducing the FN functionality to "nothing". I might slightly prefer it in this situation, but I doubt I'll need it soon.

Of course in stead of the FN, another while loop (encapsulating the 1st one) with shift register can be used  The right SR needs a disabled case (or cast) to get it's 'default' values.

I don't get in that situation much anymore, but I'm starting to see the benefits of the idea.

[AristosQueue (NI)]

Weibe: A second loop...? Hm... that's a good idea.

(I could've used a diagram disable structure instead of the case structure because the outer loop only runs once, but this way the code fragment looks the same as when it is inside the loop for an un-grown shift register, so the pattern looks the same to anyone reading the code. Seemed like a minor but useful thing to keep consistent.)