LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Question about Local Variables (Multiple answers welcomed!)

A couple of questions about Local Variables

1. Programmers always say: “Do not abuse of Local Variables”. I’d like to know, when and where Local variable are most efficiently used?
2. If I have to create a couple of local variables, is there anyway to “clone” them without going through the repetitive “create/local variables” mouse click each time? (When I try to copy and paste, it creates a new variables instead of the one that I am trying to reproduce)
3. Which is faster in execution: Updating a variable through a) writing to property node/value or b) through local variable

Everyone’s input is welcomed, so if this question is already answered, please
feel free to add additional comments/answers!
0 Kudos
Message 1 of 23
(3,508 Views)
1. Use Local Variables in user interface code and no where else. The only exception is using a local variable of a cluster output to define the datatype for a bundle by name node.

2. You can drag copy them then right click to get to a menu of all the currently defined controls and indicators on the VI.

3. B. The problem with A is that it forces a thread switch to the user interface thread--which can take time if you aren't already in it, and it's a very convoluted process under the hood. NI's advice never update indicator values through a property node unless you absolutely, positively can't figure out some other way of doing it.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 2 of 23
(3,508 Views)
What's the difference between local variable and
"value" element of property node?
0 Kudos
Message 3 of 23
(3,508 Views)
2. You can clone them by pressing CTRL and drag and drop.
0 Kudos
Message 4 of 23
(3,508 Views)
Hiya

I always thought NI said "Do not abuse use of Global variables"?

My programming philosophy is basically "Use the minimum", ie. If you cant use the basic LV functions such as shift registers or even wiring around objects, then use a local variable. And if you cant use a local variable or any other method, then use a Global - but always try the minimum first.

The hard thing is knowing what functions should be avoided. I now know property nodes are bad as these update the front panel which takes up alot of memory, so probably the faster method will be 3b - updating variable through local variable. You can always test this by creating a VI of each method, writing to each variable 1000 times and programmatically measuring the time it takes th
e vis to execute (by using a timed sequence structure). Let me know if you need help with this.

I hope this helps you..

Kim
0 Kudos
Message 5 of 23
(3,508 Views)
If you have to use local variables to connect basic signal flows instead of wires, it sounds like the code might have bigger problems that whether or not local variables are good things--like for instance why the functionality the diagram is defining isn't broken down into more subVIs.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 6 of 23
(3,508 Views)
Local variables are ok if used in very limited circumstances. The value element of a property node is a Very Bad Thing. Of all the ways of getting at the value of a control or indicator it is the absolute slowest and most inefficient.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 7 of 23
(3,508 Views)
> I always thought NI said "Do not abuse use of Global
> variables"?
>

We did. We also said not to abuse locals.

There are perfectly good uses for these and for the value property as
well, but they shouldn't be used for data manipulation and storage, and
rather for UI.

The big problem is that far too often, a person familiar with a textual
language will equate locals with textual variables and sequence frames
with a line of text. They will take statements like z= x*x+y and will
drop four local variable, three reads, a write, and a multiply and an
add. The problem with this sort of coding style is that it runs slowly,
it is hard to read, it has potential for lots of race conditions, it is
hard to maintain, and it takes a longer tim
e to write the code. If the
description above sounds familiar, please look at examples, read the
articles and manual on race conditions, and read about shift registers.

Greg McKaskle
0 Kudos
Message 8 of 23
(3,374 Views)
When you say 'you' you dont mean me do ya? I only said that about using wires cause i've seen code posted on here where people have gone local crazy and used them in places just because they look more tidy on the diagram!

You are right about subVI's though...i should have mentioned them too.
0 Kudos
Message 9 of 23
(3,508 Views)
Actually, I meant "you" in the editorial sense. Sorry, no personal slight intended. Edit previous statement to say, "If one has to..."

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 10 of 23
(3,508 Views)