Static Shift registers

[Rhayes]

My understanding of shift registers is that if you don't initiaze them then they will hold the value from the last instance, hence be static.

I've created a subvi and placed multiple copies in a case statement, all it does is check to see if the value has changed, yet when it runs the second time it starts out at zero when it should be  whatever number went through the sub the last time.

Am I missing something here?

Bundle to byte array contains single to byte array sub vi

Ron

[TiTou]

Ron,

I could not open your VIs because don't have LV 8, but if I read well I can guess the answer...
The last value will be kept in the shift register AS LONG AS THE VI RUNNING, if you stop it the memory is released and the last value lost.

If the VI that holds the value is a sub-VI of the application as long as the app is running the value will be kept, this is known as LV2 Global ot FGV (Fuctional Global Variable) and it's a nice tool 😉 !

[Evan]

I took a look at your code and was missing a subVI, so I just removed those cases.

Anyways the code seems to execute just like it should, and the shift registers do keep the old values.  However in the code you sent you only send in values of 0, so the return is always false.

I set the Max low to 1 and bingo I got a true.  Is there a different way you are running, so that you don't see what I am seeing?

[Rhayes]

I think I see what is happening.

This subVI is used 3 times in 3 different cases, I assumed that each one would be a different instance and run independantly of each other, this is not the case. When case 1 runs through, it's value is stored in the shift register then case 2 overwrites it's value on the shift register.

I'll have to rethink this subVI I think

Ron

[Kevin_Price]

Quick FYI:  If you go to the subvi in question and select File-->VI Properties-->Execution Options and set the vi to be "Reentrant", then each instance you put on your block diagram(s) will be distinct from one another.

In regular, non-reentrant mode, all instances are forced to share the same shift register data.  In re-entrant mode, all instances are forced to have distinct copies of the shift register and the static data cannot be shared.

-Kevin P.

[Albert.Geven]

TiTou

sorry but the shiftregisters keep their information as long as the vi stays in memory and is not edited.
also when not part of a running program. Try it out with running vi's by hand. That is how I check my functional globals

[TiTou]

Hi Albert,

Your are indeed right... I thought the value was realesed when the VI or application stops..
Thanks for the info.

Just a general thought to add, I think shift register should "always" be initialized to be sure not to get the value of a previous run ; the only case where it shouldn't be initialized is the FGV.
Do we all agree on that point or do I miss something else ?

[Jarrod_S.]

You should always consider initializing shift registers. Keep in mind that if you just opened a VI that contains uninitialized shift registers, it won't remember the data from the last time it was run (because it has been unloaded from memory since then), so it's more likely the values in that shift register are garbage. That could be even more dangerous, since how LabVIEW interprets that data could cause very strange and erratic behavior in your application.

Here's my solution that works for Functional Globals and general shift registers: Consider initializing them the first time the VI is called inside the While Loop, as demonstrated below:

The First Call VI outputs a true the first time that instance of it is called, and false every other time. For Functional Globals you could alternatively have a dedicated Initialize case to perform this function. The advantage of the technique listed above is that you are guaranteed initialization on the first call, regardless of whether the client programmer remembers to call an initialization case.

Message Edited by Jarrod S. on 04-11-200612:33 PM

Message Edited by Jarrod S. on 04-11-2006 12:33 PM

[kehander]

---

@jarrod S. wrote:

Keep in mind that if you just opened a VI that contains uninitialized shift registers, it won't remember the data from the last time it was run (because it has been unloaded from memory since then), so it's more likely the values in that shift register are garbage. That could be even more dangerous, since how LabVIEW interprets that data could cause very strange and erratic behavior in your application.

Wow, LabVIEW can do that? I thought the shift registers would just quietly be initialized with default data.

[Jarrod_S.]

Ok, I may have spoken too soon (I always do that 🙂 ). Some quick tests seem to indicate that shift registers are initialized to default values when the VI is first opened.

I'll try to think if there's a bona fide exception to this. In any case, the technique listed above is still valuable in many situations, especially functional globals.