Command Latency with NI USB-9263

[gilmaor1]

Hello All,

I am timing the following block, using C#.Net

1) writer.WriteSingleSample(true, 0);

2) writer.WriteSingleSample(true, 1);

3) analogOutTask.WaitUntilDone(10000);

4) writer.WriteSingleSample(true, 0);

5) writer.WriteSingleSample(true, 1);

6) writer.WriteSingleSample(true, 0);

Is it correct to say, that because I am using "analogOutTask.WaitUntilDone(10000)" in-between, then the time between the two 1's also includes the latency?

That is, in line 2) the computer tells the DAQ to output 1, then there is latency until 1 is really outputted, than in line 3) the code waits for completion of the previous measurements, so by the time the lines 4)-6) are sent the previous lines were already outputted by the DAQ. I am seeing on an oscilloscope 3 msec separation before the first 1 and the 2nd one, would that mean that latency is < 3 msec? Will this also be the latency when I write multiple samples using "writer.WriteMultiSample(true, analogDataOut)"?

[rolfk · Accepted solution]

Most likely not! You use single point updates and those are synchronous. That means the function only returns after the value has been send off and the device acknowledged its receiving and processing. It may not be visible at the port in theory yet, but as far as the software driver is concerned that update is done and the task status consequently is done too. All that wait you use does is using some CPU to query the task status but it has no effect otherwise.

This function is for timed and buffered tasks that you setup to acquire or generate a waveform or digital pattern with a finite or infinite number of samples. The isDone status returns then false after starting that task until the requested amount of samples have been acquired/generated or the task was stopped due to an error or calling the Stop function for it.

Measuring latency as you seem to want is pretty useless. It can at best give you an indication of what the average latency is. You are running on Windows which is not a real time system. Windows reserves the right to take a guru meditation at any time it feels like to lock the system and reconfigure the device driver stack for instance. That can last from anywhere between ms to multiple seconds. In this time nothing else happens and your latency timing gets hosed up. That latency anyhow never will be very accurate since the non-realtime characteristic of Windows simply can’t offer that and the USB bus is also a shared resource where multiple devices compete for it (multiple USB connectors in your computer are usually connected to the same hub).

If you want a specific timing for your analogOut() you should use timed and buffered waveform generation. Anything else works fine for slow updates but in terms of timings is only as accurate as your software can execute the code (when Windows decides that it will let it execute)!

[gilmaor1]

Thanks!

That solves the issue.