Uninitialized shift register in a for loop

[BowenM]

Today I was teaching LabVIEW to some new engineers and ran across some unexpected behavior. I still can't explain it.

I started with an uninitialized shift register in a for loop. This code:

and I asked the class what the value of "Numeric" would be after execution. After running it, they saw it was 1. I then changed the loop count constant to a 1 and asked them again what they thought the value of "Numeric" would be.

At this point, I confidently said "It will be 2 after running it the first time, and then 0 the second time I run it". I ran the VI once to show them... and numeric ended up as a 0, not 2.

I've been playing with it for a bit now, it's repeatable and I can't explain WHY it isn't 2 on the second run. Anyone want to weigh in? I feel like I'm missing something simple here, but I can't figure out what.

[aputman]

I would assume changing the count terminal from 3 to 1 causes a recompile, which resets the shift registers. 

From help file:

[PalanivelThiruvenkadam]

Now you can play around the same method with Control to N instead of Constant and Run with different N values from Control and see the results.

Change in BD will Recompile your VI.

[BowenM]

Thanks! I figured it was something simple I was missing.

I knew shift registers reset when the VI was recompiled, I just ... didn't put 2 and 2 together.

[crossrulz]

I have also seen USRs reset between runs, without even a recompile.  So a proper test would be adding another FOR loop around this loop.

[wiebe@CARYA]

If you'd make that constant a control, you'll get what you'd expect (no recompile needed!).

Also, execution highlighting makes these examples insightful (although they don't explain the reset, you'd be able to see it more clearly).

Also, a feedback node has similar effects, but you can specify if it resets on first call or load\recompile. Of course, it will still reset after a recompile, but you can change the behavior when you first run the VI (while a USR will always keep it's value). So with a FBN you can make a difference between subsequent runs (or continuous run) and putting a loop around your code.