Showing results for 
Search instead for 
Did you mean: 
Reply

local vs property node

Highlighted

local vs property node

what is the difference between local variables and property nodes concerning best practices and performance  ??
 
 
Thanks
 
 
James
- James

Using LV 2012 on Windows 7 64 bit
0 Kudos
Message 1 of 11 (8,320 Views)
Reply
0 Kudos

Re: local vs property node

If possible, you always want to pass data to/from your front panel controls/indicators with wires.  If this won't suffice (parallel loops, e.g.), then you will want to use locals.  Try to avoid using the "Value" property unless you must write to your controls/indicators in a subVI.  The "Value" property is very slow compared to locals due to threading issues associated with property nodes.

Hope this helps,

-D

Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Message 2 of 11 (8,313 Views)

Re: local vs property node

Since you compare the two in one sentence, you must mean "Value property nodes". Smiley Wink
 
As Darren said, property nodes are expensive. Check out my speed comparison VI in this old thread:
 
 
 
(Of course if you need to write to a signaling value property in order to fire an event, a local variable won't work. You need the property node.)
Message 3 of 11 (8,299 Views)

Re: local vs property node

[ Edited ]

Hello all,

To take it one step further, the speed hit comes from the fact that these items run in the UI thread along with all of your other user interface actions (speed), and copies are always made of the data (performance AND speed)!  Check out the "LabVIEW Performance and Memory Management" tutorial -- while a little old its concepts are still dead on and it does a great job of explaining the details of these issues.  If you need to pass data from/to parallel loops or sub-VIs consider putting the data in some sort of container (like a single element queue), and passing the container around.

Hope this adds just a little more insight!

Message Edited by Travis M. on 02-08-2006 02:21 PM

Travis M
LabVIEW R&D
National Instruments
Message 4 of 11 (8,272 Views)

Re: local vs property node

Really good Thread thanks

0 Kudos
Message 5 of 11 (4,996 Views)
Reply
0 Kudos

Re: local vs property node

Hello travis could you please pour in some more information on Property node concept and whn can it be best used?? Thanks in advance.

0 Kudos
Message 6 of 11 (3,924 Views)
Reply
0 Kudos

Re: local vs property node

Most of the threads address time penalities writing values, not reading them.

In a new app I am reading the propert value of  "STOP", as the node has an error cluster input.

That extra input helps with Data Flow paradigm.

Also I can "OR" the nodes error cluster output and "STOP" to a loop termination.

 

So what's the cost compared to encalsuplating "STOP" in a sequence or case structure?

0 Kudos
Message 7 of 11 (595 Views)
Reply
0 Kudos

Re: local vs property node

[ Edited ]

You can test it yourself.  Oviously the property node is far worse.

 

 

Message 8 of 11 (587 Views)

Re: local vs property node

[ Edited ]

Pappion wrote:

Most of the threads address time penalities writing values, not reading them.

 


Your use of a property node also precludes the use of latch action, which is the typical mechanical action of a stop button. What does the button do? What is the rest of the code architecture?

 

We cannot really tell without seeing the entire diagram.

 

If this is a toplevel stop to end the program, I would eliminate it anyway and use an event structure for the panel close event. It is not normal or intuitive to close an program with a special stop button in some poorly defined panel location, but everybody knows the meaning of the [X] in the upper right. You can always discard the event and handle special shutdown code. You could for example enqueue the stop command at the opposite end in that event case.

 

You can do that in a small parallel loop that just sits there, but enqueues an exit command if the user tries to close the panel.

 

Message 9 of 11 (573 Views)

Re: local vs property node

They are Test Methods for IP. So no, I can not share the APP.

The Event X close suggestion is useful. I will have to try it some time. Right now, I have no need for it.

I want to avoid using the ABORT button, and do error processing, hence the queue redirection to Exit State.

Anyway I did do my own testing, and feel like I'm goofing off....

 

Stop_Method_Timer.png

0 Kudos
Message 10 of 11 (530 Views)
Reply
0 Kudos