Very slow update using property nodes

[Steiger]

I have a VI with a large number of controls and indicators spread across a few different tabs of a tab control. On the Main tab, I occasionally update or reset about 28 of the indicators to show test results. I'm using property nodes for the updates so that I can also change the indicator display to green/red depending on whether the result is a pass or fail.

This is similar to what I've done previously on other projects with no issues. Now, with the current project, the indicators take an unacceptably long time to update - on the order of 1.5 to 2 seconds, and sometimes more. This slow update occurs whether I have the Main tab with the updating indicators selected, or whether I have another tab selected. If I scroll down so that the Main tab and most of the indicators (some are 'spare' items that may or may not be used in future) are off the screen, LabVIEW processes the updates much more quickly.

As a test, I created a VI with just the 28 indicators and updated/reset them via property nodes. That test VI ran with no issues.

I've tried some of the suggestions from other threads (deferring front panel updates, creating subVIs that run in the UI thread) with no success.

I've attached a different test VI (LabVIEW 7.1) which demonstrates the issue. The test VI has two separate state machines (similar to the actual program), which cycle through a Set/Reset procedure when the 'Next' button is pressed. The test VI contains all the controls/indicators/graphs etc that the actual VI uses, and sets/resets the selected Main tab indicators like the actual VI does.

Any assistance would be appreciated.

[altenbach]

Your code show a complete misunderstanding of dataflow. For example, the lower left big while loop has no purpose that I can see. Most code segments are so convoluted, it is difficult to tell what their purpose is.

There is no reason in the world to update a numeric via a "Numtext.text" property. Just use the "value" property and wire the random number directly to it. For good measure, you might want to defer panel updates during running of these small FOR loops.

I would also remove the timeout in the event loop and add a loop for the stop button instead. Overall, I would suggest to rethink the entire program. There simply has to be a better way. 😉

Message Edited by altenbach on 02-01-2008 06:19 PM

[Steiger]

Aaargh. I can't believe I missed the NumText.Text - you're absolutely correct that it makes no sense. I'll have to take a look back at the actual code to see what on earth possessed me to do it that way.

Your other comments are appreciated. This was just a test VI slapped together to try and isolate the problem. Its only similarity with the actual VI is that it includes all the controls and indicators, two state machines running in parallel, and the for loops for updating the front panel indicators. Beyond that it is just a horrible kludge involving a lot of hurried cutting and pasting. Thanks for taking the time to wade through it; in future I will try not to post such opaque slapdash constructions.

[RavensFan]

What is the function shown in the picture below?  I've never seen it before.  It would not show up in my context help window.  Two inputs of the iteration value and and Enum and outputs an Enum.

?????

Message Edited by Ravens Fan on 02-01-2008 11:12 PM

[altenbach]

Ravens, these constructs with the inner loops originate from the old state diagram toolkit if I remember right. So these are canned things from NI.

We discussed that special node in the past, 'don't remember the details. 😉

[RavensFan]

Thanks Christian,

That explains why I hadn't seen it before.  I haven't worked with that toolkit, and I'm pretty sure I don't have it installed.

Now I know.

[tst]

In case you're still wondering, that is called an external node, which is a node you can build yourself and which has code which runs at edit time to change it based on events (e.g. wiring something into it). These give some very powerful abilities, but they were an experiment and were replace with XNodes in 8.x, which perform the same function, but work differently.
You should note that XNodes are also still experimental and not officially released, but you can see one example in XControls, which are official and which have code that runs at edit time. If you want more details, you can look at the LAVA forums rusty nails forum.

[DFGray]

One last comment.  If you can use them, terminals are the best way to update front panel controls.  Barring that, use local variables next.  Both of these methods are asynchronous and feed into the normal update mechanism for the front panel.  If you use a "Value" property, the value is set synchronously and happens one to two orders of magnitude slower than the terminal or local variable.  However, you need to use "Value" if the update is encapsulated in a subVI.  As you know, this is a good time to defer front panel updates.