why use refnum

[scott-e]

I do not see a difference in using a refnum and property node versus a direct wire to subvi terminal. When should I use refnum vs a direct wired subvi?

see attached
thanks

[aartjan]

If your question is "why use refnums at all:"
the biggest difference will be that you can write and read properties of controls in a sub-vi. Very useful indeed. I myself make modules: I for instance have a speech module. All I have to do is connect a string refnum to this speech subvi and all of a sudden my computers speaks the string everytime it is changed.

aartjan

[aartjan]

I included a little example based on your example code

aartjan

[aartjan]

okay now then...

[scott-e]

I believe I attached the wrong file as my example - I re-attached here. I see how your app is working, but it appears directly connecting to the subvi terminals does the same thing as a refnum? I have both methods as examples in the zip file. If you can show me the benefits of a reference over a direct terminal connection, that would be helpfull. See attached - thanks

[shoneill]

Wiring a sub-vi means you have to explicitly call the sub-vi from the parent VI every time you want to give it a value.

Using a refnum, you can let the sub-vi run in the background and it can get the values itself. This way the sub-vi timing is no longer tied to the main vi timing.

The advantage is that the value-passing between main VI and sub-vi becomes asynchronous.

Apart from this, I do believe that using refnums force the code to run in the UI thread (anyone care to correct me?). This may or may not have implications on the execution speed of your application.

Hope this helps

Shane.

[scott-e]

Ok, I think in small amount of programming I've done, it is the difference of pass by value or pass by reference (pointer). I attaced an example update for anyone who needs an understanding - thanks

[rolfk]

shoneill wrote:

> Apart from this, I do believe that using refnums force the code to run in
> the UI thread (anyone care to correct me?).

Correct!

> This may or may not have implications on the execution speed of your application.

It always has and definitely in a bad way! Besides of forcing the
diagram code of your subVI to go into the UI thread (and maybe waiting
on other parts in LabVIEW using that thread at the moment) it also has
another performance problem. While updating a control terminal (or even
local) will pass the actual data to the control buffer and immediately
continue, letting the control at some time in the future be updated from
the actual buffer element by the front panel redrawing routine, updating
a property node value will ALWAYS go to the control and actually draw
the new data before returning.

This last point has no big implications if you update the control only
once every second. But if you pass a certain limit such as 50 updates
per second, or the control is very complex to redraw, the property node
value update will actually limit the speed of your subVI.

For terminal or local updates, the UI thread may miss some of the values
sometimes by not redrawing each and every one, but I want to see the guy
who can distinguish 50 updated values per second on the screen.

Rolf Kalbermatter

[scott-e]

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?

[shoneill]

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?