SetThreadPriority for WFM_Op and DAQ_Monitor

[edwardryklin]

I have a hard fast loop that looks for a new data point, retrieves it, then plays a sound. when it retrieves the data point, the function's return value

indicates if the data point is retrieved before an overwrite occurred. 

The sound function which executes after the data point is retrieved takes too long; holding up the entire loop. On the second iteration the DAQ_Monitor() is already too late, and data is lost.

Pseudo code:

while(1){

    success = DATANOTAVAILABLE;  // initializing 

    while (success == DATANOTAVAILABLE){ // looping until new data found (may enter loop only once)

        success = DAQ_Monitor()
    }

    if (success == OVERWRITE) {

         printf(" Data is not captured in time (lost) ");

    } else

         printf(" On time! ");
     }

     printf(" Generating a sound/analog output ")

     WFM_Op()                 <-- the problem is here, this function is too slow

     print(" Done, repeating loop ")

}

So far I have tried adding this before the while(1)

SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);

SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);

These lines don't make any difference. Frankly they don't appear to do anything at all.

How can I make this code execute faster?!

[Kyle_A.]

Hello,

There are two ways I can think of to possibly increase the efficiency of this code.  One would be to allocate memory space for your sound byte and call the array that is declared at the beginning of the program than doing it all in your loop.  If you can allocate the sound byte in memory before calling, you will speed up the time it takes to call the sound in your program.

Another way is to multi-thread, where you have one loop continue to acquire points, and another loop built just to call your sound when a point is received.  This may be a little more difficult to implement, but would follow more of a producer/consumer architecture. 

[edwardryklin]

Hi, I have certainly considered and implemented your suggestions already.

In my pseudocode, I do not allocate memory for sound or other data. I perform that memory allocation during a non critical time epoch, well outside the loop.

Multithreading these two processes - data acquisition and sound output, will indeed prevent samples from being lost in the first thread by the second, however, it will also introduce a temporal lag between the acquisition and the sound output events. Such a lag creates a fundamental problem in the goal of the program. An acquisition must be collected, analyzed and responded to within one sample period.

[Kyle_A.]

How fast are you intending to take samples?  How long is your sample period?  Are you using hardware-timed single point for your acquisition mode? This seems like the issue is all in how fast the sound can be output and not block the rest of the acquisition loop.  If there is a way to 'interrupt' the sound byte when another sample comes in so that the sound will always start when needed, but not finish, would that work?

[edwardryklin]

My sample period is 2ms. I believe the sound generation is initiated and then the WFM_Op() function returns control to the thread, while the sound is being generated by the board. That sound continues to loop autonomously until I deactivate it, which happens conditionally in the future.

[Kyle_A.]

It seems like the DAQ code is running fine, but the C code controlling the noise is still causing some issues.  Did you use hardware timed single point for your acquisition?  This is generally the best way to set up a DAQ to use data recovered for other events, and doesn't utilize a buffer. 

[edwardryklin]

These are the sequence of commands I use to setup my data acquisition

AI_Configure

Timeout_Config

SCAN_Setup

DAQ_DB_Config

SCAN_Start

DAQ_Monitor

AI_Configure

Timeout_Config

SCAN_SetupD

AQ_DB_Config

SCAN_Start

while()

DAQ_Monitor