Graphical interface slowing down Labview execution?

[metallifredd]

hi
I have buildt a graphical interface with indicators and plots that I put within a whileloop.
I then placed a subVI outside the loopbut in the same VI containing my Labview program that performs a series of measurements and outputs the result to the indicators inside the while loop. This executes really sloww compared to when I execute only the SubVI with my measurements without the graphical interface.
Is the while loop that contains my graphical interface slowing down my execution or is it something else??

Please help me to learn.

Regards Fredrik.

[tst]

The first thing to check is whether your loop has a wait function inside. If it doesn't, it will eat up CPU time almost regardless of what you put in it.
It's possible that graphic elements will cause the CPU usage to go up even when you have a wait, especially if you have overlapping elements which cause redraws all the time, so if you have overlapping elements try to move them. You can also minimize the front panel, which should cause the display not to update. If the problem still exists than this is probably not caused by display issues.
Another possibility is that you're using property nodes in the subVI, which cause it to run in the UI thread, thus slowing it down.
If this didn't help you, I suggest you post the relevant piece of code, or at least an image of it (no BMPs, please).

[metallifredd]

Thanks !

I put a delay indside the loop and now it runs much faster.

Thanks again

/Fredrik

[Ray.R]

This is interesting.

A delay ends up speeding up a loop.

😄

[Ben]

"
This is interesting.

A delay ends up speeding up a loop.

"

and it makes sense.

If the update of the display takes a fixed amount of time and the code attempts to update more frequently than the update can complete, you end up running behind.

Analogy:
If it takes me 1 hour to fill out my expenses regardless of the period of time covered by that report, then I will only have to spend 1 hour a month on expense reporting if I only turn the report in once a month vs 4 hours if I turn it in once a week.

So its an old story. How much time do you waste updating reports vs actually doing the work.

Remember that in LV "reports" (screen updates) are only processed 30 times a second and submitting updates more often than that is a waste of time.

Ben

[Ray.R]

"Remember that in LV "reports" (screen updates) are only processed 30 times a second and submitting updates more often than that is a waste of time."

Oh... this is a cruicial piece of information...

Ben!!

You ARE a wealth of information...
... and so is tst!!

I never considered the screen update.

I shall pay more attention to it in the future. Thanks!!

I did notice a performance improvement by placing a 10ms delay in some loops. I never questionned why..


Thanks!!

[tst]

To interpret the original sentence:
"I put a delay indside the loop and now it runs much faster"
It - not the loop, but the rest of the program.

This doesn't actually have to do with screen updates, but applies to any code you run - if you don't tell it to rest, it will eat up all your CPU time.

[Ray.R]

Yes...

It's a given in C/C++/CVI..

I .... hummm.... (trying not to use the word "assume") ...

I thought that LV took care of the "other" resources...
I stand corrected..

😄

[Ben]

While we are standing corrected, let me correct myself when I said LV only updates the screen at 30 Hz.

The actual screen refresh rate is dependent on the video adapter subsystem but that is 75 Hz at the top end (as far as I know).

You can update the "display" faster, but that is updates of the image buffer and not the screen. The screen just has to run fast enough to fool the human eye into thinking the mouse is responding to your direction. That is part of the root issue with trying to get Windows to do anything "reliably" at rate of that order and above.

My point was that any update beyond the 30 Hz required to fool the eye is (Hmmmmm.....) bordering on the extreme.

Generally push for 10 Hz argueing that it is easier to see numbers and patterns if they are not changing to fast.

SO I stand with you JLV as corrected.

Ben

PS ditto tst