Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Time to complete DAQmx tasks inconsistencies

Timing to complete a simple DO write seems to vary every now and then.

 

I have a Producer-Consumer based Test Sequencer (built into *.exe). I monitored all of the delays of completing tasks and I noticed something odd with DOs in particular. I extracted 991 DO Write tasks (all using the same code to command the 6225 card) over 23 tests. All the states (get step to end step) around the DO commands take 0 to 1ms time to complete.

71 DO steps took 1ms

15412 DO steps took 2ms

7109 DO steps took 3ms

187 DO steps took 4ms

3 DO steps took 5ms

3 DO steps took 6ms

1 DO steps took 7ms

1 DO steps took 17ms

1 DO steps took 26ms

1 DO steps took 27ms

1 DO steps took 30ms

1 DO steps took 36ms

1 DO steps took 284ms

1 DO steps took 295ms

 

I'm running a PXI system with Windows 7 (not Real-Time) and the DO card is a PXI-6225.

 

I can understand some steps taking up to 4 ms on a Windows OS, but its harder to understand why some would take much longer. 15 of 22793 took longer than 5ms.

 

Attached is the Matrix of all the timings for DOs.

 

DO calls always have Open and Close tasks. Auto Start is defaulted at False. Timeout is default.

DO Write.png

 

Otherwise:

All AIs (6723) are 15 or 16ms and AOs (6723) are 2 to 4ms.

FPGA (7853) did take a lot of time to process:

Sinewave generation commands took 231 to 239ms.

DO signals took either 31-40 or 100-300ms

 

Thanks

0 Kudos
Message 1 of 4
(2,257 Views)

Space for extra info if needed.

0 Kudos
Message 2 of 4
(2,250 Views)

FWIW, the main thing I find surprising in that distribution of times is that they are both faster and more consistent than I would have predicted.

 

Considering that you're creating and clearing the task for each of these DO steps, I'd have expected many more msec of overhead.  I'd also expect a more than just 7 out of over 22000 to exceed 10 msec.  Those 2 that approach 300 msec would trouble me, but it wouldn't shock me that they exist.  I'd put a little effort into trying to prevent those, but without certainty of success.

 

In short this seems, at a glance, to be a fairly typical case of Windows timing variation.  I've seen worse.

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 3 of 4
(2,228 Views)

Foreshadow20, I agree with Kevin_Price. Because you are not using LabVIEW Real-Time, you are at the mercy of Windows when it comes to reserving processor time. It is unlikely that any modifications to code will change the amount of jitter associated with this. If your program architecture could somehow allow you to create and clear the task outside of the DO step, this may help, as the bulk of the processing time may be going to creating and clearing the task. Other than this modification, the jitter you see is most likely to be expected.

0 Kudos
Message 4 of 4
(2,207 Views)