NI-DAQmx write raw takes up to 5ms (too slow)

[GoPSU]

I have a MSVC6 / NI-DAQmx PCI-6733 ansi-C based system that responds to a digital trigger with analog output (among other things). I have my 6733 setup to start AO on a digital edge trigger. It is working fine, but the C call DAQmxWriteRaw(taskAnalogOut, SAMPS_PER_CHAN, true, 0.0, (void *)writeArray, &sampsPerChanWritten, NULL); takes between 3ms and 7 ms to return. This is way too long for my application. I have tried loading fewer samples and not error checking etc. but it always takes way more than 1ms. I'm using a dual processor xeon 2.4 Ghz w/ 2 Gbytes ram running XP. I've tried changing the priority of my .exe file but that didn't speed it up.

Is there a way to change the priority of the NI-DAQmx drivers? 5ms @ 2.4Ghz is 12,000,000 clock cycles per CPU. Is there any way to speed this operation up?

Cale F. Brownstead
cfb102@psu.edu
814-863-5379

P.S.
Here is a code snippet of the AO channel setup

#define VPP 20.0
#define FS 200000
#define SAMPS_PER_CHAN 2000
#define NUM_CHAN 6
checkError( DAQmxCreateTask ("AO_6ch", &taskAnalogOut), 2000);
checkError( DAQmxCreateAOVoltageChan (taskAnalogOut, "/pci6733/ao0:5", "ANALOG_0_5_OUT", -VPP/2, VPP/2, DAQmx_Val_Volts , NULL),2010);
checkError( DAQmxCfgSampClkTiming (taskAnalogOut, NULL, FS, DAQmx_Val_Rising, DAQmx_Val_FiniteSamps, SAMPS_PER_CHAN),2020);
checkError( DAQmxCfgDigEdgeStartTrig (taskAnalogOut, "/pci6733/PFI6", DAQmx_Val_Falling),2030);

[GoPSU]

An update.

I fiddled around with the priority of the NI processes and now it takes 17-30ms for the DAQ_Write! I screwed something up and can't seem to undo it.

Cale

[e-Cash-Money]

Hello Cale,

A couple of questions...

1) When you say that it is taking 3ms for the DAQmxWriteRaw to return, do you mean it is taking that long for the function to return the error code or there is a 3ms delay between the trigger and the first analog output sample?
2) How are you measuring this delay?
3) Are you calling DAQmxWriteRaw before or after DAQmxStartTask?
4) Can you test and verify this behavior on a different PC?

I do not know of a way to increase the priority of the DAQmx Driver itself because it is only a dll file, not an executable program.

E.Lee

[GoPSU]

I'm starting the output with a digital trigger:
(DAQmxCfgDigEdgeStartTrig(taskAnalogOut, "/pci6733/PFI6", DAQmx_Val_Falling)).
The task is auto started started before the trigger using:
(DAQmxWriteRaw(taskAnalogOut, SAMPS_PER_CHAN, true, 0.0, (void *)writeArray, &sampsPerChanWritten, NULL)), but the DACs don't output until the digital trigger happens.

The data output starts at the perfect time down to the microsecond (because of the digital trigger). Its the WriteRaw command that takes 3-30 ms. My situation is that I need to change the output data each time I get a "transmit/receive synch pulse" ( the digital trigger is the falling edge of T/R). This T/R pulse can be long or short. When its short, I have to load the buffer before it falls or I miss the T/R and the data never makes it out. Its the load buffer (WriteRaw) command that takes so long. The stop task command takes 0.15 ms.

I'm curious as to why it takes so long? I'm guessing its stuck inside the device driver. Maybe the board responds slowly to a new buffer setup or something?

Cale

[GoPSU]

I measure the external signal delay with an 200Msa/s oscilloscope.
I measure the internal delay of software by using the Intel Performance Primitives optimized c call -> ippCoreGetCpuClocks(), which returns a int64 clock count, which I subtract from previous and divide by ~2.391Ghz to get time. Two ippCoreGetCpuClocks() calls together take 88 clock cycles to return.

Cale

[sergesl]

Hello GoPSU,

Did you check if the time depends on the number of samples you are writting or the number of updates? Notice that the prototype of the function has an input that determines the number of samples and it returns the number of samples written. When the function returns, can you use the number of sample written and the update rate choosen to find out if the function delayed because it was writting the samples?
One good way to take care of this problem is to program in a multithreaded environment.

[GoPSU]

Hi,
Thanks for your response.
Before my time critical section of code I:
1.Setup my AO task
2.Setup the channels
3.Setup the timing (FS, continuous or
4.Setup the digital start trigger
This takes 64 ms

I have separated the time critical commands using NI-DAQmx into these three:
1. load buffer (manual start) (<0.34 ms)
2. start task (15-32 ms)
3. stop task (<0.38 ms)

These commands are inside a while loop that is continually running and checking digital to change states.

That start task is really hammering me. I need a solution or I won't be able to use this hardware.

[GoPSU]

Sorry,

The number of samples and buffer size don't change the delay in starting the task.

[sergesl]

Hello Cale,

This is probably happening because of the way you are calling your functions. I suggest you try one of our examples in C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Analog Out\Generate Voltage . Those examples will give you guidelines on what you need to do to program efficiently.

[arse]

Did you solve this? I am having a similar problem.  There are delays during the acquisition cycle that make the write response jitter between 1ms and 5ms (occasionally much longer).

The task is not being restarted.  I just call WriteMultiSample(bool, double[,]). 

Thanks.