What is difference between local variable and property node ?

[jwdz]

What is difference between local variable and property node ?

[devchander]

To put it in simplest functional terms

Local variable can be used to read data that a control/indicator contains, or write data to that control/indicator

Whereas with a property node, you can do this operation as well as set/query all the associated properties of that contol/indicator ( like  make that object  invisible, disabled, assign a label name and lot more that you have to explore to know)

Message Edited by devchander on 09-21-2006 06:56 AM

[JeffBoettcher]

To expand slightly on devchander's response, local variables can be used to read/write a control's value if you don't have access to the terminal for the control on the diagram.

Property nodes can be used for the same thing (using the Value property) as well as many other things, as devchander mentioned.

However, if your goal is simply to read/write the value of the control, local variables are more efficient than property nodes (though still not as efficient as using shift registers and wires).

[Ray.R]

One important item to consider when choosing between a property node or a Local Variable when reading or writing a value is "race conditions"..

Local Variable may be more susceptible to them. 

RayR

[bfarley]

JLV,

Why would property nodes be more susceptible to race conditions?

A problem I have with locals is size.  If you have a control with a long name - the local gets huge and takes up a lot of screen space.  It would be nice if locals were a standrd size and identified by their label on the block diagram instead of embedding the label in the local itself.

Bill F

[shoneill]

Bill,

He actually said the opposite, that LOCALS may be more prone to race conditions.

This could have to do with the fact that they have no inputs or outputs except the single one providing access to the variable itself.  A property node has error terminaly, allowing the use of data flow to control when the read/write takes place.

LV being a parallel-executing thingy will only follow a specific order if the flow of data tells it to.

The label thing is OK as long as it's not editeable.  A shrinkable Local would be very nice though.  Nice idea.

Shane.

[chrisger]

hi there

-"Why would property nodes be more susceptible to race conditions?" property and invoke nodes have error inputs/outputs. this allows you to create a dependency in execution by wiring the error clusters. with locals you have to use sequence structures ore something like that to force a dependency.

- locals create data copies! so if you store lots of data in your controls memory may be an issue! property nodes don't create data copies.

- you should always seperate naming for the GUI from the naming on the block diagram. for the GUI use the "caption", for the diagram the "label". the locals name is the controls label.

- one of the most efficient ways to transport data through your app is the usage of "Functional global variables" aka "LV2 style globals". search here for this keywords. this dosn't use either locals nor property nodes.

[Ray.R]

Thanks chris,

You described it very well..

---

@JoeLabView wrote:

Local Variable may be more susceptible to them. 

---

I thought I mentionned Locals..  I try to avoid them as much as possible.  I recently discovered that they are indeed useful when dealing with IMAQs.  However, as Chris described, there is no dependencies and they are resource hungry..

Actually, in the Basics course, there is an example of race conditions that occur when using Local Variables.

RayR

[chilly_charly]

To make things clear, here are two small examples that show how nasty locals and value properties can be to the naive programmer.

- Open the diagram of the race condition.vi before running it and try to predict what will be the values of the two counters after the third run.

- Use the Compare Locals Properties and Wires.vi to find out how slow locals and value properties can be (times 1000+).

This being demonstrated, I must add that I use globals and value properties quite often, because they are often very convenient 😉

[bfarley]

Chilly,

One option you didn't try was using refs.  I thought that would be faster - forget it, it is exactly the same as using property nodes ( I guess this is what property nodes are doing under the hood).  I suppose this is because even though you are referencing the data, a copy of it is made to put on the wire - so you really aren't using a pointer to a ref type in the C++ sense - there is still a unbox/box operation going on every time thru the loop.

Bill F