How do you avoid local variables?

[john_c_m]

In the application note about Labview performance and memory management, it states that you should avoid global and local variables when possible.

From what I can tell, your variables in labview are either controls/indicators, or global variables.If you want to write to a control, or read from an indicator, then you are forced to use a local variable.

The application note states that everytime you use a local variable, a copy of variable is made. Can someone explain to me why this is?

Also, if I am writing to an indicator in many different places in a VI diagram, then it is convienent to use local variables...is it possible to use the indicator directly in multiple places (meaning that the indicator shows up on the diagram
multiple times)?

[Ray.R]

Quote:
"From what I can tell, your variables in labview are either controls/indicators, or global variables.If you want to write to a control, or read from an indicator, then you are forced to use a local variable"

Not quite..
If you right-click an indicator or control, you can select "Create" then "Local Variable".

It is this type of local variable that they are referring to. It is a double box with the name of the control or indicator inside.

I find local variable useful. In a large vi (oh-oh.. I said large!!), I use the local variable to pass the value to a spot further inside, while keeping the lines clean. The local variable can obtain or provide a value. Right-click and select "change to read/write".

So if you are using controls and i
ndicators, do not worry about local or global variables.

For instance, I seldom use Global Variables, the other guy where I work uses them all the time. It boild down to a matter of taste, espceially if you also use TestStand.

So, in short, if you simply use controls and indicators, you are probalbly doing okay. I cannot comment on the performance issu, because there are so many implementation schemes that may affect performance that the local variables are probably the least of your worries..

Have fun with LV!!

Enjoy,

JLV

[Mads]

In LV the wire is the variable.

The controls and indicators are not supposed to be that much involved; they are there for GUI purposes and are used to send data to and from sub-VIs. Not much more.

If you need the data many different places wire it there. The indicator can only show one result anyway so there is no need to wire anything else than the final result to it. If e.g. you need to store a previous result use shift registers, do not write it to the indicator just to read it back.

Sure, sometimes locals can be useful in LV, but they are not to be used as in written languages. Especially avoid locals of large data sets; that's where the biggest penalty is. Get used to avoiding locals and it will contribute to much better G code.

[LarsRoe]

"The application note states that everytime you use a local variable, a copy of variable is made. Can someone explain to me why this is?"

LabVIEW has to ensure that everything is reading and writing from one master copy, so simultaneous reads and writes do not collide.

"Also, if I am writing to an indicator in many different places in a VI diagram, then it is convienent to use local variables...is it possible to use the indicator directly in multiple places (meaning that the indicator shows up on the diagram multiple times)?"

A Case Structure or a Select Node, e.g., can let you choose dynamically between multiple outputs. And if you have a loop around the control/indicator, it will be read from/written to once for each iteration of the loop.

Also,
local variables are more than a performance problem; They do not follow data flow. This makes it a real problem when debugging because the execution order is more complicated and less deterministic.

[Ray.R]

I guess this didn't help you..

Sorry!!!

[john_c_m]

Interesting...

So you're saying that the automatic multithreading is the reason why you can't reference a variable in multiple locations (lv must do some kind of race condition protection)?

Your point in paragraph 4 is exactly what I am asking...you say that if you have a loop around a control/indicator, then it will used in each iteration.

If I have two loops, where I want the current value to be used in every iteration, in both loops, then I am forced to use a local variable, as far as I know. Is that right?

I've attached a sample app, where I think there is no way to avoid locals. On the left, where no locals are used, once the program is started, the user can't change the function. On the right, the user can change the function, but
a local variable is used.

How could I avoid a local variable in this instance?

[Dennis_Knutson]

In your example, there's no real reason to have two separate while loops. You could have two different case statements in a single loop or just combine both math operations into a single case. That being said, you may have a situation where a local variable is called for. If it's something like a numeric or small string, then the extra memory is not something to get too worried about. When used correctly, they can be the best thing to use. It's just that they can be easily overused and that's why the guidelines say to avoid when possible.

[Bob_Preis]

Here are a few local variable alternatives.

Queue (if you only need read access in one other place)

Notifier (if you need read access in several places)

Global (might as well use local)

LabVIEW 2-style global (basically a subVI with uninitialized shift register; I use it all the time!)

[Mads]

The left and right side differs in more than one way; in the right example you have correctly placed the boolean inside the loop so that it will be read each time. In the left example the initial value will be passed to the loops and that's all. Incorrect data flow.

If you use two while loops then it's often OK to use a local, especially if it's something as simple as a switched boolean (it's therefor often used e.g. to stop multiple loops). In this case the boolean is a switch and there is little chance of a race problem (which you could have if it was latched; then the first loop might have reset the button before the second one has reacted to the initial value change).

Could the local be avoided? Well - the second loop could perhaps be avo
ided, depend on what else you want to do in the loop. With a second loop though you could use an occurence, notifier, functional global etc (a bit of an overkill here though) - there are a number of options. Again - for something simple a local is OK. Often people with experience with textual languages use locals everytime they need the data though; no wiring at all...

[AELmx]

Hi to all.

I have modified a software in order to enhance performance.

There was a loop, originally each time that a test was performed, the software read a max of 24 text files, and each file was used to fill a numeric array from 2k to 32k positions.

So i made a parallel loop with an event structure, read that files only when the softwares runs initially, when i change the model under test or when i press the button if i change the data files.

But in order to do that, i have created 24 local variables to pass the data from the event structure loop to the test loop.

I have been enhancing that program reducing the number of local and global variables, creating the data flow on my own (i have deleted tens of sequence structures), and choosing proper data types for controls / indicators.

The question is:

Which is the best method to remove those 24 array variables (and maybe another 10 big variables)?