Question about Local Variables (Multiple answers welcomed!)

[FightOnSCTrojan]

Ok, so far the use of Local Variables was portrayed as inefficient. I’d like to ask a few more questions about the axis of evil in LabVIEW (Local and Global Variables):

1. Without using local variables, how can one “write” (or change value of) a control, or read from an indicator if those actions were needed in different frames of a case structure?
2. Repeating the same question for last time: Can Locals ever be “good”? I mean instead of citing why locals should not be used, can someone list instances where Locals are “good”?


Thanks

[mikeporter]

1. In a way this is the point, you can't -- but the only time you should ever want to is in a user interface situation. For anything else, the code will be reading inputs, performing some operation and then generating an output. Changing outputs several times during the course of operation doesn't accomplish anything since those intermediate values will not be seen by the calling code.

2. Good locals are ones used in creating a user interface. When creating a GUI you -- oops, I mean -- one 🙂 will very often want to change the value of a control or indicator from several places. In such cases, a local variable is the only way of making the GUI behave the way you need it to.

The rule of I use is for my application in general is to
use only the very best design and implementation practices--for GUIs I do whatever I have to do to get the thing to behave as required...

Mike...

[Greg_McKaskle2]

> 1.   Without using local variables, how can one write
> (or change value of) a control, or read from an indicator if those
> actions were needed in different frames of a case structure?

One technique, which will not eliminate all uses, but which I often use
instead of locals within various frames in a case structure is to wire
the current value into the case statement. Some frames wire the value
straight across, which other modify the value. The various computations
all merge to the same terminal on the right side of the case, and the
write to the indicator via a terminal or a local, is done once outside
of the case structure. Often, this value will also continue to a shift
register and be fed back into the diagram from the
left shift register
during the next loop iteration.

Updating an indicator with the same value it currently holds is quite
cheap as LV avoids drawing in many of the cases. Same for properties, etc.

> 2. Repeating the same question for last time: Can Locals ever be
> good? I mean instead of citing why locals should not be
> used, can someone list instances where Locals are good?
>

The most common usage is to control multiple loops with a single Boolean
button. In this case, one button is polled by reading in each loop, and
that value controls whether the loop continues or finishes. A second
common situation is to initialize the values of a control for putting up
some sort of dialog. You init the default value for the dialog, but
allow the user to modify it, and read the value back when the OK or
Apply is applied.

Greg McKaskle

[FightOnSCTrojan]

Thanks Greg, for your insightful input!

[Jonas 65]

Hi,

I was looking for a topic like this one since I use many (too many ??) local variables in my application. I have recently stated working with LabVIEW and I have understood that Global aswell as Local should be avoided as much as possible.

However, most of my locals come from indicators and controllers. And if I was to use Shift Registers, I would have wires everywhere in my diagram (and wouldn't be able to read it anymore).

I would like to know if anyone could take some time to have a quick look at my VI and tell me how bad the situation is. In a way, to tell me if the locals are properly used...

Thanks in advance.

[allaba]

I only had a quick look on you VI.
Of the 88 locals you use you probably could avoid 70 or so without using
shifts.
(Of your you can in principle avoid all, but on the cost of a messy block
diagram probably)

I don't understand all the details, however, since you made your code nearly
unreadable: you use at many places different variables with the same name,
e.g. V for some voltages.
AVOID THIS UNDER ALL CIRCUMSTANCES.
If you did it to make the names on the front panel better readable, there
are other ways to achieve this:
Use captions for the variables instaead of labels.
Format text within labels or captions with different fonts or different
sizes (super/subscript as a text attribute is not available in LV, AFAIK).

It is extremely difficult to analyze
your block diagram having these
embarrasing duplicate names...


"Jonas" schrieb im Newsbeitrag
news:506500000005000000C30E0100-1042324653000@exchange.ni.com...
> Hi,
>
> I was looking for a topic like this one since I use many (too many ??)
> local variables in my application. I have recently stated working with
> LabVIEW and I have understood that Global aswell as Local should be
> avoided as much as possible.
>
> However, most of my locals come from indicators and controllers. And
> if I was to use Shift Registers, I would have wires everywhere in my
> diagram (and wouldn't be able to read it anymore).
>
> I would like to know if anyone could take some time to have a quick
> look at my VI and tell me how bad the situation is. In a way, to tell
> me if the locals are properly used...
>
> Thanks in advance.

[Jonas 65]

Sorry for this messy VI I attached...

I have renamed all the indicators/controllers using the labels in the diagram and the corresponding item in the front Panel with formatted text : should be easier to read.

So if you would like to take some more time. I am not sure how to avoid 70 or so local variables...

[unDees]

In response to item 2 above: on Win32, after you've Ctrl-dragged to copy the item, there's an alternative to using right-click >> Select Item. In LabVIEW 6.1, you can just left-click inside the newly cloned local variable and immediately select the control/indicator you want it to point to.

[Alberto]

Hi Jonas,
when you have a large number on controls/indicators on the front panel, I believe the best way is to group them inside clusters. Labelling each element you can use unboundle-boundle by name functions.
In your vi you could have a cluster for Spectrometer parameters, one for Voltage Measured and so on; you would group all the controls/indicators in 3-4 clusters.
This has several advantages:
- you can easily use shift registers, one for each cluster in the main while loop
- by the use of shift registers you won't need to use so many local variables in nested case structures
- you get rid of the possible race conditions and improve performance
- the connector panes of your sub-vis will have a reduced number of connections
- your
diagram will be easier to read and mantain

Hope this helps,

Alberto

[Jonas 65]

Thanks Alberto, I'll have a close look at this option !

Any other comment is welcome !!