CPU usage, multithreaded program, initially 100o0before a write to file

[OMLC Clinic Team]

We are acquiring, charting, and storing (to file) data from a DAQ using a multi-threaded application. We have noticed that CPU usage is 100% before the user interacts with the program by either resizing/moving the window or by pressing a button on our front panel that writes data to a file (and asks for the file to write to).

Our application is based on while-loops, but we have the "Wait until next millisecond multiple" thrown in to hopefully stop it from using 100% of the CPU processor. We have noticed that before resizing the window, the output of the timer (from the next millisecond multiple block) is based on the current time of the CPU clock. After the user interaction, however, the
increments become even multiples of 100 (e.g. before 113, 213, 313...
after 500, 600, 700, ...)
After interaction the CPU usage drops down to about ~10% and the program appears to function normally (no crashing, etc.)

We really want the application to run with minimal CPU usage and without the user having to write to file beforehand. Does anyone have any ideas on why we are seeing this behavior or how to avoid it?

[Filipe A.]

Hello Guys;

The issue there is probably related to the way the Data Acquisition task is set up. You are probably using synchronous acquisition, which will keep the execution pointer of the code in the Read loop until the data is ready to be read.

The way to go about that is to set up a asynchronous DAQ task, so the CPU will be free to execute other tasks while the data is not ready to be retrieved from the buffer. There are some examples in Labview that shows that method of programming. You can find those examples at Search Examples->I/O Interfaces->Data Acquisition->Analog Input->DAQ Occurrences.

Hope this helps.
Filipe A.
Applications Engineer
National Instruments

[Filipe A.]

Hello;

That is probably happening because you have setup a synchronous DAQ task, and when that is the case, the CPU execution pointer get stuck inside the Read Loop, till data is ready to be retrived from the buffer.

The way to go about that is to setup a asynchronous DAQ task, that allows the CPU to handle some other tasks while the data is not ready to be retrived from the buffer.

You can find examples about that at Search Examples->I/O Interfaces->Data Acquisition->Analog Input-> DAQ Occurrences.

Hope this helps.
Filipe A.
Applications Engineer
National Instruments