LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
WSmith

Local Variable Page

Status: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

Wouldn't it be nice to the have a local variable page like the global variable page.

 

Front panel objects are local variables but sometimes it is not always desirable to see this local variables. There are three options around this: 1) put the local variable off to the side side of the visible display, 2) make the local variable hidden, or 3) use a global page. By putting these variables on a global page they are no longer local and be be changed by other VI's. The scope of a local variable needs to be limited to the VI that uses it. While it possible to use the first two workarounds and make local variable hidden or put them off to the side it makes the front panel messy. Things are complicated even more because if local variables are double-clicked on the block diagram because it brings focus to them on the front panel and this can be a problem if the front panel has a status bar or a toolbar and things are carefully arranged.

 

Another possibility would be to enhance the functionality of the block diagram constants so they can be variables.


 

14 Comments
altenbach
Knight of NI

Local variables are not "variables" in the classic sense and should not be used as such. Don't try to do literal translations of text based code using hidden front panel objects as variables. In LabVIEW, the wire is the variable. 😉

 

We also already have shared variables that don't involve and FP objects.

 

I don't like this idea, it tries to promote locals to something they are not and should not be.

AristosQueue (NI)
NI Employee (retired)

Altenbach is correct -- variables in text code should become wires in LabVIEW code, not variables of any kind (local, global or shared are all equally problematic).

SteveChandler
Trusted Enthusiast

If variables in text code are equivalent to wires in LabVIEW code, then what is the equivalent for a LabVIEW variable in text code?

 

I am just curious and I don't like the idea either. I find myself using locals on occasion in initialization code and a few other circumstances. But if a vi requires any kind of local variable managment tool then they are probably way overused.

 

But as for the front panel getting all messed up when you click on a terminal that is way off the page there is a cool solution. Just put a (possibly hidden) decoration around the part of the front panel that you want to see and use the Open G size to largest decoration vi.

=====================
LabVIEW 2012


WSmith
Member

Thanks for the comments guys.  I'm not sure how you inferred that I was equating LabVIEW local variables to something in a text based programming language but that was not my intent.  I am simply stating that many top level applications often require local variables that you may not want displayed on your UI.  Some examples might include: counters, the recent path a user just used, ref nums, temporary buffers, etc.  In my post I have enumerated some "workarounds" to hide these front panel items (a.k.a. local variables). 

 

My main interest is a cleaner and more maintainable top level application.  I am less concerned about SubVI's and how messy that front panel can look because there are extra terminals on the front panel.

AristosQueue (NI)
NI Employee (retired)

> If variables in text code are equivalent to wires in LabVIEW code, then

> what is the equivalent for a LabVIEW variable in text code?

 

The closest would be a heap-allocated pointer to data allocated within the function.Something like:

             int *x = new int(0);  // yes, I'm cribbing together syntax from a couple languages, but you get the point

 

There isn't an exact analog to all the implications of using a local variable, but in my opinion that has the closest in terms of weight and accessiblity.

SteveChandler
Trusted Enthusiast

WSmith, you don't need to use hidden controls for those things. You could use functional globals or classes to store data that you do not want on the front panel.

=====================
LabVIEW 2012


WSmith
Member

I agree, those are other good ways to get rid of hidden controls and would be a more preferred technique.  The only downside is that they require more work.  As a LabVIEW consultant who gets hired to fix or update software, you would be amazed at all the bad G-code I come across from either inexperienced or lazy programmers.

 

Your idea of a functional global has got me thinking though.  I could envision using something like the right-click framework to generate a functional global on-the-fly.  Just click on block diagram constant or a wire and select "create Functional Global". 

 

Wow, isn't the Idea Exchange a wonderful thing.

altenbach
Knight of NI

> I'm not sure how you inferred that I was equating LabVIEW local variables to something in a text based programming language but that was not my intent.  I am simply stating that many top level applications often require local variables that you may not want displayed on your UI.  Some examples might include: counters, the recent path a user just used, ref nums, temporary buffers, etc.  In my post I have enumerated some "workarounds" to hide these front panel items (a.k.a. local variables). 

 

Typically, many seasoned text programmers new to LabVIEW use local variables like crazy, e.g. lining up all terminals disconnected near the top of the diagram and do everything with locals in the wired code.

 

Apparently, you are one step better already 😄 Still, for a toplevel VI, you could keep all state data in a shift register containing a cluster of all state data (counters, recent path, refnums, buffers, etc.). (For simple counters, I typically use a dedicated shift register). Data in a shift register is local to the diagram and you can read (unbundle by name) and write (bundle by name) back into the same cluster, and even read-modify-write using the in place element structure. If the cluster elements are named well, the (un)bundle operations etc are very well self documenting, even better than for locals. For a global use, you would isolate the shift register into a subVI, creating a functional global or action engine.

 

A terminal should only be needed for user interaction, either to display something to the user or to read a control (or, in the case of subVIs, to transfer data from/to the subVI). Local variables are needed to e.g. update controls programmatically to some new settings, but for not much else. Sure I use locals, but only if needed.

 

Local variables always cause extra data copies, which can be expensive for large data sets. (There is a copy in the transfer buffer and the control itself contains data). See also this and this and this. Data that is only needed locally by the code should not stick it's head out all the way to the UI. That's just not right! 😉

 

 

 

 

 

tst
Knight of NI Knight of NI
Knight of NI

> I could envision using something like the right-click framework to generate a functional global on-the-fly.  Just click on block diagram constant or a wire and select "create Functional Global".

 

 

Note that a simple get-set uninitialized-shift-register global is not any safer than a local (except you can use it in multiple VIs, so you might as well use a global if you're doing that).


___________________
Try to take over the world!
AristosQueue (NI)
NI Employee (retired)

> Note that a simple get-set uninitialized-shift-register global is not

> any safer than a local (except you can use it in multiple VIs, so

> you might as well use a global if you're doing that).

 

And for that reason, a right click framework "easy set up" option is probably a bad idea -- anything we make easy to do encourages people to think its the right way to do it.  🙂

 

Nothing is ever going to be as easy to create as a variable. Unfortunately, variables are never going to be as safe as other tools.

 

This thread and tst's node shows once again that one of us (NI developer, tech writer, or enthusiastic user) needs to actually write up a central document we can all point to that covers local, global, functional and network share variables, and explains the race condition problem and the data copy problem. It would also mention the various safer ways of implementing data storage. We keep talking about that document, and the data is out there in various forms, but there's no central document that I know of that we can consistently link to when this topic comes up. Especially not a document that is easily digestible by novice users.