Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

-200141 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.

Solved!
Go to solution

Hi

 

Setup:

2 x 6602 PCI

 

Configuration:

Continuously sampling five 50kHz PWM signals using five counters (2 on one card and three on another) for approx 10-15 sec. per recording.

All counter tasks are configured to DMA transfer.

 

Problem:

I keep getting -200141 errors from time to time.

 

Question:

I tried increasing the buffer size and all the counter tasks are configured to DMA. In the error message the final suggestion is 'divide the input signal before taking the measurement'. I do not understand this suggestion. What is meant by 'divide the signal before taking the measurement'?

I'm open to other solutions to the problem.

 

 

/mola

0 Kudos
Message 1 of 7
(7,317 Views)

..and I cannot recover from the error once it is thrown:

When I try to stop the task the -200141 error is thrown again, when I then try to abort the task, an -88709 error is thrown.

 

Does anyone know how to 'confirm' these error messages so daqmx stops throwing exceptions every time I try to do something?

 

/mola

0 Kudos
Message 2 of 7
(7,316 Views)

I suspect this relates to the relatively high total PCI bandwidth you need (shared among all tasks) combined with the

tiny on-board FIFO of the 6602 (only 2 samples I think).  Your error means that one of those on-board FIFO's is

being overwritten before the driver can move the previous data across the PCI bus.  If you're buffering PWM duty

cycles, you've gotta clear all those FIFO's every 20 microsec (because you get 2 samples per PWM cycle).

 

With 5 channels, 50 kHz semi-periods, and 4 bytes per buffered sample, you've got:

5 channels x 50 kHz/channel x 2 samples/cycle x 4 bytes/sample = 2 MB/sec bandwidth requirement.

 

I'd look into an X-series board that doesn't have to share it's PCI-express bus bandwidth with other system

components.  Probably more importantly, they also have  much bigger on-board FIFOs for their counters.  If you

put 4 measurements on an X-series, the 1 left for a 6602 seems pretty likely to work out ok.

 

-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 7
(7,307 Views)

Hi Kevin 

 

Thanks for you suggestion. 

Just to make sure I understand this correct:

1) Do you suggest that the DMA controller is not capable of emptying the on-board buffer into system memory every 20us? This is new to me but it surely could explain what I see.

 

As far as I can see the PCI bus is specified to >100MB/sec, so to me it sounds unlikely that 2MB/sec should cause a problem.

 

Do you know how big the on-board buffer is for say a 6320 card? - I do not find this information in the specs sheet.

 

 

/mola

 

0 Kudos
Message 4 of 7
(7,305 Views)
Solution
Accepted by topic author mola

Yeah, I know the 2 MB/sec doesn't sound like much, but it's a very low-tolerance high-overhead way to try to get 2 MB/sec.  You've got 5 DMA controllers to negotiate bus access and each one will transmit only 1 or 2 32-bit samples each time it gets access.

 

I've seen benchmark data posted where the max sustained rate was < 1 million/sec (don't recall if it was Mbytes or Msamples).  As I recall, finite acquisition mode allowed higher rates for shorter bursts.

 

Ah yes, here's one link that leads to other links.  Check out the part on "Counter FIFO's" in the first message.  There you see a *very* stark difference in performance from the M-series to the X-series.  Here is data for the E-series counters.  (It's fair to note the benchmarking was done with much older PC hardware).  The counter chip for the 6602 was designed between the E-series and M-series, so you can probably expect in-between performance.  

 

Note too that benchmarks appear to have been done with a single counter task trying to own as much PCI bandwidth as possible.  Since you'd have 5 tasks negotiating access, you'd definitely lose some more to overhead.  Also, for fair comparisons, your 50 kHz PWM would act like a 100 kHz measurement since you have 2 semiperiods to buffer per 50 kHz cycle.

 

Now that I've seen the benchmarks again, I'm convinced this is a no-go for you with just the 6602's.  The good news is that the X-series appear to be even more ridiculously capable than I remembered.

 

-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).
Message 6 of 7
(7,299 Views)

I thank you for your thorough investigation! - You've got me convinced.

 

I guess it is time for an upgrade. And the good news is that the 6320 is even cheaper than the old 6602 card.

 

A final note:

99.99% of the time sampling the five PWM signals simultaneously works fine, so it seems like I am operating right on the edge of this setups capabilities.

 

/mola

0 Kudos
Message 7 of 7
(7,294 Views)