6259 Analog Output error with onboard sample clock

[klessm1]

I am running into some problems outputing an analog output sine wave with my DAQ using the onboard sampleclock. At one point I was able to get the vi running quite well and repeatable. When revisited however, I started seeing error that the driver could not provide the device with the points fast enough. I was running the sampling rate at 250k for a 1k tone, but I seem to only be able to get about 20k sampling rate. This creates a fairly choppy signal expecially when the frequency is bumped up to 8k. I am only producing 1 second of data.

See attached bmp. The I/O references passed in are channels not tasks. Could this be the problem? I'm a little frustrated as this should be a very simple vi to create and I am having all kinds of trouble with it.

[sundarganesh]

Hello Klessm1,

Please attach a screenshot of the error code. That will help in finding the source of the problem.

Regards,

Sundar Ganesh

[klessm1]

Attached is the error.

[EEsRULEtheWORLD]

Hi,

The memory underflow error that you are experiencing could be the result of several things.

Some questions and suggestions:

1. Try increasing the buffer size.   This error is usually triggered when the sample size (buffer size) is too small.
2. Try using a property node to allow FIFO regeneration.  When regeneration is enabled, data written to either the user buffer or the FIFO is reused by the DAQ device.  In this way, a continuous output can be achieved without LabVIEW (or other ADE) having to continuously write new data to the buffer.  With FIFO regeneration, data is regenerated straight from the onboard FIFO. No data is transferred across the bus. Furthermore, all data must fit on the FIFO. To enable FIFO regeneration in DAQmx, a DAQmx Channel property node must be used. Wire a 'true' to the AO.UseOnlyOnBrdMem property.
3. What kind of motherboard are you using in your computer?
4. Is this a PCI 6259? USB 6259?  If it is USB, are you connected to a hub or directly to a port on your computer?

Message Edited by lewandroski on 07-07-2009 07:56 AM

[klessm1]

Thanks for the tips.  I will try those out.

3. Not sure what exact motherboard it is (I am not in front of the computer right now), but it is a new industrial computer with a duel-core Intel uP.  We were trying it on an older single core machine as well and we were having issues right above 20k sampling where the industrial computer was ok.

4. PCI 6259 (regular, not PCI express)

Thanks!

[John_P1 · Accepted solution]

Hi klessm1,

I want to point out that the behavior you are seeing is atypical--under normal circumstances DMA transfers should occur fast enough to keep data in the on-board FIFO continuously up to at least the max sample rate (2.86 MHz on a single channel).  Having said that, the error you are receiving indicates that we are not getting data to the 6259 fast enough for some reason--there are a few options we have at this point to get you up and running:

Remove the necessity to transfer data to the device.  As Sarah suggested, you can do this by regenerating from the on-board FIFO.  The output FIFO on the 6259 is is 8,191 samples (shared between channels), so if you are generating a periodic signal and this is a sufficient number of samples to characterize one period then this should be a viable option.

Try using Interrupts instead of DMA.  This may seem counterintuitive since DMA is typically the fastest method of data transfer on our DAQ devices, but something sounds amiss with the DMA transfers from your computer to the 6259.  I imagine you will actually get faster rates using Interrupts if this is the case.  

You can configure the device to use only onboard memory or interrupts by using a DAQmx Channel Property Node (Analog Output >> General Properties >> Advanced >> Data Transfer and Memory)

Implement a delay between the start of the task and the first sample.  If the problem is with the latency of the first DMA transfer (as opposed to the total throughput over the PCI bus), then adding a delay before you try to write the first sample should resolve the issue.  Certain motherboards have been found to have a higher latency than others (hence Sarah's question #3). 

You can configure this delay with the DAQmx Trigger Property Node (Start >> More >> Delay / Delay Units).  This applies even if you don't explicitly have a start trigger configured.

I think all three of the above solutions are good ideas to try depending on what you require exactly.  I would also check for any BIOS updates available for your motherboard that might remedy the issue (but this would be something the manufacturer would know more about).  I hope this helps--let us know how it goes!

-John

[klessm1]

The suggestions worked great...after I finally got around to it.  I regenerated the points onboard the device and I can get around 800kS/S.

Thanks!