why use refnum

[shoneill]

You can also use a global variable, but then your sub-vi needs to be written so that it updates the global variable from within the loop.

Which is more efficient? I don't know, I'll make clear for someone who can answer.....

Shane.

[rolfk]

---

@shoneill wrote:
You can also use a global variable, but then your sub-vi needs to be written so that it updates the global variable from within the loop.

Which is more efficient? I don't know, I'll make clear for someone who can answer.....

Shane.

---

Globals have another performance bottleneck especially when reading. In reading a global LabVIEW always must make a copy of the data which for large arrays is a huge performance hit.

Rolf Kalbermatter

[rolfk]

---

@scott-e wrote:
Correct me if I;m wrong but if you have a subvi routine encased in a while or sequence structure, you need to use a refnum in order to have the main vi show the changed value in realtime?

---

That is only really necessary if your subVI contains a loop itself and you want to make an update of a control in the main VI in each loop iteration.

For normal VIs you simply wire the value out of the subVI through the connector pane and wire it to the indicator terminal or a locale variable of it. No need for contorl refnums and the value property node on that control refnum.

For most applications the subVI with a loop updating a control in another VI through a control refnum is unnecessary and a bad design choice. Passing out a value from the subVI and updating it in the caller directly to the front panel controls is sometimes more labour (you need to bother about the connector pane) but it is almost always the better, faster and clearer (proper dataflow) solution.

Rolf Kalbermatter

[scott-e]

---

@shoneill wrote:
Hi Rolfk,

Thanks for confirming the UI thread thing.

The panel re-draw forcing is definitely an unwanted side-effect of using refnums. You actually mention property nodes, but I presume you either meant refnums of are including refnums in the same context.

Is it not possible to (given a refnum for a particular control) get the refnum of the parent panel, activate deferred updates, write the value, and then de-activate the deferred updates? For a single control this may have little or no impact, but when updating a series of controls or indicators, does this lead to a performance increase due to less screen re-drawing? When setting the values of the controls or indicators, I don't see any change in update speed whatsoever (The values are re-drawn regardless of the "defer update" setting), but when making something visible or not or changing other cosmetics, the defer panel updates can greatly speed up this action (here the "defer updates" seems to have the desired effect).

An example of 4 digital controls, 2 simple numerics and 2 temp ramps took 1 second to make visible and invisible 100 times without deferred updates, and 40 milliseconds with.

Setting the values of the controls was the same with or without deferring the updates.

So, I suppose it depends on what you want to do really.

I don't know if this helps, but hope springs eternal

Shane.
Ps I'm using LV 6.1, maybe things have changed since 6.1?

---

So it is only necessary to use reference when you have a sub vi performing a loop structure of some kind and you want data to be shown in realtime of the main vi. So when is it usefull to use a global variable over a subvi wired terminal to a main vi? I trying to see a flowchart of when it is best to use each method. thnx

[DFGray]

You would use a reference to update a front panel value any time you want to encapsulate functionality or you have to update a front panel variable from inside a subVI before the subVI returns (a loop is the most common example). As mentioned before, using a property node to update the value of a control is MUCH slower than directly wiring it. Using the defer panel updates property can help a lot, especially if you are updating a lot of variables, because LabVIEW will often update the entire front panel every time you change the value of one control (in LabVIEW, being safe takes precedence over being fast).

I would never use the global approach. In fact, I avoid globals like the plague. With the highly parallel nature of LabVIEW, there are too many ways you can shoot yourself in the foot. In 11 years of LabVIEW programming, including one 1200 VI, UI driven application, I have never had to resort to one. Use functional globals (also known as shift register globals or LabVIEW 2 globals) if your really need a global. You can write these to lock the data and avoid most problems. If you want more details on this, consult the attachment (ZIP of an NI Week presentation on large program design).