LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Local Variable vs. Property Node (Value)

In LabVIEW 6 you can set a property node to Value, then read or write it.
It seems to function like a local variable. Is there any real difference?
Message 1 of 10
(15,504 Views)
Very interesting observation. I haven't found any "real" difference.

After playing for a while with both the property node set to Value and local variables, I only found little and maybe useful differences, depending on how you see it. I am assuming that you want only to compare the property node set to value against a local variable, because the first difference is that you can do more things with the property node than just get and set the value of the variable. I know, I know, you knew that too. It is just a fact 🙂

1. The name of the Local Variable is right in the middle of the small icon, while for the property node you must make sure that its "Label" is a visible item. I know again, that's trivial, but if you are concerned or works for a company concerned about
Coding Standards, it is better to go with the local variable as the code is better documented right away.

2. It doesn't matter if your local variable is set to read or write, if it is not wired your code will NOT run. On the other hand, your code will run if the property node is set to READ, but not if set to WRITE. Again, in this case it is better to go with the Local Variable as you will know better that your code is well written and you are not including extraneous code or variables in your project that can consume memory or something.

As you can see, nothing to worry about.

Regards;
Vargas
www.vartortech.com
0 Kudos
Message 2 of 10
(15,504 Views)
One "real" difference that hasn't been commented on yet is that property nodes have and error input and output. Any changes to the property node only occur if there is no error on the input. The error line is also useful for program flow control.
0 Kudos
Message 3 of 10
(15,504 Views)
local variables came before property nodes. property node will allow you to
change the value of an object from within another VI that is difficult to do
otherwise.

Spencer wrote in message
news:3a957718@newsgroups.ni.com...
> In LabVIEW 6 you can set a property node to Value, then read or write it.
> It seems to function like a local variable. Is there any real difference?
>
>
0 Kudos
Message 4 of 10
(15,504 Views)
The real difference is that creation of local variable makes a copy of data and you call it's data by value. When you crate many of locals, especially for complex data types like arrays, you get perfomance loss.
Property node calls value by reference and doesn't copies the data itself. LV internal updating values mechanism is another difference.

BTW there is one more feature: - control reference, seems doing the same, but has one more difference - allows building modular programs and access sub-vi's data from caller vi to be short.
Sergey
Message 5 of 10
(15,504 Views)
> In LabVIEW 6 you can set a property node to Value, then read or write it.
> It seems to function like a local variable. Is there any real difference?

There are some subtle differences.

The property node allows the reading and writing of a single control within
a cluster whereas a local variable and terminal will always refer to the
entire cluster. A property node can update the value from a remote
location, not on the diagram associated with the panel. If you are using
a non-strict control reference, then the datatype of the value may be a
variant rather than the actual datatype of the control.

Because of these differences, there are also performance differences, some
good, and some bad.

If updating something like a graph, you would sometimes need to position
two cursors, change some colors, and write the data to the graph. In the
past this would require two nodes, one for attributes, and another (terminal
or local) for the value. This resulted in two graph redraws. Adding
the value
property to the existing node and not using the terminal or local will result
in one less graph redraw, which may or may not be important for your app.

On the otherhand, because they can update a subset of the data, property nodes
do not implement the same shortcuts that the locals and terminals do. When
updated with the same value over and over, a local and terminal will not redraw
the control, but the value property will. Additionally, for controls
that are
updated very quickly, more than 50 times a second, terminals and locals
have the
option to amortize the redisplays and save CPU cycles that would
otherwise be
spent redrawing things you wouldn't see anyway. There is the option to synchronize
the display with the diagram updates, and the value property is
basically stuck
using this synchronized version each time. This is identical to how controls
and indicators updated before LV5, and it is still how the displays are done
on single threaded systems like the Mac.

To see this, drop a for loop, wire i to an indicator and have the loop execute
1,000,000 times. Initially, update the indicator with the terminal.
Run the
program and it will take a fraction of a second. The indicator will
display 0,
a few numbers in between, then 999,999. Move the terminal out of the
loop and
update with a local. You will see the same. Now popup on the indicator and
choose synchronous display -- it is in the Advanced option in LV6. Now
you will
probably need to abort the VI because it will take several minutes to
run because
it is drawing every single number to the screen making a nice blur of
digits for
you to look at. Now delete the local and use a property node instead. Regardless
of the setting of the synchronous display, you will see the display is showing
each and every one of the updates.

One last difference. The fact that the value can be set from subVIs is
a cool
feature, but it will make your diagrams way more difficult to debug if
you make
a mistake. When a string or other indicator has the wrong value being displayed,
you need to find the code that did the update. If only using the
terminal, there
is only one place the indicator is updated, and you can work backwards
from the
terminal. If using locals, then you have a list of places to work
backwards from.
If you are passing the control reference to the indicator to some number
of subVIs,
then you can have many potential updaters, even dynamic ones to worry
about. So,
while this is a cool feature for modularizing code and separating it
from the display,
be careful or it will have debugging expenses that you may not want.

Greg McKaskle
Message 6 of 10
(15,504 Views)
When you use a boolean with mechanical action "latch....", you can not use a reference nor local variable attached to it. You must change the mechanical action to "switch....". In this case both do not work very well.
0 Kudos
Message 7 of 10
(15,504 Views)
It isone of nicest explanations that i ever have come across
Message 8 of 10
(15,504 Views)
The call by reference of Property Nodes vs the call by value of the local variables had me sold on property nodes. Got some rewriting to do. The more detailed explanation of Gregs further solidified this as well. I had also never heard the 'synchronize to display' difference. Kudos to you guys for some top answers. NI should make a support article out of these differences based on your posts.
Message Edited by rex1030 on 11-13-2008 04:21 PM
---------------------------------
[will work for kudos]
0 Kudos
Message 9 of 10
(13,638 Views)

rex1030 wrote:
The call by reference of Property Nodes vs the call by value of the local variables had me sold on property nodes.

Yes, sometimes you can learn something from a 7 year od thread. 😄

 

Still, I don't understand how you can read this as value property nodes being superior to local variables for general use. Typically, value property nodes will be orders of magnitude slower because of the synchronous nature and the thread switch to the UI thread.

 

You better run some benchmarks on some sandbox code to make sure that property nodes really give you an advantage in your situation.

 

(I only use value properties if I need to set some other properties at the same time or if I need to do it from a different VI)

 

Don't forget that many years have passed since this discussion and we now also have shared variables as an alternative.

 

 

Message 10 of 10
(13,620 Views)