Slow task ‘DAQmx Read.vi’ causes error 200279

[WENGQQ97]

After almost one more day attempt again on those parameters, I still make no progress. As my program has post-processing algorithm and I can't find time counting in nanosecond (there might be in labview RT version?), now I focus my test with the NI example 'Analog Input - Voltage and Thermocouple in a Single Task.vi'.  I delete the Thermocouple function and make it simple to test, see attachment. I set the sample rate to 2000 and number of samples to 320 and then run the program with DAQ cards pci-6221 or USB-6008. Same situation happens like when my program runs. With the same program and parameters, error 200279 appears in less than 2 minutes when reading data from pci-6221, however there is no problem when reading from USB-6008. Does anyone know what causes this difference? Thanks.

[ZYOng]

Don't wire the same value to the sample per channel input on both Timing VI and Read VI. This will cause the buffer to have the same value with the number of sample requested for each read, hence the risk of buffer overflown. All examples leave the sample per channel unwired such that the driver will decide a much larger buffer size based on the sample rate. See DAQmx Buffer Size Allocation for Finite or Continuous Acquisition

[WENGQQ97]

Hi ZYOng, You are right, the original example leaves Timing vi unwired but the Read vi is wired to the input setting. I tested the original example but error 200279 aslo happened so I tried to wired them together as my program does. Tomorrow I will unwire them to see if the problem is solved. Thank you very much. 

[Kevin_Price]

The article ZYOng linked is good, but slightly flawed.    There's a similar one that pops up with a google search for "ni.com daqmx buffer size" that does a better job clarifying some things, particularly:

• no longer ambiguous about default buffer size for sample rates of 100 or 10000
• makes clear that the chart defines a *minimum* buffer size for Continuous Sampling tasks.  If you ask for less in your call to DAQmx Timing, you get the default size from the chart.  But if you ask for more, you get exactly what you asked for.

So I don't expect you'll see a difference between wiring a value of 320 or leaving 'samples per channel' unwired in the call to DAQmx.  As the chart shows, DAQmx will make a buffer of 10000 samples per channel.

That said, I'm very surprised that the example program produces a buffer overflow error with a PCI device while working fine with a USB device.  I'd expect both to handle your situation pretty easily, but if *anything*, I'd expect a USB device to be more vulnerable to your error.   

    What you're reporting is *not normal*.  I've got a PCI device in the lab that lets me capture at 5 MHz for several minutes without a buffer overflow.  There's no *good* reason that the example code you posted should lead to a buffer overflow.  Can you think of *anything* you haven't mentioned previously that might possibly shed further light?

-Kevin P

[WENGQQ97]

Hello Kevin, I totally agree that it's *not normal* there is still error 200279 even when I test with NI original example at 2000 sample rate / 320 sample numbers.  In fact, as I said in my first post, one of my new computers also can work fine even with my own program, so I'm not surprised that there is no problem at your side. That's exactly issue that I want to figure out. Is there any parameter of computer that can cause this issue?

I add a property node of available number per channel to read after Reading VI(see attachment). When I test with USB-6008, AvailSampPerLoop and AvailSampPerChan are alway 0, but when testing with PCI-6221, AvailSampPerLoop fluctuates from 0, 2 and 4(what I can see) and AvailSampPerChan is increasing correspondingly. Even in my new working computer, it acts in same way (AvailSampPerChan reaches 6150 in 13 minutes), but I don't know why that computer doesn't have any problem after it runs for more than 15 hours continuously, and others fail in 2 minutes. Does this test make any help to solve my problem. Thanks.

[WENGQQ97]

One more thing I notice, the manufacture day of these PCI-6221 shown on their boxes is 2007.03. The labels related to date on boards show copyright 2004 or copyright 2006 (I admit that they are old, but I don't want to discard them. Both versions work fine in that good computer). Is it possible the compatibility issue with new windows system causing this problem? 

[Kevin_Price]

Your code is not the problem here.  Something else is.  M-series boards have been around a long time, delivering data reliably at orders of magnitude higher sample rates than what you're asking.  So I wouldn't point the finger at DAQmx either.

FWIW, summing up a cumulative total of "Available Samples" from iteration to iteration isn't really a meaningful metric.  You could have 2 or 4 available after every read for several hours and accumulate a sum much bigger than your buffer size, even though you never "fell behind" by more than 4 samples at any given instant.   It'd be better to simply monitor "Available Samples per Loop", perhaps in a chart, watching for *it* to grow over time until you fall behind by most of the buffer size and cause the error.

I made a couple small mods to your code for diagnostic purposes.  I queried DAQmx property nodes to show the "Data Transfer Mechanism" (to confirm that DMA is being used rather than interrupts, especially on the systems with problems) and "Input Buffer Size" (to confirm the chart which says it should be at least 10000 for a 2000 Hz sample rate).  I changed the # samples to read to be a front panel control, so you can change it while running and observe the effects.  And finally I changed your accumulator to simply retain the max # available samples seen in any particular loop iteration.

Running it here (albeit on a PCIe-6341 card), my # available samples per loop typically ranged from 0-4 with a max of 5 or 6.  It seemed almost entirely insensitive to the # samples I read per iteration, all the way down to reading only 1 sample at a time.  I wouldn't recommend doing that in the real app, but figured I'd report what I observed nonetheless.

I don't know what's going on, but this gives you just a little more versatile tool for investigating further.

-Kevin P

[WENGQQ97]

Hi Kevin, Thanks for the help. I run the program. In less than 2 minutes the problem happens and then I capture the image. According to the result, it's DMA data transfer mode and the buffer size is 10000. The MaxAvailSampPerChan is never bigger than 4 in my case when the problem happens. 

I've also run the "test panels" function in NI MAX, "test panels" also gives error 200279 after 15 minutes but in 1 hour (not sure exactly what time) instead of in 2 minutes. Not sure this difference can do some help for the diagnosis. 

[WENGQQ97]

I just notice that the DAQ driver in the computer that I have error 200279 doesn't have proper driver even after I recovered the windows and reinstalled the 2015 NI software package twice when I diagnose this issue. it might be due to the old version in the installation package is not compatible with new windows and PC hardware. I'm updating the driver to 18.6 (the last compatible one for LV2015) and will post here what I find. Thanks.

[Kevin_Price]

Oops, didn't refresh before answering so everything below the line is in response to msg #18.  I'm very interested what you find out with the DAQmx version change.  Seems more likely to be the root cause than most of the stuff I speculated about below.

--------------------------------------------------------------------

Sorry, no good answers here, it continues to be really weird.

Buffer size is 10000.

You read 320 per loop iteration.

The maximum # of "available samples" immediately after the read is 4.

How in the world does that add up to a buffer overflow?!?

I think I'd take the 1 new PC that works ok and 1 of the ones that doesn't and start doing some deep dive scrutiny for differences.  Things like BIOS version, motherboard version, and perhaps some A/B swaps of parts to see if the problem moves with the DAQ device, the video card, the RAM chips.

    No real theory here, but that's the kind of stuff I'd be doing at this point, hoping for accidental magic.   I'd also work to fully uninstall DAQmx, reboot, and reinstall.

Meanwhile, try further experiments where you read more or fewer samples per loop iteration.  Make an indicator for your iteration #.  Maybe add an "Elapsed Time" function too.   You've been seeing the error after ~2 minutes so far.  As you change the # samples to read, try to see if the error correlates more with 2 minutes worth of acquisition or some particular # of calls to DAQmx Read.

Maybe even try calling the 2D Array version of DAQmx Read instead of the array of waveforms.  Then also try outputting to an array indicator instead of a graph.  Also try the 1D array for a single channel.   Basically, keep poking and prodding at the very few things you *can* tweak in hopes that one of them reveals a clue or two.

-Kevin P