LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

read a subVI input node from inside a while loop

I have been having trouble the last couple of days trying to correctly pass a value into a subVI.  The subVI reads the control from within a while loop.  The subVI was set up like this because it was a standalone program that reads a new value from the control each time the loop interates.  When this program is used as a subVI, the default value from the control is read each time, regardless of what the input was.  The only way I have been able to fix this is to move the control outside of the while loop.

 

This solution is not an option without further modifications of the original VI, which I prefer not to do because I would be forced to use property nodes.  In particular, a new hidden control would be used to set the value of the original control in the init case of the state machine (inside the loop) with a property node.

 

Is there something that I'm not seeing, maybe a way of setting up the call to the subVI?

0 Kudos
Message 1 of 6
(3,189 Views)

astromike wrote:

Is there something that I'm not seeing, maybe a way of setting up the call to the subVI?


There is a lot that I am not seeing, simply because your description is not very clear.

 

Is the while loop in the subVI, in the calling VI, or both?

Where exactly did you move to control to fix the issue?

How are the connectors of the subVI setup?

 

Could you attach a simplified example that shows the problem and the general program layout?

0 Kudos
Message 2 of 6
(3,186 Views)

Here's an example of what I was trying to say.  It is a dumbed down version, but for some reason, the dumbed down version works.  Looks like I've got more to look through.

 

 

Download All
0 Kudos
Message 3 of 6
(3,174 Views)

It is a really bad idea to have multiple controls and indicators with the same name. Could it be the value property node links to the wrong terminal with the same name? (50% chance!).

 

Since this example actually works for both inputs, maybe you should show us your real VI instead. 🙂

Message 4 of 6
(3,167 Views)
It's not ideal to have multiple controls and indicators with the same now, but this is a quick example I created to show how things were set up in the program.  Unfortunately, I can't provide the full up VI.  There is only one input, well, multiple inputs with the same problem on the VI I'm working on.  The example was supposed to show how the property node fixed the problem of reading the subVI inputs from within the while loop, and of course, Murphy's Law shows up and everything works in the example.
0 Kudos
Message 5 of 6
(3,159 Views)

I found the problem after further looking at the application I was turning into a subVI.  The subVI had a call to the Reinit Controls VI with a true constant wired to reinit all.  The error output of this method was wired to the input of the while loop.  It appeared to work when the control was out of the while loop on shear luck as a race condition existed between reinitializing the controls and reading the controls.  When the control was in the loop, the while loop required the Reinit Controls to be run before entering, so it was guaranteed that I would not have the values I passed in.  I have updated subVI.vi with this for furhter illustration.

 

Thank you for at least trying to resolve the issue on what was given. 

Message Edited by astromike on 11-11-2008 09:34 AM
0 Kudos
Message 6 of 6
(3,127 Views)