Add initialize and enable terminals to Shift registers

[falkpl]

Shift registers are used often in functional globals where they need to only be initialized on first call, requiring extra code to handle this case. 

The feedback node handles initialization and enabling (optional updates without adding any code),  why are these not options on the shift registers.  I would just use feedback nodes, but shift registers are more readable in the action engine template.  See the code below, the feedback is much cleaner:

The new SR with the same options yields clean code (I think it is cleaner since there are less object to use real-estate) using shift registers:

[David_L]

This seems similar to my idea a few months ago, but noone seemed to like it 😞

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Reinitialize-stacked-shift-register/idi-p/1116994

[falkpl]

Although this is similar to a reinit register it is actually an init on first call register as well as a conditional update (which is a more generic version of a reinit).

The use cane I see for this is more on the init on first call option.  This use cans is for making simple get set functional globals with a non standard default value (Ie make a functional global that counts down from a non zero number.  Although this can be done with an action engine with a initilaize case simple functional globals (get-set or read- write functional globals) often do not need the non boolean case structure and providing the initialize on first call saves the need to clutter up the code with additional logic.  I use this functionality in the feedback node but would prefer the shift register if it was offered.

[falkpl]

Sorry for the many typos, I was refering to use cases not 'use canes" and couldnt edit the post to correct it.

[AristosQueue (NI)]

>  This use cans is for making simple get set functional globals with a non standard default value

If you're going to do that, then just make a global VI and give it a non default value. The amount of code you have to write is way less, it'll perform slightly better and it is just as unsafe for variable access. Functional globals only help solve the race condition problems if you have no "Get" or "Set" operation but instead encapsulate all the effects of the operation inside the subVI.

[falkpl]

I prefer the functional global over the simple global for scalability, often I expand the simple get,set with functionality (like limiting the range of a variable or adding alarming).  I guess my use case was over simplified.

Also I find the ability for searching vis much better than searching for global.  But I do agree that the get set with no functionality could be done with an initialized global.

Why is this functionality (init on first call and conditional enabling of updates) available in a feedback node but not in the shift register.  Are the 2 mechanisms not interchangeable?  Just curious.

[Darren]

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.