LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problems with clusters updating after being passed to sub VIs

Hi,

I'm working on a LabView program that reads in four external hardware reaction timers.

The problem I'm having can hopefully be illustrated by the attached simplified example vis.

The main vi (ClusterPassingExampleMain.vi) passes a cluster to a sub vi (ClusterPassingExample_Sub.vi). The sub vi uses the boolean checkbox value to either:
if TRUE - return a random counter value between 0 and 1000.
if FALSE- if the current value is less than 1000, increment the current value and return that otherwise reset it to zero.

There is also a text box where the name of the counter can be changed (supposedly).

In the sub vi there is a brief delay to simulate the reading of my external hardware timers.

When the main vi runs if you try to change the 'Random' check box state by clicking on it it briefly responds but then reverts back to the original state, likwise if you try changing the text in the 'Counter Name' text box it reverts back to it's original text.

In the main vi where the new counter value is bundled into the counter cluster the 'counter name' and 'random' fields are left unconnected so how are the old values getting in to the cluster?

It only happens when there is a delay in the sub vi as though the user is changing the values whilst the sub vi is being executed and the changes are being missed?

Any ideas?

Thanks,
Dave.

(LabView 7.0, Mac G5 OSX.)
0 Kudos
Message 1 of 3
(2,606 Views)
Nothing but normal here. Let's have a look at the way your vi execute :
The Counter cluster is read. Of course this occurs before you could have a chance to change something in it. Then there is a call to the subvi.  At nearly the same time, the Counter cluster value is transfered to the bundle node. Then we wait for the subvi to return the new counter value. Once this happen, the Counter cluster value is updated with the new counter value, and written back to the Counter cluster. And a new loop iteration is started again. 
Clearly, the only chance to update the random button or the counter name would be to write it during the time left after the write operation at the end of a loop iteration, and before the read operation at the beginning of a new loop iteration. About one clock cycle. Less than a nano second !.. 😮
Just slow down things a bit by adding a small delay node (100 ms is allright) in your main vi loop, so you'll have some opportunity to have your changes taken into account and everything will go fine !..
Chilly Charly    (aka CC)
0 Kudos
Message 2 of 3
(2,596 Views)
- Thanks, I'll try that.

Dave.
0 Kudos
Message 3 of 3
(2,585 Views)