DIO underflow on 6533

[ToeCutter]

Hi,

I'm having some problems with a system not being able to write data fast enough to run a continuous digital output task without a buffer underun. The replay is written with daqmx and was tested in detail and has been run on a customer site 24/7 for many weeks without problem. We imaged the disc and used it to build a set of supposedly identical machines, (based on the same model laptop, purchased at the same time as the original as a batch) and now it turns out that all these 'identical' clones have an issue with buffer underflow. This can happen almost immediately on starting replay, or be after one to two hours. Replay rate is only 224,000 samples/s over 8 digital channels to a PXI 6533, so it shouldn't tax the high end laptops.

In investigating the problem, I am contrasting the DAQmx code we're using with our old traditional DAQ code, and it has raised a query over the buffer length. Traditionally, (and I believe this was based on examples available with LabVIEW), we created a buffer (224,000 samples in our case), filled the buffer, initiated replay, and then fed HALF buffers of data at a time in the servicing loop. It appears from the DAQmx examples that it is now different. Buffer length is initiated to the size of the first write, then WHOLE buffers (same size as initial write) are passed to the write function every loop. Is this how it should be? Why the change, what am I missing? It seems to me that this is a poor way of doing things because you're waiting until the buffer is empty to write? Presumably this then relies on just the boards onboard buffer (which is somehting like 64 samples) to take up the slack?

Anyway, coming from the traditional background, we have been using DAQmx but only writing half buffers in the service loop. Could this be part of the problem.

Any hints or tips very much appreciated.

Cheers

Lee

[Marshall_B]

Hi Lee,

Are you able to send us a screen shot of the underflow error you are seeing?  It would also be useful if we could take a look at your code and if you could direct us to the two example pieces of code that you have used.  

From what I understand you are initializing a buffer of 224,00 samples, waiting for all 224,000 samples to fill the buffer and writing only 112,000 values to a loop which then performs further data processing.  How often does this loop iterate and how often are you reading in samples from your DAQ device?  It may be that you are not passing the samples through often enough and that data is being overwritten.

It is strange to think that you are seeing an underflow error when only writing half of the buffered elements to the servicing loop at a time.  If this were the problem, I would have expected an overflow error rather than an underflow error but this could depend on the rest of your coding.  There should not really be any problems with either of the two writing methods provided that timings and number of buffered elements are all in sync.

[ToeCutter]

Hi Marshall,

Thanks for the response. I have been trying to produce a cut down version of the code which reproduces the problem, but it just won't crash. Can I email you the original code with the understanding that it's proprietary? It doesn't really do anything particularly special, but I have been asked not to post it on public boards.

Thanks

Lee

[RbCs]

Hi,

we are having a similar problem with on board underflows with the PCI version of this card.  Did you ever resolve this issue?

We upgraded from XP to win7 x64 and upgraded the motherboard but the Labview version and NIDAQmx driver remained the same.  Suddenly we can only output at 500kHz (32 bits) instead of 1MHz.  At 1MHz the card crashes partway through the generation and gives an on board underflow error.  The NI test specs for the card on ancient computers indicate 2.5MHz should be no problem.

http://digital.ni.com/public.nsf/allkb/4FCA248D888831C386256D8900563E45