Jump to content

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


MViControl

Recommended Posts

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.

Link to comment

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

Link to comment

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

Link to comment

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

Link to comment

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).

Link to comment

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.

Link to comment

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.
Link to comment

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.:rolleyes:

Link to comment

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.

Link to comment
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.

Link to comment

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.

Link to comment
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.

Link to comment

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

Link to comment

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.

post-11268-125431650764_thumb.png

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 by crossrulz
Link to comment
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.
Link to comment

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.

post-4959-12543439171_thumb.png

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.