What is the benefit of passing variables to Vi's instead of Refs?

[eximo]

When passing variables to vi's what is the benefit of doing so?

Why not pass all values to Vi's as references?  It uses less memory, is faster, and eliminates the need for local or global variables.

The reason I ask is that my test fixture structure has two separate control structures for controling the test fixure.  One is designed to test the analog portions of our device, the other is designed to test the digital portions.  A few of the controls overlap, and sometimes it is useful to run both analog and digital control systems.  Using references I can update any over lapping controls without passing the values to globals and back and forth between the two control VI's.

[Yann_50]

Refrences doesn't contains only the value bur also every properties concerning the indicator.

it can be usefull to use refence with their properties but it is longer for updating

see my benchmark vi linked.

Yann

[majoris]

Using references adds complexity to your application, both when coding and when debugging. Good programming practice stresses the importance of cohesion, namely how focused each module of your application is at doing what it is doing. When you write a SubVi that not only does some computation but also updates the front panel UI, you decrease the cohesion of your software. This makes reading the code and tracing bugs more difficult. For instance, if every function has the power to update the UI, tracking a bug where the UI is changed is made more difficult (since that bug could exist in any SubVi).

Additionally, it adds complexity because accessing the value of the variable is that much harder (requires a property node). This adds additional blocks to your block diagram that could otherwise be avoided. Using the property node also likely has some additional overhead as opposed to using a wire. As is often stressed on these forums: wires are the optimal way of passing around data in a Vi. So if performance is your goal, a wire is likely your solution.

That said, there are a whole bunch of reasons why you might pass around your front panel controls as a reference, and I have a feeling your application might be one of those examples. Indeed, you could be practicing good cohesion by doing exactly what you're doing, abstracting how you update your front panel using two different control schemes you can toggle between. Other examples might be memory constraints (you can't go passing around a 100MB data source to every Vi in your block diagram willy nilly).

So it very much depends on your application. The goal should always be to practice good programming techniques.

[SteveChandler]

References cause the front panel to be loaded into memory. Updating a value by reference causes a switch to the UI thread. It is a real performance hit. With that in mind it may or may not be appropriate to use references.

If by "passing variables to vis" you mean the wire then you understand a key concept of LabVIEW. If you are talking about those rectangle things that are used to access a control or indicator value then this is a very common and understandable misconception. Those things are really a function associated with a control. The wire is the variable.

[Ray.R]

---

@eximo wrote:

Why not pass all values to Vi's as references?  It uses less memory, is faster

---

Who told you that?

As was already mentionned, using references not only passes all properties for the value, but also requires a property node to handle it.  Which adds clutter to the code without additional benefits.

Only when you want to control something inside another VI while both VI's run (well...  the other does not need to run, but that's another story), then using references may not be an appropriate solution.

[eximo]

I swapped the variable out with a "value" property node, it matched the timing for the reference almost exactly, but swapping with a local variable......that used almost the same amount of time as if I had the indicator in the loop.......I had been led to believe references were like pointers so they would use less memory because there was no copying, hence less time would be taken up.  Now i'm trying to reconcile my fractured understanding of memory and timing in regards to references, property nodes, and local variables.   

[SteveChandler]

I am sure that writing a value property node is just as fast as using a local variable. But there is more that LabVIEW has to do other than just writing the value. The swap to the UI thread is what is killing performance.

[eximo]

UI =? User Interface?   What is the significance?  Why wouldn't a shared variable do that?  Why would a property node do that?  What is the benefit of switching to the UI thread?

[SteveChandler]

There is only one user interface thread. Swapping to it is time consuming. The reason for the swap is that controls are a user interface component so need that thread. There are property nodes that do not require the UI thread such as LVOOP accessors. (Someone correct that if I am wrong)

Switching to the UI thread is not a benefit but an expensive requirement of the value property node.

[nathand]

---

@eximo wrote:

I had been led to believe references were like pointers so they would use less memory because there was no copying, hence less time would be taken up.  Now i'm trying to reconcile my fractured understanding of memory and timing in regards to references, property nodes, and local variables.   

---

A reference is not like a pointer.  A reference is to an object on the front panel, NOT to a space in memory.  For someone accustomed to managing memory, this can  be a hard concept.  When you pass data on a wire into a subVI, you don't really know whether it's being passed by value or by reference, and even better, you don't have to worry about it.  If it's necessary to make a copy of the data (for example, because the subVI modifies the data and the unmodified values are used somewhere else later), then LabVIEW will make a copy.  If the compiler determines that no copy is necessary, then the subVI gets a reference to the original data.  There are tricks you can use to minimize data copies, but references are not one of them.