DAQmx+6009: Reading the current counter value is too slow

[280Z28]

I have a thread that runs a software loop that I need to run as fast as possible. One of the things I need to do is poll the current counter value from my 6009, and branch if it's changed from the last time I read it. Over 90% of the time spent in my 1.2ms loop is doing this read. My goal is to get the loop under 50us.

What I really need here is an accurate timestamp (20us or better) for every time the counter changes (up to 1kHz). When I detect a change, I currently get the timestamp by calling QueryPerformanceCounter().

Here's how I create the task:

    DAQmxErrChk( DAQmxCreateTask("",&taskHandle) );
    DAQmxErrChk( DAQmxCreateCICountEdgesChan( taskHandle, line, "", DAQmx_Val_Falling, 0, DAQmx_Val_CountUp ) );
    DAQmxErrChk( DAQmxStartTask(taskHandle) );

And here's the line of code that goes so slow in my loop:

    DAQmxErrChk( DAQmxReadCounterScalarU32( taskHandle, 10.0, &count, NULL ) );

[Jonathan_Brumley]

It is impossible to get the performance you are looking for with the 6009. 

The USB bus has very high latency compared with the PCI bus , and I typically see 

between 1 and 10 ms per operation.

If you need lower latency, I would recommend a PCI-family device.

With a PCI device on a somewhat up-to-date computer running Windows XP,

I have been able to perform a DAQmx read in about 20 us. 

If you need better than 20 us, then I would recommend LabVIEW and the LabVIEW

real-time OS.  With that OS you can perform a read in less than 10 us - and

depending on the type of read you may be able to get a snapshot in as fast as 3 to 5 us.

Hope this helps.

[Jonathan_Brumley]

Some more information on USB issue:

Theoretical minimum latency = 125us for USB 2.0 versus 1ms for USB 1.1.

Here is an EDN article that states the bandwidth and latency capabilities of USB 2.0 versus 1.1.

(It also has information on PCI and PCI Express).

http://www.edn.com/article/CA6258599.html?ref=nbra

[280Z28]

Interesting. I wonder if I can get my money back on these (6008, 6009, 6501). 😞 I don't have PCI on my laptop - I'll have to build something I guess. All the advertised stuff about these devices was exactly what I was after. Oh well.

[280Z28]

Will the NI PCIe-6259 do what I need?

[GDE]

I understand that you are trying to do some counter operations, and everything thing that you wanted to do with the 6009 you can do with the PCIe-6259. Now as for the latency, as Jonathan mentioned you will probably be able to get what you need from the PCIe bus. But of course there is always OS concerns as he mentioned, so if you absolutely need sub 20 us capability then you should look into LabVIEW RealTime. So ultimately yes, you should be fine with the PCIe-6259.

-GDE

[Jonathan_Brumley]

I would like to add that we have benchmarked Counter Reads here at NI and been able to get faster than 20us using the PCIe-6259.  The exact timing you will get is system dependent.  Of course, if you use Windows and not a real-time OS, there is jitter from any number of sources.  As one of many examples, what if the virus scanner all of a sudden decides to run in the middle of your application?  So I would recommend designing your application in such a way that it can tolerate occasional delays.

If you get the 6259, you may want to try the change detection feature, which could have some advantages depending on what you want to do.  Change detection allows you to clock an input or output sample whenever a change is detected on one or more digital lines, and since it is implemented in hardware, it is not affected by OS jitter.

[280Z28]

I don't expect many interruptions. I run a dedicated thread for this loop, with priority set to highest and the processor affinity set to one of the cores (dual core system).

My critical timing is as follows:

A shaft angle is measured via a hall effect sensor on a 60-2 (missing tooth) wheel. I need to time events to occur when the wheel reaches specific angles. Change detection would be perfect if these angles fell on one of the wheel's teeth. However, they don't necessarily, and I have to do a time interpolation for the exact point to output a bit. 20us gives me 1 degree of accuracy at 8000rpm, which is acceptable for my application (car engine).

[ichthus]

I updated a robot control from a Mac Powerbook with a PCI expansion chasis running Mac OS9, Labview 5 and DAQ to a Mac Mini (intell) with 6009 and 6501 USB cards  running Mac OSX, Labview 8.5, and DAQmx-base.  I have connected wheel encoders (pule train and direction) to a 6009 and a 6501.  It all seems to work, except the tuning of velocity control loops is not as good as before, indicating some delays.  The loops run every 100msec (10Hz update) so I expected a synchronisation problem rather than latency.  I did some measurements today and found that reading the 2 counters and the 2 digital inputs takes over 20msec.

 I get better performance from VISA with a serial to USB converter.  I have a program reading 25byte packets every 20msec.  Although I did run into the USB latency problem with another serial application.  I have a serial device that requires a response t changing CTS (clear to send) in less than 1.2msec, and VISA was taking 1.5msec.

On the same machine I am reading 1024 samples from an analog input every 100msec with out any timing issues - (once I got the incredibly slow start and stop vis outside the loop - they take about 200msec each.  Taking the start and stop vis outside the loop reduced my loop time from 450msec (approx) to 100msec.  The only problem is that to do this I have to run in continuous mode and can't  use an external trigger (it has to restart on every trigger, so the start and stop vis have to be in the loop).

So it appears that I have updated my technology by 10 years only to find that USB is incredibly slow - something that is not in any of the NI doccumentation that I can find.  Does NI have any documentation on what to expect in terms of performance from these USB devices and any suggestions on how to get better performance, apart from buying more expensive hardware?

Thanks 

[ichthus]

Hi

I have been able to get some improvements in performance

1. Combining reads of multiple inputs or writes of multiple outputs into a single task rather than having them in individual tasks saved some time - probably decreases the USB trafic.  However, you can only combine signals from one board and you can not have more than 1 timer per task in DAQmx-base.

2.  Changing the error wire from passing through the i/o vis in series to parallel halved the time to read two timers and 2 bits from 2 boards (6009 and 6501) (still required 4 tasks) - so it appears that time spent waiting for USB in one task can be used to access USB in another task.

3. The result is that the time to do the control loop reduced from roughly 35msec to roughly 20 msec with a huge improvement in tuning.