Showing results for 
Search instead for 
Did you mean: 

Uninitialized shift register in a for loop

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.



0 Kudos
Message 1 of 6

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


From help file:


Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
Message 2 of 6

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.

Palanivel Thiruvenkadam | பழனிவேல் திருவெங்கடம்
LabVIEW™ Champion |Certified LabVIEW™ Architect |Certified TestStand Developer

Kidlin's Law -If you can write the problem down clearly then the matter is half solved.
0 Kudos
Message 3 of 6

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.

Message 4 of 6

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.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 6

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. 

0 Kudos
Message 6 of 6