LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Calling vi front panel object update in a running sub-vi loop?

Solved!
Go to solution

Hello All. I have a calling sub-vi with a "Start Test" button on the front panel. I passed a control reference for that Start button into a sub-vi that runs in a while loop. The while loop is monitoring that Start button and other things.

 

Problem: Once the sub-vi runs, it no longer takes updates from that Start button. My program never leaves that while loop in response to my Start button.

 

Is there some way I can make the sub-vi take an updated value from the calling vi?

 

Attached is the sub-vi (top level, LabVIEW 2011). Please note that I have already tried putting the Start Test terminal inside the loop, but that did not help. I put comments in the block diagram and the front panel to help identify the problem code.

 

I am going to get around this problem by running this whole vi through a loop in the calling vi, where I can easily respond to button changes. This is mainly an academic or curiosity problem now.

 

Thank you, Richard V

0 Kudos
Message 1 of 11
(3,055 Views)
Solution
Accepted by topic author rrsquez

You should look at the Syncronization pallette and become familiar with the Queue and Notifier constructs.  These are very useful for passing data between VI's.

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
Message 2 of 11
(3,037 Views)

Lets just whip up a little example then shall we?

!1-1.png

The subvi you see contains:

!1.png

Go ahead and run the top vi.  Press OK and watch the value of Value change (up to 20 times per second but that is faster than your eyeball).

 

Why the difference between this simple example and what you are seeing?

 

If I had to guess (And, I do since the caller wasn't encluded) I would suspect that you misswired the reference.  With that over-burdened connector pane and no required terminals it would be fairly easy to do.

 

And thats where you might want to ricght-click the vi and deselect view as icon.

!2.png

You'll find out that its a lot easier to wire the right terminals that way.  Also, changing the terminals to "Required" for anything that is as important as an exit condition is a good idea.  Perhaps even exit if the reference is null although that should cause an error on the property node.  Did you shut off automatic error handling?.... Nope you didn't so there is a valid reference going into the sub-vi.  But a reference to what? maybe not the button you think.

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 11
(3,036 Views)

I would also end the love affair with the stacked sequence structure.  She will only cause heartache down the road.  😉

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 4 of 11
(3,021 Views)

@aputman wrote:

You should look at the Syncronization pallette and become familiar with the Queue and Notifier constructs.  These are very useful for passing data between VI's.


I actually think this approach is over-complicated for what you had in mind...

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 11
(2,995 Views)

@billko wrote:

I actually think this approach is over-complicated for what you had in mind...


Actually, I agree now that i have had a chance to see the code.  But i think there are other issues.


Are you sure the subVI is running as you stated?  I am assuming you push the start button to start the test (duh) so the initial value is TRUE.  But a TRUE value stops the loop.  So my question is are you sure the subVI is running? 

 

The center while loop really bugs me.  I'm not sure what is going on there but there is likely a race condition with the Start Test local variable. 

 

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 6 of 11
(2,990 Views)

@aputman wrote:

@billko wrote:

I actually think this approach is over-complicated for what you had in mind...


Actually, I agree now that i have had a chance to see the code.  But i think there are other issues.


Are you sure the subVI is running as you stated?  I am assuming you push the start button to start the test (duh) so the initial value is TRUE.  But a TRUE value stops the loop.  So my question is are you sure the subVI is running? 

 

The center while loop really bugs me.  I'm not sure what is going on there but there is likely a race condition with the Start Test local variable. 

 


I was only highlighting it becasue it was accepted as a solution.  I actually assumed exactly what you said - that your post was before you were able to obtain all the available data.  🙂

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 7 of 11
(2,984 Views)

What i mean is if your button is set to a latching action, your VI may be reading the value properly from the reference but the local variable is reading it before the control updates so the test never starts.

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 8 of 11
(2,980 Views)

@aputman wrote:

What i mean is if your button is set to a latching action, your VI may be reading the value properly from the reference but the local variable is reading it before the control updates so the test never starts.


I was just commenting on the first part of your post above, but I admit that I didn't even notice there was a local variable there (even thought it was right in front of me).

 

So is the reason for your concern becaus there is no coupling between the control update and the local variable read that enforces data flow?

 

Err, well I know that using a local variable breaks data flow already... but I hope you know what I mean.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 9 of 11
(2,973 Views)

No biggie man.  I agreed with your comment that it was a little overcomplicated but it would work just fine.  I am by no means a LabVIEW expert.  Sometimes I get in a rush to type out my answer without thinking things thru fully. 

 


So is the reason for your concern becaus there is no coupling between the control update and the local variable read that enforces data flow?


 

Yes, that is one of my concerns.  I think execution may get stuck in the center while loop depending on the mechanical action of the button in the main VI. If it latches, I could see that the subVI never gets the updated value.  But if it is set to switch, I don't see why the OPs code doesn't work.

 

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 10 of 11
(2,937 Views)