03-19-2015 05:09 PM
nathand wroteFor setting the value of a control, a local variable is slightly more efficient than a property node.
Actually, the local is A LOT faster than the property node. Remember that a property node or an invoke node of a front panel control forces a thread swap to the UI thread. This swapping of threads or horribly slow and forces the front panel to redraw (another really slow process).
03-19-2015 05:25 PM
Thanks, I'll give it a shot then and at worst use the local variable.
I was just under the impression, don't ever use local variables, its bad/lazy coding was what I kept reading/hearing over and over again. What is/are the situations a variable is an 'absolute no' and a why wouldn't you use it'?
03-19-2015 05:48 PM
@cscansin wrote:
I was just under the impression, don't ever use local variables, its bad/lazy coding was what I kept reading/hearing over and over again. What is/are the situations a variable is an 'absolute no' and a why wouldn't you use it'?
There's a missing question that goes with this, which is "WHY are local variables bad?" Because they break dataflow. Apparently we (LabVIEW users) have failed that part of the explanation, since you're not the first person to conclude that they should use a property node because local variables are "bad" (unfortunately, this is exactly the wrong conclusion, because property nodes are worse - they break data AND they're inefficient).
I wonder if the problem is the name "local variable" - programmers from text-based languages see "variable" and think "ah-ha! That's where I store data!" when they should be using a wire or shift register.
There are cases when a local variable is just fine. In my code, the most common case is to set the value of a control (since that cannot be done with a wire, and doesn't need to be done frequently). For example, a program reads a values from a configuration file at startup, and sets a controls to match the saved configuration. I might use a local variable when I have an event structure with a lot of cases and I need to read or write the same control or indicator in only a few (say 2-3) of those cases. However, if I need to use it in many event cases, I'll use a wire (and a shift register, for an indicator, passing the value through unchanged in the cases that don't change it).
If you're using a local variable to hold data, and there's no other reason to have that data on the front panel, then you shouldn't be using a local variable. If you need to update something the user sees, and you can't do it (or can't do it easily) by wiring to the terminal, then a local variable is acceptable.
03-20-2015 07:53 AM
Haha, I was tempted to ask why.
The property node for some reason feels like the smarter way of doing it. We hear about not using local variables so often and so rarely hear/read about property nodes, that it does not stick in our heads. When you're in the middle of programming and can't find out how to change the control without creating a local variable or another indicator, 'Tada!', there's the option a neither of those. Hopefully this will speed up my programs a bit. I'm a liberal user of property nodes and as you could tell invoke nodes. Which I assume invoke nodes have the same problem of being inefficient?
Thanks for the explanation!
03-20-2015 08:26 AM
Actually, what about other uses of the property node as well, such as disabling the controls and changing the text of a plot? Are those only accessible via property node or is the a more efficient way of accessing the non-data/value properties of a control?
03-20-2015 10:56 AM
@cscansin wrote:
Actually, what about other uses of the property node as well, such as disabling the controls and changing the text of a plot? Are those only accessible via property node or is the a more efficient way of accessing the non-data/value properties of a control?
You must use property nodes for those. Property Nodes do exist for a reason. It is just the value property that I mostly harp on people for.
And I feel your pain with NI saying "Don't use local variables". I have had many people make the same conclusions you did: just use the Value property. It is now my #1 pet peeve in LabVIEW code. There is almost a guarantee there is a lack of data flow if you are using that many locals and/or value property nodes. That is the part that people tend to not hear: use data flow instead of local variables.
03-20-2015 10:59 AM - edited 03-20-2015 11:00 AM
@cscansin wrote:
Actually, what about other uses of the property node as well, such as disabling the controls and changing the text of a plot? Are those only accessible via property node or is the a more efficient way of accessing the non-data/value properties of a control?
These are typically rare events. You typically don't enable/disable a control at a fast rate. You don't change the plot name cosntantly.
SImply ensure that the property is only written when it differs from the existing state. Don't hammer the same property with the same value over and over.
03-20-2015 11:05 AM
@cscansin wrote:
Actually, what about other uses of the property node as well, such as disabling the controls and changing the text of a plot? Are those only accessible via property node or is the a more efficient way of accessing the non-data/value properties of a control?
Those properties are accessible only through property nodes. You're unlikely to update those properties frequently - certainly no faster than the user can see and react, and usually much less often than that - so performance isn't an issue.
03-20-2015 12:32 PM
I may be guilty of hammering the same property over with the same value over and over...
Awesome, this does calirfy the difference between and proper usage of local variables and property nodes. I added those tags to this discussion! (The title for the post has nothing to do with what I learned here, haha).