LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

local variable doesn't update

Solved!
Go to solution

 

hello,

 

in the example below the upper loop doesn't always update the value of the stop-control. why is that?

 

 

0 Kudos
Message 1 of 16
(2,214 Views)

The Variable reads the Value of the Control every 900 ms. So If you don't hold the stop button that long, the variable doesn't read the value of the button.



Remember Cunningham's Law
0 Kudos
Message 2 of 16
(2,209 Views)

 

thanks for the reply.

in the end i solved this issue by introducing a new variable and setting its property "value-signaling" to the value of the stop button, then reading the value of this variable in the second loop via property node "value". is there another, more appealing solution for this?

 

0 Kudos
Message 3 of 16
(2,202 Views)

As I understand you shouldn't read Data by property node, as that's a much slower way than the local variable. (At least that's what I've always been told)

 

If you want to be sure that you read every value change of a control you can use a queue. But if you use queues, the reading loops should always be faster than the writing ones. Using a queue to stop parallel loops is like using a tank to go hunting, though.

You could also try an event triggered approach. It really depends on what you want to do, really.

 

your second post said something about another indicator. Does your VI look a little like this then?



Remember Cunningham's Law
0 Kudos
Message 4 of 16
(2,175 Views)

I would do this with two event structures both looking for the stop button. You never miss it that way and you are not constantly polling. More efficient code.

Tim
GHSP
0 Kudos
Message 5 of 16
(2,170 Views)

@aeastet wrote:

I would do this with two event structures both looking for the stop button. You never miss it that way and you are not constantly polling. More efficient code.


Isn't 2 event structures in a single VI on the list of dangerous no-no's?

0 Kudos
Message 6 of 16
(2,165 Views)

That's right, you can use the timeout event to time the loop.

However that timing isn't really accurate over longer periods of time.



Remember Cunningham's Law
0 Kudos
Message 7 of 16
(2,164 Views)

@Taki1999 wrote:

@aeastet wrote:

I would do this with two event structures both looking for the stop button. You never miss it that way and you are not constantly polling. More efficient code.


Isn't 2 event structures in a single VI on the list of dangerous no-no's?


Only if you don't know what you are doing and don't set them up properly.

0 Kudos
Message 8 of 16
(2,150 Views)

 

thanks for your feedback. here is what i did.

although the property node is supposed to be slower than local variables, it suffices in this case.

0 Kudos
Message 9 of 16
(2,147 Views)

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

 

 

Download All
0 Kudos
Message 10 of 16
(2,127 Views)