Use of multiple property nodes for GUI manipulation

[Broken_Arrow]

I have a LabVIEW 6.0.2 application where I'm using 14 different property nodes in the main loop. All of these have to do with GUI - hiding buttons when "X" isn't pressed, disabling and greying out controls if <0, popping one button on top of another depending on the mode of operation, etc, etc. While this works fine, the program is getting slow. I've noticed that using the old 2-D buttons works faster - things update faster and redraw quicker. However, more to the point, I once read that if you have to use a lot of Property Nodes like this, that you should bundle them into a sub-vi, thus replacing what would be Property Nodes with references. How does that make it faster?

[EdDickens]

Not sure if bundling them into a sub-vi by itself would make it faster. The nodes in the sub-vi would still have to access the user interface thread, and that's where the slow down comes from.

When I use any property node, I put it in a case structure and only write to it when needed. You just need to be able to detect when the value being written is changed from last loop iteration. It's useless to constantly rewrite the same value (doesn't have to be the "value" property) to the node.

Bundle them into a sub-vi and put the change detector, case structure and nodes in the sub-vi, this should help speed things up a bit. Assuming of course that the nodes are the slowdown. It may also help clean up the diagram a bit.

Ed

[Greg_McKaskle2]

> I have a LabVIEW 6.0.2 application where I'm using 14 different
> property nodes in the main loop. All of these have to do with GUI -
> hiding buttons when "X" isn't pressed, disabling and greying out
> controls if <0, popping one button on top of another depending on the
> mode of operation, etc, etc. While this works fine, the program is
> getting slow. I've noticed that using the old 2-D buttons works faster
> - things update faster and redraw quicker. However, more to the point,
> I once read that if you have to use a lot of Property Nodes like this,
> that you should bundle them into a sub-vi, thus replacing what would
> be Property Nodes with references. How does that make it faster?

My assumption is that your slowdown is coming from screen update
s. When
you change a property, it needs to update the screen, and this always
takes longer than people expect. And yes, the 3D controls can take
longer to draw than the 2D, especially if they have a blended edge or
shadow.

The other poster's suggestion to set the property only when changed will
help, but that is a very small cost compared to the cost of drawing.
Where you have a collection of properties showing, hiding, or moving
objects, surround these updates with a Panel>>Defere Updates property
set then clear. This will help a bit as the drawing will be more amortized.

As for the subVI question, it cleans up your diagram, and makes the
defer panel updates easier. It will shrink the size of the top level
VI, and can allow for reuse, but I wouldn't expect it to speed things up
simply by shoving the code into a subVI.

Greg McKaskle

[Broken_Arrow]

So true re: updating 3D controls with shadows - I had a button sized up quite a bit - the difference in updating this button and a 2D equivalent was easily apparent with the eye.
As far as the Panel>>Defer, I'm not quite sure how to do that, but I'll check it out.
I tried the sub-vi and it didn't help. And in fact, it just saves a little room because you still have all those references connected to it.
Thanks for all the help.

[waldemar.hersacher]

We made some testing how classic and 3D controls and panel defer update would influence each other.

I made a measurement frame and put some controls in it. The acompanying VIs will move 10 buttons around the screen. If you expand the front panel to the right you can see some timings. "Zeit ohne" means the time without using panel defer update and "Zeit mit" means using panel defer update.

We have found that moving, hidding and changing colour will give a lot of benefit from panel defer update but if you are setting the same attribute again it will make no difference.

Change frame 0 and 3 to get other things with attribute nodes which you want to measure also you can change the type of control without breaking the VI.

Waldemar

[Broken_Arrow]

Amazing difference in 2D and 3D. And thanks for the vi! I was having trouble with the defer updates. Now I know what the Open VI reference is for!
As far as all of my Property Nodes, I bundled them into cases and triggered the cases with the Boolean Trigger vi that is available at opneg.org. That little vi is awesome! Now my Property Nodes are written to only when the value of a button changes.

[Philip_B]

I am having the exact same issues as discussed above. I cannot however find the "panel >" section. Is it present on labview 5.0?
thanks
Phil

[Philip_Courtois]

Hi Philip,

The feature of deferring panel updates and the panel reference were not introduced until LabVIEW 6i.

If you want to upgrade, please visit "Upgrade Your NI Software".