Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Error -200141 encountered while counting edges using a PCI 6251 device using an external clock

Hi,

 

I have a NI PCI-6251 device. I have created a counter input edge-count task. I receive the following error when I try to sample at 300,000Hz with an external clock:

 

Error -200141 occurred at DAQ Assistant
Possible Reason(s):
Data was overwritten before it could be read by the system.
If Data Transfer Mechanism is Interrupts, try using DMA or USB Bulk. Otherwise, divide the input signal before taking the measurement.

 

Providing an external clock from a function generator does not help resolve this. Sometimes I see this at 270,000Hz. My experiment was conducted on NI-Max. Here are the steps I followed:

1) Create a task. Select the "Acquire Signals" drop down, then under "Counter Input" select "Edge Count". 

2) Select the NI PCI-6251 device. 

3) In the configuration tab's Timing settings, set the Acquisition Mode to "Continuous Samples" and set the rate to 270k. 

4) Click on the "Advanced Timing" tab.

5) Set the external clock source to the correct terminal. 

6) Click "Run"

 

The error shows up in a pop up window. Please note that this experiment was performed on a real device and the behavior isn't reproducible on a simulated device.

 

Please let me know what is the correct setup to be able to count edges at rates such as 2MHz. Is is the upper limit on the sampling rate? If yes, what is the limit? Is there a NI-DAQmx function that I could use to find that number for a PCI device. 

 

Thanks,

Varun Hariharan.

MathWorks

0 Kudos
Message 1 of 4
(4,167 Views)

First I'd want to clarify whether you need to *sample* at up to 2 MHz, or whether you just need to count pulses that arrive at up to 2 MHz.  What's the whole measurement about?

 

First let's tackle high speed sampling.  The problem with sampling in the 100's of kHz and higher with your M-series board is that the on-board FIFO for counter values is very small, only 2 samples wide if memory serves.  That's the underlying reason for the error you see.  There's really not very much you can do about it.  The driver & DMA just can't sustain 300 kHz indefinitely when the FIFO buffer is so small.  Newer boards (including, I believe, the X-series MIO boards) have much larger FIFO's and deliver much better sustained performance for continuous counter measurements.

 

All that said, let's now address whether 2 MHz sampling is really needed.  I've done a lot of fiddling with NI counters and feel pretty comfortable with them, but the fact is that counter measurements take a little bit different mindset than thinking about regular analog or digital sampling.  A key thing to grasp very clearly is the distinction between counting and sampling.

 

Each counter has a count register that will either increment or decrement based on receipt of digital edges into its logic circuitry.  This counting happens whether or not you are sampling it.  In your app, you can absolutely and definitely *count* at 300 kHz or 2 MHz for as long as you'd like.  When the count value reaches its maximum value (2^32 -1), the next edge makes the count register "rollover" back to 0 and continue counting.

 

*Sampling* is the act of requesting or storing that count register value.  In software-driven on-demand mode, this happens with a software function call to DAQmx Read.  In hardware-driven sampling mode, this happens when there's a sample clock edge at the designated input.  The important thing to note is that the sample clock signal is *different* than the signal that causes counts to increment.

 

Maybe I'm telling you things you already know, but this distinction has been a fairly common source of confusion on the forums.  It's no wonder, counters really do require a little shift in mindset compared with the other kinds of tasks.

 

 

-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 2 of 4
(4,146 Views)

Hello Kevin,

 

Thanks for your response. My application involves sampling at up to 2MHz and not count pulses that arrive at up to 2MHz. I understand why I receive the error. 

 

From your response, I understand it isn't going to be possible to sample at that rate with this specific device. Please correct me if I am wrong. Is there a way (a NI-DAQmx function) to find the maximum possible sampling frequency (for counter applications) from a given device? I have an application where I allow the user to set the sampling rate. I want to prevent my user from setting a sampling rate that might cause this error. 

 

Thanks,

Varun Hariharan

MathWorks

0 Kudos
Message 3 of 4
(4,134 Views)

No, there won't be anything you can query from DAQmx.  There isn't a set limit, it's system dependent with PCI bus negotiation as a prominent limiting factor.   Here are some benchmarks for your series of card, suggesting that the upper limit may be somewhere in the 300-400 kHz range.  But it's far from guaranteed.

 

Info on X-series counters suggests 10 MHz sampling can be possible.  The larger FIFO on the X-series boards makes the benchmarks much more likely to be regularly achievable on a variety of systems.

 

 

-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 4 of 4
(4,131 Views)