Front Panel decorations affect loop execution

[pmac]

Here's a real head scratcher.

I've been trying to get a while loop to execute at a specific and constant rate (100 loops/sec). Inside the loop there is a subvi that reads an analog input and then does some calculations. To see the actual execution rate, I toggle a digital output channel once per loop and connected the output to an oscilloscope probe. This displays a square wave that toggles anywhere from 60 to 80 times per second (not 100 and not constant). I was able to get close to the desired rate when I replaced the while loop with a timed loop with dt = 10 msec but it still varied quite a bit. I eventually discovered that when I removed a couple of recessed frames from the front panel the toggle rate displayed on the oscilloscope was rock  solid at 100. When I replaced the recessed frames the rate drifted all over the place. Of course, I deleted and replaced the frames several times with the same results.

How can front panel decorations to have this affect on block diagram execution. Has anyone else seen similar behavior?

I'm running labview 2011 sp1 on a pxi-8105 embedded controller.

[SteveChandler]

You would think that because decorations don't do anything they would have no effect. But the OS does have to periodically redraw the window. A complex display might be causing this.

Try with the decoration but minimize the window and/or placing another window over it and see what happens. Also try without the frames but move the window around while looking at the scope.

You might want to get out of the UI thread altogether. Put your loop in a subVI and make sure the front panel is not loaded. That means no modifying any controls/indicators of the subVI with property nodes.

[pmac]

You are correct.

Minimizing the front panel does allow stable loop execution. I also have two waveform charts on the fp and if they are hidden I get stable loop execution. It's surprising how much the OS is compromised by updating the display.  

I have to execute in the UI thread because the fp display (with charts) is important to the application. Fortunately, recessed frames are not important to the application and I can get the loop rate I want by eliminating them.

Thanks for your reply.

[Ben]

updating a chart using the TERMINAL (not property nodes) does not involve the UI thread.

Ben

[Mark_Yedinak]

---

@pmac wrote:

You are correct.

Minimizing the front panel does allow stable loop execution. I also have two waveform charts on the fp and if they are hidden I get stable loop execution. It's surprising how much the OS is compromised by updating the display.  

I have to execute in the UI thread because the fp display (with charts) is important to the application. Fortunately, recessed frames are not important to the application and I can get the loop rate I want by eliminating them.

Thanks for your reply.

---

No, you do not have to run in the UI thread. Separate out your processing from the UI. Use user events, a queue or a notifier to pass the data from the processing task (which is running in a different thread) to the UI which will update the display. By doing so you will get more predictable performance from your processing task since UI updates will not affect it.

[SteveChandler]

---

@pmac wrote:

You are correct.

Minimizing the front panel does allow stable loop execution. I also have two waveform charts on the fp and if they are hidden I get stable loop execution. It's surprising how much the OS is compromised by updating the display.  

I have to execute in the UI thread because the fp display (with charts) is important to the application. Fortunately, recessed frames are not important to the application and I can get the loop rate I want by eliminating them.

Thanks for your reply.

---

The OS is not really compromised. The problem is that you only get one very busy UI thread in which lot's of things need to happen. The things you put in the UI thread should only be things that are user visible. Our brains are so slow at processing changes in visual input that a few tens of milliseconds go unnoticed.

As was pointed out you don't really have to use the UI thread for any processing. I am writing a very large application in which the top-level VI does not have any controls or indicators whatsoever. It is made up of several modules that communicate with eachother through the top-level VI using queues. The user interface is one of these modules. My UI just sends events to the top-level VI and the top-level VI updates the GUI by enqueuing messages back.