Analog Output sometimes underflows.

[Flipp]

hi everybody,

I´m having problems using the analog outputs of a PCI-6251 DAQ. My aim is to generate 2 Channels with a Samplerate of 54000 S/s. The signals are non repetitive so I form blocks of 2x1080 to pass them to the hardware. In one out of three times I use the application it works fine but then it starts giving the underflow Error randomly (Fehler -200016 ist bei DAQmx Write (Analog 1D Wfm NChan NSamp).vi aufgetreten). I tried everything the suggested in the Error message but i still do not get better results (dma...).
Is there a way to get relyable results.

Thanx
 

[Ingo_Schumacher]

Hello Flipp,

difficult to say what exactly causes the problems. In general, the error occurs, if the application fails to write data to the output buffer on time. Commonly this happens because of lack of resources.
Since the M-Series DAQ boards have 6 DMA channels, your AO operation should use DMA as a default. That is why it does not make a difference if you explicitely change the tranfer type to DMA.
I dont know the specs of cour computer, and which operations are happening in parallel to rthe output, but there is one thing that works always:
Increase the block of data you are writing to the buffer. Try to write blocks of 5400 values instead if 1080, this should decrease the overhead in the operation and save some performance.
Furthermore, doublecheck that you do not have some loops that need extra performance in parallel to the AO task. Make sure that every loop has its timing and none is running un-braked.

regards

[Flipp]

Thank you Ingo,

We solved our problem be changing our Computer Hardware. We switched from a  Prozessor    x86 Family 15 Model 4 Stepping 1 GenuineIntel ~3211 Mhz with 1GB Ram on an ASUS P5GD1 Motherboard to a slower maschine ( AMD Athlon 3000+ 1GB Ram ASUS A7N8X-X). No we can write blocks of 1080 Samples with up to 500kS/s to the Analog Outputs simultainusly in non regeneration mode, more than enough for our application.
We think that the PCI Bus System of the ASUS P5GD1 caused our problems. Probably it has a mailfunction in PCI Express to PCI communication causing a bottleneck.

Thanks again for your answer.
Flipp

[Baturin]

Hi!

Suddenly I have encountered the same problem and also on ASUS with PCI 5251 (several items)! More specific P5WD2Premium and P5LD2 motherboards. It is very annoying because we have bought  3 such computers specially for experimental setups and they are the most powerful among that we have. Just using AO in MAX test panels results in error  -200016 while trying to use more than 30-40 kHz rate. It is OK to use interrupts at the maximum possible speed and at the same time using AI at maximum speed. But default transfer (DMA) is failed permanently. It is worth to note that there is no problems using AI (which I suppose also uses DMA by default). I have tried to do DI and DO at the maximum possible rate (generating or measuring many samples with high rate) and both are working without problems.

A couple of Gigabyte boards (slightly older, without PCI Express) are working OK with all PCI 6251 boards.

I understand that there should be an ASUS problem, but at the same time it seems to me that the problem is specific to NI PCI boards. What we can try to do with it? How is it possible to find where is the trouble? What BIOS settings to check? Can NI try to test one of asus motherboard like P5xxx with such a board because it seems to be not only one accident?

Many thanks in advance!

P.S. By the way, USB 6251 working like a charm. But I don't  know the details about usb transfer mechanism.

[An Engineering Student]

I'm having the same problem. I'm using the USB-6251, and using the frequency sweep vi found here:
http://zone.ni.com/devzone/cda/epd/p/id/16

I tried decreasing the samples per buffer, but it did not solve the problem.

Any other suggestions?

[stilly32]

Hi,

At what sample clock rate did your AO fail? Also, how far did you decrease the samples per channel? Just to see if is your system or the code, try a MAX test pannel on AO and select Sine wave generation. Set the rate to ~2-2.8M - do you get the same error? You'll probably get at least a 200040 warning - this is expected.

 If you're still getting an underflow, what are your system specs (proc, MB, RAM, USB 2.0...)

cheers,  

Message Edited by stilly32 on 03-20-2008 10:25 AM

Message Edited by stilly32 on 03-20-2008 10:26 AM

Message Edited by stilly32 on 03-20-2008 10:26 AM

[An Engineering Student]

Thanks for the resources.

I ran the test panel in MAX, and I'm still getting the error. I get it anywhere from ~5 kHz and up. So I guess it's a hardware issue then? I'm running a virtual windows server on my mac -- 2 GHz Intel processor, 2 GB RAM, USB 2.0.

Message Edited by An Engineering Student on 03-20-2008 01:35 PM

[stilly32]

Vitualization itself causes some issues and isn't fully tested with our hardware - using it from OSX tends to complicate things futher. I use VMWare occassionally on my Windows box and see significant performance decreases - I can run AO at max rates on XP, but when I run it on the same machine through XP in VMWare, I top out at ~600k. This isn't just NI USB HW with this issue - its present with pretty much all USB traffic (try downloading a large file from a thumb drive).

I'm guessing that your USB-6251 is fine and that virtualization with USB sharing is your issue. Can you try this on a Windows XP machine and see if you get the same performance?

As for a workaround, if you're just writing a small waveform and just repeating it over and over again, you could use onboard regeneration (check out the LabVIEW shipping example) and you should be able to run that at the max rates because it doesn't depend on streaming rates across USB.

cheers,

Andrew S

Message Edited by stilly32 on 03-20-2008 04:53 PM

Message Edited by stilly32 on 03-20-2008 04:54 PM

[Baturin]

We have underflow error at 30-40 kHz rate while generating sine from MAX AO test panel on PCI 6251 board. We didn't use any virtualization, just winxp. Interrupt mode is OK, but DMA immediately shows the error.
The error occurs only when using ASUS P5xx series motherboards on a couple different DAQ board. Others MB are working OK.
Seems to be some hardware issue...
It would be nice if somebody from NI can test such kind of board. They are a lot of different subseries and models available in P5 series.

[stilly32]

Hi,

Can you post the exact model of the motherboard? We're in the process of acquiring one to test out and I'd like to know if the current chipset (Intel P35) reproduces this behavior as well.

Thanks,

Andrew S