How do you avoid local variables?

[RavensFan]

Use a functional global variable or Action Engine.  The reading of the files themselves could even be included inside the subVI .

If you need further help, please post a new message thread that includes your VI.  This one is 7 years old and is rather stale.

[Yamaeda]

---

john_c_m wrote: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)?

---

It's a common misconception that the "variables are controls". The variable is the wire. The controls/indicators are the functions input and output. The Control and indicators should never be used as variables (i've seen VI's with ~50 hidden controls as 'variables'). As the wire is the _real_ variable, a 'local variable' as it's erroneously called is a new variable, thus a copy. 'Local data copy' is a more correct name. :) If you're updating an indicator a Local Variable is actually often a decent solution, but often it's the result of a calculation you're showing, and shouldn't it then be after the calculation anyways? The main problem, as has been mentioned, is when locals are used to transfer data and/or are read from (alot) since it'll result in race conditions. The solution to that is sequences ... and then you get stuck in the dangerous sickness Sequentitis Localitis which is semi fatal to LabView. ;) The wire is the variable. Read it with me, the wire is the variable. /Y

[tbob]

The false perception that local variables are bad still exists.  Its not that local variables are bad.  The improper use of local variables is what is bad.  Properly used, there is nothing wrong with local variables.  The word "proper" is the key.  Learn what causes race conditions.  Then you will know how to avoid them and you won't have to write extensive extra code and you won't have to resort to tremedously long wires in order to avoid local variables.  However, don't use them until you LEARN the pitfalls.

To answer your question about writing to controls and reading from indicators, there are two methods.  One is the local variable and the other is a property node.  Of the two, local variables are more efficient.  Both can cause race conditions if not properly used.

I have attached a small VI to show how a race condition can be unpredictable.

[Yamaeda]

I tend to use a bunch of locals in event structures (similar to the mock example below), especially if the number of cases starts to get high. It is safe as i dont have several Locals within each event which avoid the race condition chance. In some cases i could clump up all controls to a cluster and have it wired through, and in others i could use an AE, but often enough this seems the leanest solution.

That said, Locals should still be minimized, but in this case i add the term (within each event).

/Y

[AELmx]

@Yamaeda:

I have a similar case with the one you have posted:

For example, if "Model" is assigned in the same event structure, i pass the value each iteration using a shift register. The bad thing is that you must wire the shift register in all the event cases. There is no risk of a race condition

My "problem", maybe it's not so bad, is that i need to pass big arrays to a parallel loop. So i use 24 array local variables. Some of my thoughts are:

1) Bundle the 24 arrays in a cluster, and use only 1 local variable. But the memory use i think will be the same or worst in this way.

2) Eliminate the parallel loop used for the test, and embed that code in the event structure. Then i can pass all the values using wires. Bad thing: the parallel loop its way big (width), and could be messy to be wiring about 30 shift registers in each case of the event structure. This code right now is sloppy, all from left to right, the error cluster gives the sequence, but the wires have a lot of bends.

My "problem", maybe it's not so bad, is that i need to pass big arrays to a parallel loop. So i use 24 array local variables. Some of my thoughts are:1) Bundle the 24 arrays in a cluster, and use only 1 read local variable. But the memory use i think will be the same or worst in this way.2) Eliminate the parallel loop used for the test, and embed that code in the event structure. Then i can pass all the values using wires. Bad thing: the parallel loop its way big (width), and could be messy to be wiring about 30 shift registers in each case of the event structure. This code right now is sloppy, all from left to right, the error cluster gives the sequence, but the wires have a lot of bends.

Sorry for not posting an image of the code, its from my job. But i will try to do a representation of it.

[SteveChandler]

Thirty shift registers? You could just bundle everything up into a cluster and have one shift register.

[Yamaeda]

Without knowing how the rest of the program looks/works i'd say Cluster! It's simply put soo damn easy to forget one of those 24 wires in a case and get strange errors. It's a bummer when a database suddenly stops working because you forgot the wire through the reference but remembered the error and the other 24 variables.

Since you'll need the data accessible in 2 loops i'd put that cluster in an Action Engine.

It also sounds like you could modularize abit more into sub vi's. Fewer function blocks allows faster understanding of what's happening in a screen. 🙂

/Y

[tbob]

As Steve Chandler mentioned, one shift register with a cluster can handle all of your needed local variables.  The picture below shows how to manipulate one of the variables:

[AELmx]

I did 3 clusters:

1) The first with 24 U8 arrays and 24 boolean arrays

2) Other with about 15 control references and about 10 numeric and string constans.

3) The last one with about 40 constants of different data types.

So as i am using the wires as variables, and i have erased a lot of controls from my front panel, because i am not using local variables and the values are passed to the subVIs using wires.

It was a really hard work.

Thanks by your advices.

[Yamaeda]

Well done, that sounds excellent!

Food for thought (and next program/project): If the booleans and U8's are connected, they can be clustered. If you have 24 (conceptually if you have more than 2) of something it probably should be in an array.

If the above is true, cluster wire 1 could be an Array of clusters, consisting of a Boolean array and a U8 array.

Again: Well done, i'm sure it feels pretty different looking at the program now and i assume you think somewhat different on how to program LV.

/Y