diffrent of "property->Value" and "Local Variable"

[MViControl]

Hello,

Does anyone know the different between "property->Value" and "Local Variable", I feel they have same funtion in Labview.

[crossrulz]

Hello,

Does anyone know the different between "property->Value" and "Local Variable", I feel they have same funtion in Labview.

Functionally, they are the same. But the implementation is totally different. A property node will force the front panel to draw and will really slow down your program. Local Variable is faster, but not nearly as fast as a wire, shift register, or terminal.

[Grampa_of_Oliva_n_Eden]

Functionally, they are the same. But the implementation is totally different. A property node will force the front panel to draw and will really slow down your program. Local Variable is faster, but not nearly as fast as a wire, shift register, or terminal.

adding a little to the above....

LV has a special back-door mechanism for updating via a local.

A property node on the other hand uses the UI thread to do its work so there could be thread swapping issue if using this method.

Ben

[McKman]

Techie,

I believe the benefit of the "property node value" is that it does not require a copy of the data to be made in memory like a "local variable" would. From what I understand LabVIEW keeps a copy of the data for each local variable in the code. So if my code occasionally updating a front panel graph that has a lot of data, I use a property node since speed is not an issue and I don't want to eat up memory with multiple copies of data. But if I wanted to quickly update a front panel graph with small amounts of data, I would use a local variable. Where is the break even point? I don't know. You can always test it out if you want to find the optimum choice.

Mark

[Black Pearl]

As mentioned before, the use of the property node is slower because of the 'thread swapping'. For some reasons, the UI thread is a single thread (no multicore/hyperthreading here) and thus poses a bottle neck. So you should always rarly use local variables and far less frequently the property nodes.

There are some cases where you need the property nodes though. If you are working with a cluster, you can read/write the value of a single (and even random) element of the cluster with the property node.

Also if you use other properties as well, you can assign the value, as the thread swapping already needs to take place.

Felix

[EricLarsen]

Using a local variable in a Real-Time time critical loop is also much faster and less jittery than a property node. Yes, I know you're not supposed to use either in a time critical node, but let's face it, we're all guilty of that now and again, especially during the development stage.

[crelf]

I always figured that you should use locals over property nodes (for reasons already mentioned) - unless you were already using a property node anyway (to set some other property). Also, when speed really isn't an issue, I like that I can use the error clusters of the proprty nodes to both force execution order and decisions based on those errors (note: you can right click on a property node and select "ignore errors inside this node" or something like that).

[Mark Yedinak]

I always figured that you should use locals over property nodes (for reasons already mentioned) - unless you were already using a property node anyway (to set some other property). Also, when speed really isn't an issue, I like that I can use the error clusters of the proprty nodes to both force execution order and decisions based on those errors (note: you can right click on a property node and select "ignore errors inside this node" or something like that).

The ignore errors inside only pertains to errors generated inside the property node, not the error passed in. I wish it did allow you to ignore input errors. this would be handy when using the error cluster to force data flow.

[Aristos Queue]

Techie,

I believe the benefit of the "property node value" is that it does not require a copy of the data to be made in memory like a "local variable" would. From what I understand LabVIEW keeps a copy of the data for each local variable in the code. So if my code occasionally updating a front panel graph that has a lot of data, I use a property node since speed is not an issue and I don't want to eat up memory with multiple copies of data. But if I wanted to quickly update a front panel graph with small amounts of data, I would use a local variable. Where is the break even point? I don't know. You can always test it out if you want to find the optimum choice.

Mark

Sorry, McKman... the Value property does make a copy of the data for the wire. Otherwise after you read the value, if someone modified the value on the front panel, your block diagram would suddenly have a whole new value, right in the middle of execution. That would be very very bad. The difference between local variable and property value is the UI thread swapping, as mentioned by others.

[Anil Reddy]

I would like to mention some special case here. For tab display.

If we try to choose the tab using Local Variable....it will not work all the times........

If we use Property-->Value, it always works...................

[huotom]

I always figured that you should use locals over property nodes (for reasons already mentioned) - unless you were already using a property node anyway (to set some other property). Also, when speed really isn't an issue, I like that I can use the error clusters of the proprty nodes to both force execution order and decisions based on those errors (note: you can right click on a property node and select "ignore errors inside this node" or something like that).

I seldom use local variable except for path or boolean value because I'd like the error in/out cluster force execution order.

[MikaelH]

I would like to mention some special case here. For tab display.

If we try to choose the tab using Local Variable....it will not work all the times........

If we use Property-->Value, it always works...................

See this post regarding this: http://lavag.org/topic/11081-tab-control-bug/

Cheers,

Mikael

[MViControl]

All,

If the difference between "Local variable" and "property value" is only UI Thread swapping(assume they are all consume memory), then I think we should only use "property" to handle those things related to the GUI, and local variable would be better to handle caculation in background etc.

If I am wrong, please correct me.

[Black Pearl]

Calculations should be done by wire and not by locals. The biggest wrong on locals is the name 'variable', that leads beginners to use them too much. Locals are only to display the results to the user (and normally the terminal is enough).

Felix

[crelf]

The ignore errors inside only pertains to errors generated inside the property node, not the error passed in. I wish it did allow you to ignore input errors. this would be handy when using the error cluster to force data flow.

I totally *don't* want that - that'd obsfucate to much IMHO. Use the "Clear Errors" vilib vi. I think that, rather than adding this functionality specifically to the property node node, I'd rather see the exection sequence container we talked about here.

I seldom use local variable except for path or boolean value because I'd like the error in/out cluster force execution order.

...and that's totally valid if exectution order is important for that part of your code and it can't be controlled otherwise.

[vugie]

So the task for someone skilled (or who wants to be skilled) in XNodes is: create a local variable with error cluster terminals

[Mark Yedinak]

I totally *don't* want that - that'd obsfucate to much IMHO. Use the "Clear Errors" vilib vi. I think that, rather than adding this functionality specifically to the property node node, I'd rather see the exection sequence container we talked about here.

However this implementation would be much more explicit than a subVI which simply passes an error through it. At least here the glyph could be changed just like it is when you ignore errors inside the property node. If someone writes a subVI that ignores the errors other than looking at the code you have no idea that the error will be ignored.

And yes, if I had to choose between this feature or the sequence container I would opt for the sequence container.

[crelf]

However this implementation would be much more explicit than a subVI which simply passes an error through it. At least here the glyph could be changed just like it is when you ignore errors inside the property node. If someone writes a subVI that ignores the errors other than looking at the code you have no idea that the error will be ignored.

We're getting totally off topic here, but what would happen if the property node did ignore errors? Would the error output be the error input? Would errors that occured in the property node be merged? Wuold this be extended to VIs and primatives (and other things too)? Of so, how would they be handled? I agree that it *could* be useful, but I think what we have is intuative and works fine.

[Rolf Kalbermatter]

All,

If the difference between "Local variable" and "property value" is only UI Thread swapping(assume they are all consume memory), then I think we should only use "property" to handle those things related to the GUI, and local variable would be better to handle caculation in background etc.

If I am wrong, please correct me.

The thread swapping is only one aspect of difference. A Value property always operates synchronously. That means it will wait until the new data has been drawn in the UI (quite logical since it already swapped to the UI thread and incurred that overhead anyhow, just do the drawing as well).

A local variable will behave mostly like a terminal. Yes there is an additional copy involved but the worst thing about locals (and globals and property values) is that you can easily create race conditions and those funnies can be very hard to debug, since the fact of debugging can chance the execution order and create or avoid such race conditions randomly.

And as long as the according control is set to not operate synchronously, updating a local or terminal will NOT wait until the new value is updated on screen. It will simply drop the new value into a buffer of that control and go on. The UI thread periodically will check for such controls that need an update and redraw them.

This has the advantage that a control that gets updated in a loop will not slow down that loop very much. You can make a small experiment:

Create a loop that executes 10000 times and just creates some random value. In one case wire that random number inside the loop to a terminal or local not set to be synchronous (the default). In the other case wire it to a terminal or control set to be synchronous or a value property.

You should see the asynchronous terminal executing fastest directly followed by the asynchronous local. Then far slower the synchronous terminal and local (really little difference here) and last but not least the value property which will be the slowest by far.

The reason is that updating a control takes a long time in comparison to computing numbers and shuffling data around in memory. So in asynchronous mode the loop iterates many 1000 times per second, while only maybe 60 of those values are really shown on the frontpanel and if someone now says: what? LabVIEW does not show me all values! Then think again. You can't even see those 60 values as they change way to fast for the human eye so why try to update more than that?

In synchronous mode, and the value property is inherently synchronous with no way to avoid that, the loop will only iterate in the 100ds per second as for each new value, the control has to be redrawn completely.

Rolf Kalbermatter

[crossrulz]

I did something similar to what rolfk is suggesting for a presentation I gave back in April. I would like to attach the results, but apparently I'm not allowed to upload .xls files. I used a for loop to write to and indicator using the terminal, local variable, an explicit property node, and a property node w/ a reference 1 million times.

Keep in mind that I ran this on a Windows machine that IS had a hand in, so the timing can be off a little bit.

Edited September 30, 2009 by crossrulz

[Black Pearl]

Can you please tell us the data type of the control. Benchmarks that were given on the feedback node (I think it was Darren's blog) have shown differences depending on the data type.

But the picture is clear and as expected.

Felix

[Aristos Queue]

We're getting totally off topic here, but what would happen if the property node did ignore errors? Would the error output be the error input? Would errors that occured in the property node be merged? Wuold this be extended to VIs and primatives (and other things too)? Of so, how would they be handled? I agree that it *could* be useful, but I think what we have is intuative and works fine.

There are plenty of nodes in LV that execute even if there's an error in -- Close Reference, for example -- and the behavior there is well defined. I would assume the property node would follow suit. I think the bigger question is how would we change the block diagram to indicate "executes even if there's an error in" and whether this setting would change the behavior *between* properties... currently if you have 3 properties on a single node, if an early one triggers an error, the later ones don't execute at all.

[Black Pearl]

AQ: I really would like to see this behavior for disabled=0 (if an error occures upstream, the exit button is not enabled, bad...). Maybe we could just have some properties duplicated with something like (Ignore Errors).

Felix

[James Beleau]

Adding dataflow to a local seems too easy.

[Mark Yedinak]

There are plenty of nodes in LV that execute even if there's an error in -- Close Reference, for example -- and the behavior there is well defined. I would assume the property node would follow suit. I think the bigger question is how would we change the block diagram to indicate "executes even if there's an error in" and whether this setting would change the behavior *between* properties... currently if you have 3 properties on a single node, if an early one triggers an error, the later ones don't execute at all.

The way I would envision this to work would be if you select to ignore incoming errors the error input would change from black to red. This would be similar to how the current ignore errors on the inside works. I would also envision this option only affecting the input errors. Internally generated errors would be control by the state of the "Ignore Errors inside Node". If the "Ignore Input Errors" (new feature) is enabled and an error is input then that error would be passed through. If an error occurs on the inside then just like today in most VIs the internal error would overwrite the input error.