How "local" are Local Variables?

[RTSLVU]

I avoid local variables at all costs so don't have a lot of experence with them. Are local variables only "local" to the sub-vi they are in or if you used the sale local variable in several sub-vi's in the same program would they all share the same varaible?

I have been given the task of fixing a LabView program we had subcontracted out. The unit it runs on has three identical modules that are used to profile and discharge profiles of different battery types. Anyway the program has a bug in it where all three on screen V/I graphs show identical V/I curves.

My original thought was the subcontractor got the program working on one module then replicated the code to the other two. But didn't make new graphs or was referencing the V/I measurement module 1 on graphs 2 and 3. First glance at the code it looked like it should be working properly.

Digging deeper I see the contractor made this sub-vi to build the cluster for a Waveform Graph. In this sub-vi he used a local array variable, called "local array".

When he replicated this for the two other modules he used the same "local array" local variable. Since all three "programs" (one for each module) run inside one larger loop wouldn't they all be reading and writing the same "local array" local variable?

I have attached the origonal sub-vi (V_WFM.vi) and one of my replacements (V_Wave_1.vi) I have made three copies of my vi's and each module will get it's own sub-vi.

Am I thinking correctly here?

[altenbach]

No, the "local array" is local to its own subVI, and is no reachable from anywhere else.

This code needs some cleanup!

[crossrulz]

A local variable is only accessible to the actual VI it is in.  Just like with C++, a local variable is only accessible to the actual function it is in.

If a contractor used local variables the way you are describing, they should be fired and you should hire an NI Alliance Partner.  I didn't look at any of the code, but I fully trust Christian's evaluation that it needs some major clean up.

[RTSLVU]

Thanks guys, I see I still have a lot of work to do. I thought for sure I had finally found the graph bug.

The contractor is long gone and looking at his code is generally sloppy, lots and lots of local variables, several flat sequences, didn't TypeDef enum constants in a state machine.

My company is not paying me enough.

[altenbach]

Also note that the output cluster forces a coercion, because "t0" and the array is SGL (dt is dbl). The "to DBL" conversions are a complete waste unless you change the cluster. 😄

[RTSLVU]

Thanks!

Figuring out why all the clusters had coercion dots on them was on my to do list.

[altenbach]

• Also note that there is quite a bit of sloppy code. Converting an I32 to SGL can irrversilby drop a few significant digits. Not future-proof!
• There is a negate primitive, so multiplcation with -1 should never be seen.
• The single-iteration while loop can be removed once you replace the shift register with a globally initialzied feedback node.
• The "index array" in the true case can be replaced by a single "build array" of height 1.
• The bundling occurs in both cases, thus it belong after the case structure.
• Why is the data not valid after the TRUE case. It contains one element.
• "Insert into array" in case "0" can be replaced by a simple "build array" to append a scalar to a 1D array.

How is this subVI used in the rest of the code? looks like a poorly implemented action engine.

[tst]

I didn't look at the code, but there is something that should be clarified - a local variable is part of the data space of a VI. That means that if the VI is non-reentrant (or presumably shared reentrant and being reused. I never checked that), then the local WILL be shared between those instances. If the subVI is reentrant (preallocate), then each copy ON THE BD will have its own copy (the caps part means, for instance, that calling the VI in a loop will reuse the instance between iterations).

[altenbach]

Yes, the VI is not reentrant and looks like a poor action engine.

---

@tst wrote:

I didn't look at the code, but there is something that should be clarified - a local variable is part of the data space of a VI. That means that if the VI is non-reentrant (or presumably shared reentrant and being reused. I never checked that), then the local WILL be shared between those instances.

---

The local will be local to the subVI. Only data that's available via the connectors is shared. But yes, if the VI is not reentrant, all instances operate on the same subVI and have the same dataspace. It is not clear enough from the original question what's important here. I't not the local variable per se that's shared, its the entire subVI that happens to use a local variable.

It seems one of the subVIs has been rewritten to use an uninitialzied shift register instead of the local variable. The same applies here too, of course.

[RTSLVU]

---

@altenbach wrote:

• Also note that there is quite a bit of sloppy code. Converting an I32 to SGL can irrversilby drop a few significant digits. Not future-proof!
• There is a negate primitive, so multiplcation with -1 should never be seen.
• The single-iteration while loop can be removed once you replace the shift register with a globally initialzied feedback node.
• The "index array" in the true case can be replaced by a single "build array" of height 1.
• The bundling occurs in both cases, thus it belong after the case structure.
• Why is the data not valid after the TRUE case. It contains one element.
• "Insert into array" in case "0" can be replaced by a simple "build array" to append a scalar to a 1D array.

How is this subVI used in the rest of the code? looks like a poorly implemented action engine.

---

The original sub vi (V_WFM.vi) from what I gather is used to build the waveform cluster that is fed along with another waveform cluster to an onscreen graph of voltage and current for the last 10 minutes or so. I believe this would be dependent on how often the measurement are taken. "Local Array" is used to hold the values of the measurement between iterations.

This sub vi is being used simultanusly by three different "sub loops" in the same program. That is what brouhgt up my question.

If "sub loop 1" uses V_WFM.vi at the same time "sub loop 2" and "sub loop 3" are using it wont the data in "Local Array" be a conglomeration of the three?

The poorly implemented action engine is my attempt to get rid of the local variable "local array".