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

Question

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.
Attachments:
lv-bug-files.tar.gz ‏24 KB

Answer 1

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