How can I improve the response time of the user interface?

[MIG]

I'm after some tips on how to improve the response time to mouse clicks on a VI front panel.
I have  data acquistion application which used to run fine, but after spending a couple of weeks making a whole bunch of changes to it I find that the user interface has become a bit sluggish.
My main GUI VI has a while loop running 16 times a second, updating some waveform charts and polling about a dozen buttons on the front panel.
There is sometimes a delay (variable, but up to 2 seconds sometimes) from when I click on a button to when it becomes depressed. I have wired the iteration terminal of the while loop to an indicator on the front panel and can see that the while loop is ticking over during the delayed response to the mouse click, so I know that the problem is not that the whole program is running slow, just the response to mouse clicks.
Also, just for debugging purposes, I have indicators of the iterations of all the main while loops in my program on the front panel, so I can see that there are no loops running abnormally fast either.

One thing I've tried is to turn off multi-threading, and this does seem to work - the response to mouse clicks is much faster. However, it has the side effect of making the main GUI while loop run less evenly. I was trying to get a fairly smooth waveform scrolling across the screen, and when multi-threading is off it gets a bit jerky.

Any other suggestion welcome..
(I am using LabVIEW 7.1, Windows 2000).

Regards,
Mark.

[altenbach]

Form your descriptions it is not clear what is wrong, and a 2 second mouse delay definitely IS wrong. 😮

• What kind of data acquisition takes place (DAQ borad, GPIB, serial, etc...).
• You talk about multiple while loops. how many while loops do you actually have?
• You talk about charts. How much data do they contain? What is the history length?
• Is your code peppered with value property nodes and/or local variables?
• Have you done any profiling?

Would you mind attaching some of your code, or at least a picture of the diagram?

[altenbach]

Oh..., some other things....

• Are you building arrays in uninitialized shift registers or local variables? What is the memory usage over time?
• How is the CPU usage?
• What is the execution priority of our VI? (See: VI properties...execution). Make sure it is set to normal! If you would set the priority to time critical, user interface actions such as mouse actions are starved and you would observe symptoms similar to what you are seeing.

[MIG]

Hi Altenbach,

Thanks for your reply. In answer to your questions:

• I am doing both DAQ board and serial data acquisition. I am using NIDAQ traditional for the DAQ board, and VISA for the serial. I have other similar versions of this program that do only DAQ board, or only serial, and these work fine. It was only when I combined them both into the same program that I ran into problems.
• The multiple while loops are actually in separate VIs. I have one VI that acquires data from the DAQ card, another VI that acquires data from the serial port, another VI that processes the data and saves to file, and another VI, the GUI VI, that displays the data in graphs and charts.  The data is transferred betwen the VIs via LV2 globals.
• The GUI VI is a bit more complicated than I first mentioned. It has tab control, with 4 waveform charts on one page, 4 waveform graphs on another page, and 3 waveform graphs on another page. The charts have a history length of 2560, and 16 data points are added 16 times a second. The wavefom graphs are only updated once per minute.
• I don't use the value property at all, but I do use lots of property nodes for changing the properties of the graphs and charts e.g. changing plot colours, Y scale range etc. There is only one local variable (for the Tab control). All the graphs and charts have data wired directly to their terminals.
• I haven't done any profiling yet.
• I am building arrays in uninitialised shift registers, but this is all well under control. As the experiement goes on, more data is collected and stored, and so the memory usage does gradually increase, but only to the extent that I would expect.
• The CPU usage is 100%, but I thought this was always the case when using NIDAQ  with DAQ cards. Or am I wrong about this? (As a side note, I am using NIDAQ traditional, but would NIDAQmx be better?)
  
• Execution priority of the GUI vi (and all the other VIs for that matter) is set to normal.

The program is a bit large to post here, and I'm not sure if my company would be happy for me to publicise it anyway, so I suspect that this is turning into one of those questions that are going to be impossible to answer.

Just as a more general question, why would turning off multi-threading improve the user interface response?

Thanks,

Mark.

[EdDickens]

Let's see,

You state that sometimes there is a delay. Does this mean that sometimes there isn't a delay? And that the delay length varies?

Does the delay only show up after the application has been running a while or can it show up right away?

Since your loops don't seem to be stopping, it almost seems like it might be something other than your application interfering with the button clicks. Try running the application with the Task Manager open so you can see what processes are taking CPU time. When the delay happens, which tasks are taking CPU cycles. (click on the CPU column to sort the tasks by CPU usage) LabVIEW may still be using the most, but something else might be taking just enough to block the UI. It's worth looking at least.

DAQmx probably would help. It is a much more efficient driver and is a lot better at releasing the CPU for other tasks. Most of my applications that run a continuous acquisition only use about 10% of the CPU.

Ed

[MIG]

Hi Ed,

Yes there is sometimes a delay, and sometimes not. And the delay length varies. The longest is approx 2 seconds, but it is not usually that long.
The delay shows up straight away as soon as I start the application.

I did as you suggested with the Task Manager, clicked on the CPU column, and my application is the second in the list. The first in the list is "System Idle Process". Whatever that is.

I think I am making some progress though. I replaced the VIs that do the serial communication and DAQcard acquisition with dummy VIs that just generate some fake data at the same rate that the real devices do.
When running the program this way the user interface is fast and snappy.

I put back the serial VIs and the user interface is still fast and snappy.
I put back the DAQcard acquisition VIs as well, and the user interface becomes less responsive again.

So it looks like it might be something to do with the DAQcard acquisition. When running with the genuine serial VIs, and the dummy DAQcard VIs, the CPU usage is about 25%. (it's a fairly slow computer, 800Mz PIII).

On Monday I'll try switching over to NIDAQmx and see how that goes.

Thanks,
Mark.

[MIG]

OK, I think the problem is solved.
Using NIDAQmx got rid of all the user interface delays.

I also tried using NIDAQ traditional with DAQ occurrences. This also worked, presumably because it stopped AI Read from hogging all the CPU time.

It was all a little bit of a wild goose chase though. The computer I was running the program on had a touch screen. I just assumed that the touchscreen would work exactly like a mouse, but when I actually plugged a mouse in, I found that the original program worked fine. It was only when using the touchscreen that I had the problem.

Anyway, it wasn't a completely wasted exercise. I now have a program that I can use with either NIDAQmx or NIDAQ traditional, and with either a mouse or a touchscreen.

Mark.