Analog Output sometimes underflows.

[Baturin]

Hi,

Two models have the same behavior:
Asus P5LD2-VM (Socket 775. i945G, Audio,VGA,GLAN,USB,PCI-E,m-ATX,DDR2,SATAII)
Asus P5WD2 Premium (Socket 775,i955X,Audio,2xGLAN,1394,USB,ATX)                
Regards,
Ivan

[nab-aki]

I have encounted same problem too!  We wish to controll 3 Analog Out channel on PCI-6229.
When we increase Analog Output rate (more than 20KS/s), then Buffer underflow error(-200016) is occurred. So, I alter "Data Transfer Mode" from DMA to Interrupt, then the error is eliminated.

In my case, this problem occured on SUPER MICRO motherboard(ModelName:X7DAL-E+). This motherboard has 2 PCI33 slots, 2 PCI-X slots, and 2 PCI-e slots. This problem occured on both PCI33 slots only. (It does NOT occured on PCI-X slot.)

Thanks.

[Baturin]

Seems to be quite common problem. M-series bug?

[stilly32]

Hi All,

We were able to reproduce this issue on an ASUS P5GC-MX board with a P4 using a PCI M-series. We haven't dug into the low level bus interactions yet, but basically it appears that the initial DMA transfer is not happening as quickly as it does on typical motherboards so when we start the generation the onboard FIFO overflows. The work around for this is simple: you can use a start trigger and there will be enough of a delay (unless the trigger comes right after the DAQmx start is called) for the FIFO to fill and the generation to start successfully. If you're not using a start trigger, you can still add a delay between the first sample clock and the internal start trigger to allow time for the FIFO to fill like so:

1 ms worked for me, you may need to add a slightly longer delay depending on your system. I've attached an example as well.

Please post back if this will not work for your application or if you have additional feedback. We will likely be adding some code to compensate for this problem in the next version of DAQmx.  

thanks, 

Andrew S

National Instruments

MIO Product Support Engineer

Message Edited by stilly32 on 01-12-2009 04:15 PM

[stilly32]

Quick correction: We haven't dug into the low level bus interactions yet, but basically it appears that the initial DMA transfer is not happening as quickly as it does on typical motherboards so when we start the generation the onboard FIFO overflows undeflows.

Thanks, 

Andrew

[Baturin]

Hi!

Nice to hear that the problem is not forgotten :).

Thanks.

[Bill_Anderson]

Hi,

I just wanted to point out that I have found this 200016 buffer underflow error has now been found on Intel Extreme motherboards as well as ASUS P5xxx motherboards, and it occurs with internal software triggering too.  In particular it occurred just when running MAX.  See:

  http://forums.ni.com/ni/board/message?board.id=250&thread.id=46795

Sincerely,

Bill Anderson

[stilly32]

Bill raised a couple good points:

To work around this in C use:

DAQmxSetStartTrigDelayUnits(taskHandleAO ,DAQmx_Val_Seconds);

DAQmxSetStartTrigDelay(taskHandleAO, .001); 

Also, you don't have to use an external trigger to take advantage of this work around, AO always uses an internal start trigger so you don't have to use an external trigger to delay from, the dleay can come from the internal trigger. 

Thanks, 

Andrew S

[ASharma]

Does this problem occur with MSI motherboards as well?  We think we're running into the same problem with an MSI (MS-7528 ver 1.0).

We were successfully running our application (generates three channels of AOs, regeneration allowed, update rate = 500kHz) for quite some time on a Win2000 desktop with a PCI 6229.  We had not changed the Data Transfer Mechanism but I believe it is DMA by default (right?).  The same application has also worked successfully for quite some time on an XP laptop with a USB 6259.  We have only the one AO task (i.e. no analog in, DIO, counters etc.).

We bought a new XP desktop, transferred the PCI 6229 and the application to it and immediately started experiencing underflow errors.  We worked with an AE and discovered it was an ASUS motherboard and he informed us about the ASUS problem.

We returned that computer and got a new one with this MSI motherboard.  Same problem.  Any ideas?

[ASharma]

UPDATE: We implemented the Trigger Delay suggested by stilly32 and the problem was solved (Thanks stilly32!).  Looks like MSI motherboards exhibit the underflow problem as well.