12-10-2012 11:39 AM
@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?
12-10-2012 12:04 PM
@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.
12-10-2012 12:14 PM
@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.)
12-10-2012 12:59 PM - edited 12-10-2012 01:00 PM
@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.
12-10-2012 01:15 PM - edited 12-10-2012 01:32 PM
@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!
04-03-2013 08:55 AM
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
04-03-2013 09:52 AM
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.
04-04-2013 03:16 AM
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
04-04-2013 09:29 AM
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:
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.
04-04-2013 10:16 AM - edited 04-04-2013 10:19 AM
@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:
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....