LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Stop a sub VI from main VI

Solved!
Go to solution

@Mark_Yedinak wrote:

@billko wrote:

@Aojha wrote:

Here I have tried to attach a solution. It could not be the best but can help you. What I think the problem was that once you have connected a while loop for your subvi it can not take updated values from main vi. What I did was used multiple loops for controling a subvi. Hope it solves your problem.

In the main vi there are three buttons to Open a subvi close the subvi and close main program.


Passing in a control ref from the main VI to the subVI is more robust than writing to a global on the outside and reading it on the inside.
  Less potential for race conditions.


How does a reference minimize the chance for race conditions? The answer is it doesn't. You can still have race conditions because a control reference will allow access to the same control from two places at the same time.


I am thinking that it is going to read the current state of the control, not the current state of the global.  I didn't say it would eliminate the chance of race conditions.  I didn't even say it would minimize the chances for race conditions.  I am under the impression that control reference allow acesses the control's properties directly so what is there is the current state of the control.

Maybe my undserstanding of a control reference and what it does is flawed?

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 31 of 41
(1,061 Views)

@billko wrote:

@Mark_Yedinak wrote:

@billko wrote:

@Aojha wrote:

Here I have tried to attach a solution. It could not be the best but can help you. What I think the problem was that once you have connected a while loop for your subvi it can not take updated values from main vi. What I did was used multiple loops for controling a subvi. Hope it solves your problem.

In the main vi there are three buttons to Open a subvi close the subvi and close main program.


Passing in a control ref from the main VI to the subVI is more robust than writing to a global on the outside and reading it on the inside.
  Less potential for race conditions.


How does a reference minimize the chance for race conditions? The answer is it doesn't. You can still have race conditions because a control reference will allow access to the same control from two places at the same time.


I am thinking that it is going to read the current state of the control, not the current state of the global.  I didn't say it would eliminate the chance of race conditions.  I didn't even say it would minimize the chances for race conditions.  I am under the impression that control reference allow acesses the control's properties directly so what is there is the current state of the control.

Maybe my undserstanding of a control reference and what it does is flawed?


The thing is, if somebody else has a reference to that same control, they could  change it without you knowing.  You are back to the global variable scenario.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 32 of 41
(1,054 Views)

@crossrulz wrote:

@billko wrote:

@Mark_Yedinak wrote:

@billko wrote:

@Aojha wrote:

Here I have tried to attach a solution. It could not be the best but can help you. What I think the problem was that once you have connected a while loop for your subvi it can not take updated values from main vi. What I did was used multiple loops for controling a subvi. Hope it solves your problem.

In the main vi there are three buttons to Open a subvi close the subvi and close main program.


Passing in a control ref from the main VI to the subVI is more robust than writing to a global on the outside and reading it on the inside.
  Less potential for race conditions.


How does a reference minimize the chance for race conditions? The answer is it doesn't. You can still have race conditions because a control reference will allow access to the same control from two places at the same time.


I am thinking that it is going to read the current state of the control, not the current state of the global.  I didn't say it would eliminate the chance of race conditions.  I didn't even say it would minimize the chances for race conditions.  I am under the impression that control reference allow acesses the control's properties directly so what is there is the current state of the control.

Maybe my undserstanding of a control reference and what it does is flawed?


The thing is, if somebody else has a reference to that same control, they could  change it without you knowing.  You are back to the global variable scenario.


So then it is just a matter of naming your poison?  If this is so, then what is the advantage of using dynamic event registration to register events from outside the subVI?  (I'm currently re-reading this nugget.)

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 33 of 41
(1,049 Views)

@billko wrote:

@crossrulz wrote:

@billko wrote:

@Mark_Yedinak wrote:

@billko wrote:

@Aojha wrote:

Here I have tried to attach a solution. It could not be the best but can help you. What I think the problem was that once you have connected a while loop for your subvi it can not take updated values from main vi. What I did was used multiple loops for controling a subvi. Hope it solves your problem.

In the main vi there are three buttons to Open a subvi close the subvi and close main program.


Passing in a control ref from the main VI to the subVI is more robust than writing to a global on the outside and reading it on the inside.
  Less potential for race conditions.


How does a reference minimize the chance for race conditions? The answer is it doesn't. You can still have race conditions because a control reference will allow access to the same control from two places at the same time.


I am thinking that it is going to read the current state of the control, not the current state of the global.  I didn't say it would eliminate the chance of race conditions.  I didn't even say it would minimize the chances for race conditions.  I am under the impression that control reference allow acesses the control's properties directly so what is there is the current state of the control.

Maybe my undserstanding of a control reference and what it does is flawed?


The thing is, if somebody else has a reference to that same control, they could  change it without you knowing.  You are back to the global variable scenario.


So then it is just a matter of naming your poison?  If this is so, then what is the advantage of using dynamic event registration to register events from outside the subVI?  (I'm currently re-reading this nugget.)


There are no race conditions with dynamic events as there are with variables or references to variables. If you use an event triggered by value signaling you are notified when the value changes and are provided a copy of the value. If you use a user event you get the same thing. You trigger the event when you want and if there is data associated with that event you get a copy of the value. If you use direct access to the value of the control using a reference to it you run into the same things you woudl using variables.

 

BTW, you did state that you would have less potential for race conditions when using references.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 34 of 41
(1,042 Views)

@Mark_Yedinak wrote:
<snip>

There are no race conditions with dynamic events as there are with variables or references to variables. If you use an event triggered by value signaling you are notified when the value changes and are provided a copy of the value. If you use a user event you get the same thing. You trigger the event when you want and if there is data associated with that event you get a copy of the value. If you use direct access to the value of the control using a reference to it you run into the same things you woudl using variables.

 

BTW, you did state that you would have less potential for race conditions when using references.


So this whole discussion was because I left out a vital piece of info.  I am truly sorry about that.  No wonder I confused everyone (jncluding myself).  Thank you for wading through the muck and separating it for me!

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 35 of 41
(1,036 Views)

Hi 

I have the smae problem,I have many SUBVI and in each of them I have while loops because I should measure field from field meter, so I can not stop SubVi when they loops 😞 and I can not see your sample vi because my labview is 8.2

I would really appreciate it if somebody can help 

0 Kudos
Message 36 of 41
(993 Views)

I would recommend that you look at the examples that ship with LabVIEW for notifiers. You can use a notifier to check for stop conditions in your subVIs. You can also look at the producer/consumer architecture which uses messages passed via queues. This again can be used to stop your subVIs. However you would need a queue for each subVI. Notifiers or user events are good since they can be broadcast to all the subVIs that are receiving the /notifications/events. If I can get more time I will try to post some example code saved for version 8.2.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 37 of 41
(980 Views)

Thnak you for your response, but I don't know how can I use notifier for stop button, I tried to make it but it does not work. I really appreciate it if you can upload some example.

 

Best Regards

0 Kudos
Message 38 of 41
(961 Views)

Your main VI which is controling the UI (the one that is showing it's front panel) will detect the Stop button is pressed. Preferably you will detect this using an event structure and a Value Change event for the button. When you detect this you post a notification that a stop has occured. All of your your subVIs will check to see if a notification has occured. You can use a timeout of 0 on the notification check. Here is an example of a VI that can check for the Stop notification:

 

Check Stop Condition.png

 

Your main VI would create the notifier with a specific name, for example "Stop Application". Your subVIs that call the above subVI would wire the notifier name to it and post a notification when you want everything to stop.

 

By the way, it is always a good idea to post your code. It is much easier to see what you have done and let you know what you have to change.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 39 of 41
(954 Views)

@Mark_Yedinak wrote:

Your main VI which is controling the UI (the one that is showing it's front panel) will detect the Stop button is pressed. Preferably you will detect this using an event structure and a Value Change event for the button. When you detect this you post a notification that a stop has occured. All of your your subVIs will check to see if a notification has occured. You can use a timeout of 0 on the notification check. Here is an example of a VI that can check for the Stop notification:

 

Check Stop Condition.png

 

Your main VI would create the notifier with a specific name, for example "Stop Application". Your subVIs that call the above subVI would wire the notifier name to it and post a notification when you want everything to stop.

 

By the way, it is always a good idea to post your code. It is much easier to see what you have done and let you know what you have to change.


ummm....with a 0 for your timeout on wait on notification it will spit out a true, whether or not a notification is sent? i think you want to inverse that bool....

 

Spoiler
Example_VI_BD.png

 

0 Kudos
Message 40 of 41
(949 Views)