Measurement speed increases when pull-down menu items are accessed.

[Dekay]

I've noticed that measurement speed increases substantially when one of the pull-down menu items are visible (e.g. File, Edit, View,...). The program is averaging several measurement arrays. Each array from the AI varies, but typical conditions are to collect 400 points, and average several hundred of the 400 point arrays together for noise reduction.

It normally takes about 65 seconds to measure and average 1500 of the 400 point arrays together. If a menu item is pulled down, it only takes 38 seconds for the same measurements and averaging.

The DAQ is a PCI-6251, in an HP PC using a 3500 AMD processor (single), 2G RAM. The sample period is 10 microseconds.

There is a lot of good information in 'Managing Performance and Memory in the Labview Help. However, I've tried a few of the recommendations, but none seem to make much difference. For example, display is already asynchronous, 'smooth updates' doesn't matter. The data acquisition is running as a subVI in a loop that averages and displays the graph with each measured array. Changing the subVI to a subroutine would require many changes to fix errors involving the subroutine using subVIs with asynch nodes.

Any ideas as to how the pull-down menu impacts program operation such that it would increase the speed?

Thanks 

[Ben]

Quoting myself from here

---

 

Shot in the dark...

Check Start >>> Control panels >>> System >>> Advanced >>> Performance >>> Settings >>> Advanced

Process scheduling = Background Services

See here if that changes things.

---

If that makes a difference please let us know. It is just TOO weird that this is the third time in the past week I have read a Q like this.

Ben

[RDR]

Are you using software or hardware timing for your acquisition?  What does the CPU usage look like when the code is executing (and does it change when you access a menu)?

Also, what version of LabVIEW is this?  I recall a bug in an older LabVIEW version where the menu items could block the UI thread, which might be speeding up execution in your case if this is software timed.

-Bob

[Dekay]

Bob, Ben -

The program is using hardware triggers, based on the NI synchronous AI AO example, in LabView 8.5.

Switching from 'background services' to 'programs' did not change the execution time.

With the present measurements (33usec sample period, 600 points, 500 array sets averaged), the CPU usage is 60-75% without the menu pulled down, and 55-65% with the menu pulled down.

[RDR]

I looked up the bug I was thinking of and it was for accessing the menu via the alt-key when the menu was not visible, CAR 99672.  This does not sound like the same situation, but I'm not saying it is not related...

Since the DAQ example code is hardware-timed, it is not likely a source of the drop in execution time as acquisition time should remain relatively consistent with a hardware timing source.  Are you performing calculations in the same while loop as the DAQmx read?  I recommend passing data to another loop for processing if you are not already...

If you have already separated your DAQ from averaging the data sets, do you see a difference in the execution time for the calculations when accessing the menus?  (you can use a simple method to benchmark the code as seen here)

If it turns out the execution speed does drop for the calculations when the menus are accessed, you might double-check this behavior with debugging disabled or in the executable form to see if this is due to the added overhead of the dev-environment (as opposed to the RTE).  Perhaps in EXE form the performance issue is negligible...  If this is related to the above bug, disabling FP updates before performing calculations and enabling after they are complete would likely reveal the same behavior...but this is not a workaround.

If concerned this is a performance issue with LabVIEW, and you're able to share this code with NI, I recommend calling in for support.

-Bob

Message Edited by B O B on 11-20-2009 04:03 PM