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.
I would assume changing the count terminal from 3 to 1 causes a recompile, which resets the shift registers.
From help file:
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.
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.
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.
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.