Unexepcted results from sub-vi using local variables in LV2009 makes me wonder. What is a local variable really?

[user_4342726352435]

Maybe I should also point out that the arrays of constants are only used here to simplify. For real I use variable arrays that cannot be determined at design time and by that folded. It still behaves the same, giving "insane" value.

But if I change the place of the output terminal (ModeName) in the sub-vi to outside the loop and use "shift register" in the for-loop, as suggested by "tst", it's "OK" again, which might be the best way to do it, considering my "fix list" above. To bad it means more wires to clutter the code with, specially since I sometimes have several output terminal this way.

But still I'm not completely happy about this change from LV 8.5 since when you consider the for-loop of the sub-vi you might think you know what the output must be...

Is it possible it would be considered a bug so it might be fixed in a future patch?

[tst]

---

user 4342726352435 wrote:

Is it possible it would be considered a bug so it might be fixed in a future patch?

---

It definitely is a bug somewhere, which will probably be fixed, but you shouldn't expect to see that fix before the next version of LV, which comes out in August. As you've concluded, using a shift register to pass the value to the terminal outside the loop is the best solution, even if it does complicate the diagram.

[user_4342726352435]

This thing really drove me nuts for a couple of days until I found this piece hiding in the dark. To bad there might be more to look for in all my projects...

Thanks a lot for your advice.

[Yamaeda]

I guess someone has already answered ... but:
The boolean array is only 2 items long, causing the for-loop to run twice, thus "Insane" is the last ModeName generated.

/Y

[Ben]

---

Yamaeda wrote:
I guess someone has already answered ... but:
The boolean array is only 2 items long, causing the for-loop to run twice, thus "Insane" is the last ModeName generated.

/Y

---

... but the terminal is in the true case...

Ben

[Yamaeda]

Unless there's a Local Variable in the false case it cant (shouldn't) happen. 😉

One solution is ofc to cluster up the values before feeding them to the loop, cant guarantee it'll make a difference though.

Congrats, you've found a bug! 😄

/Y

[user_4342726352435]

Just to clarify Yamaeda, since you might not be able to run LV2009 and test mine or tst's code: 

The different lengths of the two constant arrays are not part of the problem. I put an extra element in the string array intentionally to further investigate the "insanity". I thought since the case structure doesn't do it's job properly (stopping the assignment to the output element) maybe the for-loop is crazy too and runs to the end of any data disregarding all rules. But it works fine. The for-loop only runs to the end of the shortest array.

There is no object hidden in the pictures, i.e. no local variable in the false case. What you see is all there is.

[Davidek]

Hi

I get the same behavior, very weird. One thing that can help you if you are concerned about having to go through all your 8.5 code is mass compile. I tried it (2009 SP1) on the VIs and the answer now comes out OK without any of the fixes you specified in your first post. I completely agree with tst that the shift register and terminal outside the structure is a better solution, this is just a quick fix. I'm sending the VIs to R&D for a look. Will try to keep you posted.

Best Regards

David

NISW