LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

local variable doesn't update

Solved!
Go to solution

@smercurio_fc wrote:

That "solution" is no better than your original. Using a property node instead of a local variable gains you absolutely nothing. A property node requires a thread switch to the user interface thread. In some cases this can cause huge performance impacts. I don't know why you don't want to use an event structure. Are you using LabVIEW Base which has no access to event structures? If you must use loops, then a better way to handle a loop that has a long loop time is to actually have the loop time short and then use a case structure to determine if it's time to execute the loop.

 

Something like this, for example

 

 


It would also be a good idea to place the stop local variable in a sequence structure and read its value AFTER all your processing is completed. Otherwise you run the risk of doing an extra loop iteration. As written above there is a very high probability the local variable very early in the loop.



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 11 of 16
(484 Views)

This is an easy way and it does not depend on loop time.

 

Example_VI_BD.png

Tim
GHSP
0 Kudos
Message 12 of 16
(477 Views)
Solution
Accepted by labviewette

@aeastet wrote:

This is an easy way and it does not depend on loop time.


This is similar to this.

 

I would use value changed and keep the button at the latch mechanical action. Remember, you only need an event structure in the "other loop" (the one without the stop button). The loop with the stop button can be polling normally.

 


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 13 of 16
(466 Views)

@Mark Yedinak wrote:
It would also be a good idea to place the stop local variable in a sequence structure and read its value AFTER all your processing is completed. Otherwise you run the risk of doing an extra loop iteration. As written above there is a very high probability the local variable very early in the loop.

That's a valid point, though the intent of the example was just to show the technique of how to deal with loop times that are supposed to run with a long duration, but still have a responsive UI. I still think the best solution is to use an event structure, and I don't quite understand the OP's apparent reluctance in doing so.

0 Kudos
Message 14 of 16
(458 Views)

@smercurio_fc wrote:

@Mark Yedinak wrote:
It would also be a good idea to place the stop local variable in a sequence structure and read its value AFTER all your processing is completed. Otherwise you run the risk of doing an extra loop iteration. As written above there is a very high probability the local variable very early in the loop.

That's a valid point, though the intent of the example was just to show the technique of how to deal with loop times that are supposed to run with a long duration, but still have a responsive UI. I still think the best solution is to use an event structure, and I don't quite understand the OP's apparent reluctance in doing so.


I agree, the event structure is defintely the preferred choice. I also like to use queues/notifiers. This gives an added benefit that messages can be sent which allows more than just a Stop.



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 15 of 16
(453 Views)

 

thanks all for the loads of ideas !

0 Kudos
Message 16 of 16
(422 Views)