6143 counter input max frequency

[Dave Sprinkle]

Hello everyone,

First of all, thanks in advance for any assistance or insight you can provide.  Here is a summary of my application:

I have a PXI-6143 card that will be performing 3 operations:

1.  Sample 1 to 8 analog inputs on the rising edges of the a-pulse of a rotary encoder.
2.  Measure the period of the a-pulse of the rotary encoder.
3.  Count the rotary encoder z-pulse and log the count on each rising edge of the encoder a-pulse.

The card will be performing these tasks continuously for 12s.  The frequency range of the a-pulse is 12kHz to 192kHz.

Here is the problem -- I have been unable to drive the input frequency higher than roughly 100kHz.  If the input frequency reaches ~108kHz, Labview responds with error 200141, "Data was overwritten before it could be read by the system."

In my testing so far, I am fairly certain that this error does not result from inaccuracy in the period of the Labview service loop.  The loop period will vary by about a millisecond or so, but I've sized the 6143 buffer to ensure that Labview retrieves the data quickly enough to avoid buffer overflow.  It appears to me that this error is the result of a frequency limitation in the internal data bus of the 6143.  Can anyone comment?

Again, thanks for your help.
-dave sprinkle

[PBear]

Hi Dave,

This is most commonly associated with 1.) the parameters when setting up the timing engine are not configured correctly or 2.) the DAQmxRead is not being called fast enough/isn't pulling enough samples from the buffer.

Try increasing the rate parameter to the timing VI, increasing the samples to read on the DAQmx Read VI, and also the samples per channel on the Timing VI and see if this resolves the problem.

[Dave Sprinkle]

Thanks, PBear, for your comments.  Regarding your suggestions:

1.  Timing engine not configured properly.  I'll concede that I might have missed something here, but I will say that I've iterated on just about every option available to me, without affecting the behavior of the system.

2.  Not reading the data often enough or not reading enough data.  Regarding the read-period, I have iterated from 10ms to 100ms, with no effect.  Note that I have been careful to configure the buffer size appropriately for the read-period and the input clock frequency.  I should point out that even running a 1.5x or 2x buffer size has no effect on the problem.  I have set up debug code that measures the read-period and number of samples retrieved.  The failure occurs even when the read-period is OK and the number of retrieved samples is significantly smaller than the buffer size.  Regarding quantity of the retrieved data, I have configured the read function to retrieve all available samples, so this shouldn't be a problem.

As I mentioned, it seems to me that this behavior can be explained by a limitation on the speed of the 6143 data transfer path.  Software servicing interval doesn't seem to be the issue here.

Thanks.
-dave

[PBear]

Hi Dave,

You may want to attach a small example of the problematic code for the community to look at. If you can remove any excess code that is not relevant to the problem then it would make finding the problem a little easier.

[Dave Sprinkle]

Here is a VI that illustrates the problem.  In general, the higher the input frequency, the more readily the problem occurs.

[PBear]

Hi Dave,

Are you getting the error in this VI or your analog input VI that is being driven off of your external clock? I was under the impression that your analog input task was throwing the error, not the counter period measurement task.

In anycase, use of the DAQmx Configure Input Buffer.vi should be used sparingly. This is especially the case for implicit timed tasks as the driver handles many more things automatically than the Sample Clock polymorphic instance.

You'll want to make sure your board is using DMA as the data transfer mechanism to make sure your onboard FIFO is being transfered to RAM as fast as possible. Follow this KnowledgeBase to ensure this: KnowledgeBase 34FGAFVM: How do I Configure the Data Transfer Mechanism (Interrupt or DMA) in DAQmx a...

There is a limit to how fast of a signal your counter task can measure so you are correct on that front. This is because of the FIFO size on the card and also your system performance. This may be part of your case as it sounds like you are doing multiple tasks which will put more strain on the bus than a single task. Refer to the following forum posts and KnowledgeBases for more information on how buffered counter measurements are implemented and the performance to expect. Also look at many of the related links on them as they are very informative.

Ignoring FIFO Overflow Error -200141
http://forums.ni.com/ni/board/message?board.id=40&message.id=6057&requireLogin=False

Disabling data overwrite Error 200141 NI-DAQmx
http://forums.ni.com/ni/board/message?board.id=170&message.id=257152&requireLogin=False

KnowledgeBase 3RA73U2W: Error 200141 Occurs When Doing Buffered Event Counting With DAQmx Base?
http://digital.ni.com/public.nsf/allkb/83656593DCF1FB0F862570B6004D7222

KnowledgeBase 40TFKJ46: Benchmarks for Buffered Counter Input with M-Series Devices
http://digital.ni.com/public.nsf/allkb/72A7E41EE5A8756A862571DA0076F1D7

KnowledgeBase 2JCD04EW: How are Buffers Read in Finite vs. Continuous Buffer Mode for Counter Operations?
http://digital.ni.com/public.nsf/websearch/D2C16FADED423B5486256B7B006DE3BE