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

[user_4342726352435]

I've read about different problems (or caveats) regarding local variables in Labview 2009. Generally the issues has been about race conditions, memory considerations and performance. I didn't know it could totally change the logic of a sub-vi when it's used the "wrong" way.

Look at the code-picture of "TestInsane.vi" that is used as a sub-vi to "TestInsaneMain.vi". First considering the for-loop of the second sequense. It seems like the output of "ModeName" never could be anything else than "OK", but when the sub-vi is closed and only the main-vi is running it's producing "insane" as a result. How is this possible? If the sub-vi is opened by the user when "main" is running the result immedately change to "OK",  and when closing it drops back to "insane".

If I run the same code under LV 8.5 it gives the result "OK" all the time. Something must have changed in LV2009 (I installed patch f3).

There are a number of ways to make this little code behave better:

- disable the local variable input and use "default" value of "ModeName" instead..or

- change place of terminal and local variable (works for indicators but not for controls)....or

- put a property node of any control (e.g. "nothing to do with it") and put it anywhere in the sub-vi (even in a disabled case)...or

- use the data of the wire before "ModeName" as input to some other control... et.c.

(note: if you changed the code of the sub-vi you might need to restart Labview to really clean the memory before you get the insane value again)

The problem is that I've used this method to initilize controls instead of "set to default"-method since I though it was more clear to read and I also might have alternative values due to some other cause. Now I have a lot of code from LV8.5 converted to LV2009 which I don't know the state of anymore because of this change of behaviour. Maybe I could accept that a "local variable" in a sub-vi might not "exist" as you would think... so the init value to "no mode" might not get through, BUT the total change of logic in the for-loop came as a big and depressing surprise . The "cause" (init of local variable) and "effect" (insane data) might not be as close to each other and therefor "easy" to find in a big project.

Now I don't know if I dare using local variables at all since I don't understand the mechanism completely. Is there some "in depth" description of the local variable that can explain this result (not a general description about race conditions et.c.). I've searched this forum and google but not yet found the clue about this specific topic.

Best regards

Kai

[Ben]

---

user 4342726352435 wrote:

I've read about different problems (or caveats) regarding local variables in Labview 2009. Generally the issues has been about race conditions, memory considerations and performance. I didn't know it could totally change the logic of a sub-vi when it's used the "wrong" way.

Look at the code-picture of "TestInsane.vi" that is used as a sub-vi to "TestInsaneMain.vi". First considering the for-loop of the second sequense. It seems like the output of "ModeName" never could be anything else than "OK", but when the sub-vi is closed and only the main-vi is running it's producing "insane" as a result. How is this possible? If the sub-vi is opened by the user when "main" is running the result immedately change to "OK",  and when closing it drops back to "insane".

If I run the same code under LV 8.5 it gives the result "OK" all the time. Something must have changed in LV2009 (I installed patch f3).

There are a number of ways to make this little code behave better:

- disable the local variable input and use "default" value of "ModeName" instead..or

- change place of terminal and local variable (works for indicators but not for controls)....or

- put a property node of any control (e.g. "nothing to do with it") and put it anywhere in the sub-vi (even in a disabled case)...or

- use the data of the wire before "ModeName" as input to some other control... et.c.

(note: if you changed the code of the sub-vi you might need to restart Labview to really clean the memory before you get the insane value again)

The problem is that I've used this method to initilize controls instead of "set to default"-method since I though it was more clear to read and I also might have alternative values due to some other cause. Now I have a lot of code from LV8.5 converted to LV2009 which I don't know the state of anymore because of this change of behaviour. Maybe I could accept that a "local variable" in a sub-vi might not "exist" as you would think... so the init value to "no mode" might not get through, BUT the total change of logic in the for-loop came as a big and depressing surprise . The "cause" (init of local variable) and "effect" (insane data) might not be as close to each other and therefor "easy" to find in a big project.

Now I don't know if I dare using local variables at all since I don't understand the mechanism completely. Is there some "in depth" description of the local variable that can explain this result (not a general description about race conditions et.c.). I've searched this forum and google but not yet found the clue about this specific topic.

Best regards

Kai

---

LV can change the code execution order any time you change the code or update teh version IF you do not dictate the oreder via data flow.

SO you have an obvious race condition in that the sub-VI out will step on what was written in the For loop.

THe issue with your code is that you have two version of your data, one coming form the sub-Vi and another from the For loop. If you change the struture of your code such that you have only one version of the data and only use a copy of the data coming from that single "master copy" this issue would go away and you could just use the terminal and toss the local.

I wrote this Nugget on Action Engines to demonstrate how they can be used to hold a "master version" of your data so that race conditions are avoided.

I'll leave out the detailed discussion of the nature of locals since that would take a while to explain.

Ben

[Broken_Arrow]

---

 What is a local variable really?

---

Race condition enabler.

[tst]

Ben, you misunderstood the images - the top one is the subVI.

I would say this is definitely a bug (since the second case should never execute), although I'm not sure what's causing it. See the attached LLB for an example.

I would have guessed that this has something to do with loading the VI's front panel into memory, but that doesn't completely fit with everything.

In any case, you should note that having output terminals inside structures is not a recommended practice. You should place the indicator outside all structures and wire an explicit value to it each time. I'm assuming this will fix this bug.

[altenbach]

I agree that there is somethings wrong, but we cannot be sure because we don't have full information. 

Could you please attach the actual VIs instead of pictures. For example we cannot tell what is in the FALSE case. What are all the other VI settings?

You should also be aware that the entire second frame is most likely folded into a constant at compile time, because it can be pre-computed (it only depends on diagram constants). Does it behave differently if you turn one of the diagram constants into a control for example.

Since you are blaming the local variable, does the outcome change if you delete it? The second sequence frame should not depend on it anyway.

[Ben]

---

tst wrote:

Ben, you misunderstood the images - the top one is the subVI.

...

---

Thank you for pointing that out!

Forget what I said and please post the example code so we can look closer.

Ben

[user_4342726352435]

Thx for your fast responses.

I attach the code with this post even if "tst" already got it completely right (showing the insanity).

Sry, maybe I did not explain clearly that the first sequense is the sub-vi of the next while-loop.

As I told you there are a number of ways to get rid of the problem. One is to delete (or disable) the local variable.

Still the turnout of the sub-vi is not what you expect only because you happen to initilize a local variable AND all the other "fix" of the list in my first post is NOT there. Also running the exactly the same code in LV8.5 gives no "insanity".

[user_4342726352435]

Since you also asked about the other control "nothing to do with it". You could try to create a property node for this and hide it anywhere in the sub-vi even in a "disabled case" it makes the sub-vi behaving "ok" again.

[Ben]

---

altenbach wrote:

I agree that there is somethings wrong, but we cannot be sure because we don't have full information. 

Could you please attach the actual VIs instead of pictures. For example we cannot tell what is in the FALSE case. What are all the other VI settings?

You should also be aware that the entire second frame is most likely folded into a constant at compile time, because it can be pre-computed (it only depends on diagram constants). Does it behave differently if you turn one of the diagram constants into a control for example.

Since you are blaming the local variable, does the outcome change if you delete it? The second sequence frame should not depend on it anyway.

---

THere is a bug or two in this somewhere!

In an earlier version of LV there were some issues with constant folding. maybe this is realted to the earlier bug.

I can duplicate the bad behaviour undr LV 2009 but if I add then delete anothe boolean to the array, the sub-VI works as expected.

So I think this may be related to upgrading from an earlier version of LV.

I am curious why the folding is not happening and or why I don't see it being folded.

Ben

[Broken_Arrow]

---

Ben wrote:

I am curious why the folding is not happening and or why I don't see it being folded.

Ben

---

You probably remember this Ben, but for those that may not, remember they changed it, see here