LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Writing Values To Front Panel Controls (Most Efficient Method)

Highlighted

Just for kicks, I put this in an empty project and also added a shared variable case.  Ran them all as is and then again with the shared variable bound to the "Value" indicator.  Here is what I got

 

Method                                       No Binding           Shared variable bound to "Value"

 

Terminal                                        9 ms                   9 ms

Local Variable                              11 ms                  8 ms

Shared Variable                           535 ms                4.2 sec

Property Node                             33.1 sec               36.5 sec

Reference                                    33.9 sec              37.0 sec

Set Control Value                         776 ms               803 ms

Set Control Value by Index          46.7 sec             57.7 sec

 

Odd that the Local Variable time actually decreased when with the bound condition of the indicator.  This was consistent though.

 

Might go back and add a global variable just to see where it falls in though I try not to use these any more.

 

These times look about right?  Since they are all relative to computer porcessing speed, I'm sure they will vary from system to system but the delta's between the various options should be somewhat consistent.

Doug

"My only wish is that I am capable of learning each and every day until my last breath."
0 Kudos
Message 21 of 33
(432 Views)
Highlighted

@dacad wrote:

Just for kicks, I put this in an empty project and also added a shared variable case.  Ran them all as is and then again with the shared variable bound to the "Value" indicator.  Here is what I got

 

Method                                       No Binding           Shared variable bound to "Value"

 

Terminal                                        9 ms                   9 ms

Local Variable                              11 ms                  8 ms

Shared Variable                           535 ms                4.2 sec

Property Node                             33.1 sec               36.5 sec

Reference                                    33.9 sec              37.0 sec

Set Control Value                         776 ms               803 ms

Set Control Value by Index          46.7 sec             57.7 sec


The control value by index doesn't look right. Here's what I got on my machine.

 

Capture.PNG

0 Kudos
Message 22 of 33
(417 Views)
Highlighted

I ran it again outside the project and eliminating the shared variable and the Set Ctrl by Index ran around 700 ms.  Maybe the overhead of being in a project along with the presence of a shared variable has an impact?

Doug

"My only wish is that I am capable of learning each and every day until my last breath."
0 Kudos
Message 23 of 33
(412 Views)
Highlighted

The set control by index code also has the overhead of finding the index each time you go to write it.  To get the real performance boost, you should look up the index once before the FOR loop and then use that index to update the value.


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
Message 24 of 33
(408 Views)
Highlighted

Sorry to interject. This is an interesting case study for sure, but I would consider leaving it at that: a case study. In my however many years of LabVIEW development I have never had a need for this, so while figuring out the most efficient solution, don't forget the balance between code that someone can read and code that is more efficient but completely obfuscated. I'd much rather lose some minor efficiency and have a process that just pumps data via some transport (queue, user event, etc) to a loop that is dedicated to handling UI updates, which I can quickly understand. Consider the YAGNI and KISS principles and don't overdesign if you aren't doing massive UI updates.

0 Kudos
Message 25 of 33
(399 Views)
Highlighted

What is obfuscating in using terminals whenever possible and eventually local variables if unavoidable? Smiley Very Happy

 

The only legit use of the Value Property Node in my opinion is when using the "Value w. Signal" version for UI updates as reaction of other UI events, to avoid duplication of the same code in multiple event handling cases (and very rarely when implementing a generic VI that does quite a bit of processing with subsequent update of a control value). However this last one is most likely already a good candidate for an XControl instead.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 26 of 33
(388 Views)
Highlighted

rolfk wrote:

The only legit use of the Value Property Node in my opinion is when using the "Value w. Signal" version for UI updates as reaction of other UI events


I'd also argue if you are setting a value at the same time you are setting other properties.  Just drag down the property node to accept multiple inputs.  It should just be one thread swap the the UI if in the same property node (based on my understanding of how the property node works).


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 27 of 33
(362 Views)
Highlighted

rolfk wrote:

The only legit use of the Value Property Node in my opinion is when using the "Value w. Signal" version for UI updates as reaction of other UI events


The only issue w/ local variables is that to maintain the linearity of the execution, you have to put them in a frame or other type of case structure whereas nodes can get wired in and as crossrulz points out, you can tap into many parameters at once.  When I have several different nodes in a given location I often stack them and wire the error wire to the input but leave the output open just to get the execution flow that I need.

Stacked Nodes.png

 

 

On a semi-related topic concerning shared variables, I am going to start a new thread asking about timing of these in conjuntion with refrenced vi's. Noting it here so you guys that get to work with LV a lot more than I do might have some thoughts when you see the thread.

Doug

"My only wish is that I am capable of learning each and every day until my last breath."
0 Kudos
Message 28 of 33
(347 Views)
Highlighted

@dacad wrote:

When I have several different nodes in a given location I often stack them and wire the error wire to the input but leave the output open just to get the execution flow that I need.

Stacked Nodes.png

 


With that example you are showing, I would use a sequence structure and local variables.  It just isnt' worth the performance hit to me to write a value to a property node.  Now if you were setting the Visibility and the Value properties OF THE SAME CONTROL, that's when setting the value with a property node makes sense.


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 29 of 33
(337 Views)
Highlighted

@dacad wrote:

rolfk wrote:

The only legit use of the Value Property Node in my opinion is when using the "Value w. Signal" version for UI updates as reaction of other UI events


The only issue w/ local variables is that to maintain the linearity of the execution, you have to put them in a frame or other type of case structure whereas nodes can get wired in and as crossrulz points out, you can tap into many parameters at once.  When I have several different nodes in a given location I often stack them and wire the error wire to the input but leave the output open just to get the execution flow that I need.

Stacked Nodes.png

 

 

On a semi-related topic concerning shared variables, I am going to start a new thread asking about timing of these in conjuntion with refrenced vi's. Noting it here so you guys that get to work with LV a lot more than I do might have some thoughts when you see the thread.


Well I would use locals and put the false constant and the 1 constant in the loop. Smiley Very Happy

LabVIEW is since many versions smart enough to consider constants inside a loop as invariant code and not evaluating them on every loop iteration again.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 30 of 33
(325 Views)