Multifunction DAQ

Showing results for 
Search instead for 
Did you mean: 

What is the max. readout rate (ext. clock) for counters on USB-6221 ?

Hi DAQmx-Experts,


I have two quadrature encoders which I need to read synchronously (externally clocked) at a rate around 50 kSamples/s. I wrote the program using a PXI-6251 and it works just fine. Now the custumer wants to use a USB-6221 and it seems I keep loosing measurements unless I drastically (5 kSamples) reduce my sample rate. Even then I seem to miss data occasionally.


Has anybody been investigating what data rates can be achieved (and how !) ??? Nice as the flexibility of USB-DAQ seems to be at first sight, it doesn't make sense for us, if I cannot get better performance out of it.


Any suggestions are greatly appreciated


thanks HU

0 Kudos
Message 1 of 7

Dear Hurban,

Your issue seems very interesting.


I would like to find out a bit more information about the system that you are using.


The USB-6221 can cope with the 50kS/s that you require as an actual unit. However there could be a few other underlying issues that could cause this data loss of yours.


Are you using the USB cable just for data acquisition or is it being used bi-directionally?


I was also wondering what other hardware are you using within your system? Just so I can get a better grasp of your overall system.


There may be an issue within your underlying Architecture code.

Are you using Labview to program this? For instance, if you are using notifiers, then the reading’s are not queued, rather the latest reading will be taken therefore causing some of your reading’s to “disappear”.

Message Edited by Ashish N on 10-06-2008 10:38 AM
Ashish Naik
Automotive Business Development Manager
National Instruments UK
Message 2 of 7

Dear Ashish,


thanks for the quick response !


- No there is nothing else on the USB-cable but the laptop and the USB-6221

- no other hardware, just the DAQmx card

- yes I am using LabView but no notifiers in this VI


I will try to "extract" that particular piece of code and post it a.s.a.p.


thanks again


0 Kudos
Message 3 of 7

Dear Hurban,

I look forward to seeing your code if that is possible.


Are you receiving any error messages when running within Labview? if you cannot actually extract the actual VI, then a screenshot of the VI's used will be useful.


Another thing to try is using Measurement & Automation Explorer (MAX) to test the hardware is working properly. Try using the Self-test and test panels to try this.

Ashish Naik
Automotive Business Development Manager
National Instruments UK
0 Kudos
Message 4 of 7


have attached the error message, looks like what we typically see when polling to slowly in a continuous acquisition, BUT: I am doing a FINITE acquisition !


The hardware (selftest etc. is ok.) all other components (AI, DIO) on the board seem to perform as expected.  


Attached is also my code "". There are 3 channels that I need to acquire synchronously: Reference Encoder (RI), Unit under Test (MS) and an additional digital input PI. All these are sampled at the same external rate "RS_A"


The procedure is as follows:

- calculate a suitable buffer size in

- Configure a FINITE acquisition in Counter_Init etc.

- start the Motor that is moving the encoders (Motor Move_Rel)

- from now on the RS_A input is delivering Sample Clocks and the DAQmx-Read VIs are collecting data until either

the buffer is full or a timeout occurs which is the intended exit case because I never want to overfill the buffer.


As I said this works perfectly fine at 50 kHz sample rate on the PXI card, only on the USB-card the DAQmx-Read VIs exit with error -200141 unless I drastically reduce the sample rate.


Actually I found a KB article saying that the performance of the USB should be roughly the same as the PCI, if I understand it correctly: 


Any good ideas ??


Thanks for taking your time



Download All
0 Kudos
Message 5 of 7



What are you using for a sample clock for the encoder measurement? I'm curious to know if that is a constant 50k (like from an AI sample clock) or some other signal that might vary. You are correct that USB performance is generally around PCI/PXI performance so I'm suprised you're having an issue. Can you confirm that you're using a USB 2.0 port?


Other things to check - I know Vista has some USB issues, but most of those were addressed in SP1 (or whatever they decided to call that first update) so that might be worth looking into. I'm not sure if I'm reading this right or not - do you still get the error if you just run the counter, and no other tasks (AI, DIO...)? If not, what rate are you running those other tasks? Other tasks could take up enough USB bandwidth to effect counter performance, especially since counters on these cards only have a 2 sample FIFO.


Other things that can effect USB throughput in general are things like system resources (CPU usage and memory) using USB hubs and extenders and bad USB chipsets. Do any of these conditions apply to you?


Thanks and hopefully this sheds some light on something, please post back if things still don't work or if you figure out what is causing the problems.


Andrew S

MIO Product Support Engineer

National Instruments  

0 Kudos
Message 6 of 7

Hi Andrew and thanks for the really elaborate answers/suggestions !


The sample clock comes from the (mechanical) reference encoder itself, so there are certainly frequency variations / oscillations of the mechanical system. I will look into all of your suggestions in great detail when I am back at home. Actually I am right now attending the NI-VIP conference in Munich - lots of your colleagues here 🙂


Thanks a lot for the moment and I will certainly keep you informed of any of  my findings


regards HU

0 Kudos
Message 7 of 7