local variable vs property node->value

[Neil.Pate]

OK, so that pretty much confirms what I thought, its always better to wire directly to the control if you can. Now I know that in cases where you can't you should use a local variable rather than value property node, unless you already using the property node to update something else on the control.

In the past I used the value property node as you can wire the error cluster through it and preserve some dataflow, a local variable does not offer this, maybe for good reason? I always thought it was strange that the default property when you create a node  is "visible", had NI wanted us to use the value property to read and write I would have thought this (value) would have been the default. Its *really* easy to make a very silly mistake of not changing the "visible" property to "value" when using a boolean control. As they (value and visible) are both green its quite hard to spot later, unless you are looking for it!

To everyone, thanks for all your comments.

cheers
Neil

[tst]

---

@nrp wrote:
Its *really* easy to make a very silly mistake of not changing the "visible" property to "value" when using a boolean control. As they (value and visible) are both green its quite hard to spot later, unless you are looking for it!

---

They're only both green if your control is a boolean (which is green).

Incidentally, I don't think the locals don't have error handling "for a reason", but simply because it's not required - you can't have an error there, and apparently no one thought about (or it was decided against) adding error handling to locals to perserve dataflow. I believe the new shared variable (which is like a "universal" variable) does have error handling.

[Gurdas]

Hi all,

Interesting thread ... with some revelations - the fact that the FP will be loaded each time I update a value property never occured to me. Another proof that NI needs to start including such information in its help pages 😉

Though the discussion points to Locals being better, I avoid them as much as possible

Questions:

1) Can we 'flush' the local variable copies that NI makes? Then we could have the best of both worlds.

2) Is there a method to avoid the FP getting loaded when using property nodes? What happens if my control/indicator is 'hidden'?

3) What are Explicit Property Node and Implicit Property Node? And how do I identify and set them?

4) I too have faced anomalous behaviour when using value property. The value would not get updated even though placing a probe showed the desired value was being passed to the indicator. My property node was within a fast running loop. I finally had to remove it altogether. Any ideas what could be causing this?

Wishing the NI community a year full of Eureka! moments.

- Gurdas

[WNM]

---

@Gurdas wrote:

Interesting thread ... with some revelations - the fact that the FP will be loaded each time I update a value property never occured to me.

---

Actually I have used this fact to my advantage when I have been programming an application that was eventually destined to be made into a standalone executable. I had a number of subVIs whose front panels were dynamically displayed by yet another VI responsible for front-panel display management and the application builder didn't always guess right about which subVIs needed to retain their front panels. It was much easier to include at least one (read) value property for some front panel control/indicator somewhere in each of the VIs which needed to have their front panels retained in the built application than it was to try to maintain the correct list within the application builder setup file. Just the presence of the value property node anywhere in the VI was enough to ensure that the app builder always automatically included the front panel in the build.

[mitulatbati]

Hi,

I have made a short test with 1.000.000 times increment a value. Maybe it is not fair, but I wanted to compete CVI... Here the results and the codes:

1. LabWindows/CVI: 5ms

2. LabVIEW local variable: 245ms

3. LabVIEW property node via static reference: 33053ms

4. LabVIEW property node: 33185ms

mitulatbati

[mitulatbati]

I have to apologize, because I have compared two different things... Of course, if I don´t read the control value each time in LabVIEW, then makes it LabVIEW as well in 6ms... Reading of control value in CVI with GetCtrlVal() is very slow...

This means, if you need performance in your code, try not to access front panel controls, just use variables.  

[Ben]

1) make your loop count a control and move it before the seq structure. Making it a control rather than a constant prevents LV from "folding" the structure into a constant. Note there is an option to "show Constant" and Show Structure folding.

2) Move your control write to beyond the end of the seq structure so you are not timing how long it take to update the indicator.

Ben

[Mark_Yedinak]

I realize that this is a very old thread and I am sure the OP is no longer concerned with this issue but I wanted to point something out for any reading this thread now. One other option that was not mentioned, which may not necessarily be the fastest option but will produce a clean delineation between the processing tasks and the UI task would be to update all controls/indicators in a single task and use a queue for other portions of the code to pass the the updates to the UI task. What this does isto provide a clear distinction between the UI processing and the application processing. By doing so it is possible to increase your code reuse as well as provide a means to easily adapt the system for new user interfaces requirements without impacting the data processing tasks.

[Erik.Brenncke]

Hello again,

I wanted to thank all of you that posted these interesting locals vs. prop node tests!

I'm fairly new to complex applications and not familiar with the concept Mark Yedinak described in the last post. Are there examples to learn from? Because that sounds like I'm going to love it.

Erik Brenncke

[Norbert_B]

mitulatbati,

thanks for sharing your investigations. I want to point out several things here:

1. You already made a follow up stating that the test you made in the first post do not really compare to the CVI code. And a comparable code in LabVIEW really gets about the same performance as CVI does.

2. When working with property nodes, you stick to the UI thread. So if you minimize the frontpanel during execution, you will get some increase in performance (should be about 10-15%)

3. Encapsulation of the repeated access of property nodes into a section of "Deferred Panel Updates" will increase performance again for about 50%. Nevertheless, it will still not compare to variables....

hope this helps,

Norbert