LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reproducible and critical bug in labview 7.0 (test VIs included)

In upgrading from 6.1 to 7.0 recently, I've found a bug in at least the Linux and Windows versions of LabView 7.0.

I have verified the bug on Windows XP as well as RedHat 8.0 (with a 2.4.24 custom kernel).

As a part of this post, I am including a tar-gzipped set of three VIs that demonstrate the bug described here.

The synopsis (refering to 3 included tar-gzipped VIs):
- lv-bug1.vi has a three clusters with similar contents
- lv-bug1.vi passes the contents of cluster1 to lv-bug2.vi and to lv-bug3.vi
- lv-bug2.vi increments one of the integer fields in the cluster and then returns the resultant cluster to be displayed in lv-bug1.vi's cluster2.
- lv-bug3.vi also increments the same integer field in the EXACT same manner to be displayed in lv-bug1.vi's cluster3.

What you will notice first off:
1. The incremented integer field is indeed incremented
in both returned clusters.
2. In lv-bug2.vi, none of the other fields will be carried through to cluster2 (change them as you will, these changes will not go through).
3. In lv-bug3.vi, ALL of the other fields will be carried through to cluster3
4. If you open up the panel of lv-bug2.vi, everything works as expected (ie. all values of cluster1 go through lv-bug2.vi to cluster2).
5. If you close the panel of lv-bug2.vi again, cluster2 does not receive any new changes of cluster1.

Some more details:
In both lv-bug2.vi and lv-bug3.vi, the steps are:
1. copy input to output
2. increment said integer field in the output cluster
- This increment is done by (abstractly):
output->intfield->property_node->value =
input->intfield + 1;
3. The only difference between lv-bug2.vi and lv-bug3.vi is that lv-bug3.vi has a Reference to some other unused control. This control is unwired and its Reference is also unwired. I find that as long as I have a Reference on the diagram to anything (be it to the one of the clusters or something else), the VI functions properly. But in the case of lv-bug2.vi, where there is no Reference to anything, the values are not correctly copied from the input to output.
0 Kudos
Message 1 of 6
(2,461 Views)
I can confirm that the same problem exists under LabVIEW 7.1 under Windows 2000.

lv-bug2 FP open --> correct operation
lv-bug2 FP closed --> output is stale (except for the numeric)

However, I don't quite understand why you do this in such a complex way. If you use the attached direct code in lv-bug2, the behavior is correct, even if the panel is closed.
Message 2 of 6
(2,461 Views)
I agree that the method is unneccessarily complex and I'm not sure whether to call it a bug in LV 6.1, 7.0, or in the way the original application was coded. You can change the behavior by moving things to different frames of the sequence structure. This leads me to believe that there's some sort of weird race condition going on and the fact that it once worked was pure luck.
0 Kudos
Message 3 of 6
(2,461 Views)
To complicated for me to jump in.

But,
The race condition could be getting canceled out when the sub-VI is forced to run in the UI thread.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 6
(2,461 Views)
I agree it is a bug since the subVI should return the content of untouched cluster elements and behave the same with panel opened/closed.

However, you have to know that indicators (on FP) and terminals (on BD) are not exactly the same thing in a VI. Controls are graphical objects to display data. Terminals hold data in the block diagram. They are related as the Control usually displays the Terminal data, but LabVIEW tries not to update the Control unnecessarly when the front panel is closed or otherwise not visible.

But they are not exactly the same. For example take the working lv-bug3.vi and make it reentrant. You'll see that it doesn't work anymore. The Control has been incremented on the front panel but the subVI outputs the same cluste
r as input. That is because when you make a VI reentrant, the Terminal is disconnected from the Control. All instances of a reentrant VI share the same FP and Controls but keep their own terminals. In your code your write a value in the terminal and another in the control since the value property node is a property of the control, not of the terminal.

In your test case (non-reentrant) the bug occurs probably because LabVIEW fails to keep the terminal data and the control data properly synchronized when the front panel is closed.

There is no reason to use the value property node in a non-UI subVI and it should be avoided. The correct way to implement your code is as altenbach showed in his picture: use wires and write output to the terminal.


LabVIEW, C'est LabVIEW

Message 5 of 6
(2,461 Views)
So, then, can you tell me that property nodes are necessarily connected to the control/indicator (on FP) whereas local variables are connected to the terminal? Can I have fully reentrant code that uses local variables?

(Thanks for the previous suggestions)
0 Kudos
Message 6 of 6
(2,461 Views)