Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

error -200621

Hi

 

I have an app which generates a signal through the output of a USB-4431. This is looped back to an input and captured. The capture and playback is synched via a start trigger (/ai/StartTrigger). This produces a perfectly reproducible waveform capture (i.e. sample accurate).

 

The capture buffer size is 100 kS, the generator buffer size is 50 kS. The sample rate is 48 kHz

 

Unfortunately every once in a while I get an error that looks this:

USB underflow

 

and at other times I get this:

Reduce sampling rate and increase timeout

 

Reducing the sampling rate to 1 kS resolves everything and it chugs along nicely.

 

I would really like this to work at higher sampling rates. What are my options?

 

Thanks

Nirvtek

 

 

 

 

0 Kudos
Message 1 of 11
(5,539 Views)

Hi nirvtek,

 

So it looks like the problem is with the generator buffer size being to small for your sample rate.  Here is a reference on how you should determine buffer size:

 

http://zone.ni.com/reference/en-XX/help/370466V-01/mxcncpts/buffersize/

 

Also, here is another KnowledgeBase article on getting your second error that goes over sample rate and samples to read vs timeout:

 

http://digital.ni.com/public.nsf/allkb/FEF778AD990D5BD886256DD700770103?OpenDocument

Peter T
Applications Engineer
National Instruments
0 Kudos
Message 2 of 11
(5,509 Views)

The errors don't occur with a virtual version of the device.

 

I tried upping the buffers to 100 kS for input and 50 kS for output with a 3 s wait period. Even if I set the wait period to -1 (INFINITE) the error still occurs.

 

 

The machine has other USB devices connected pretty much all the time. I wonder whether this is what's causing the errors?

0 Kudos
Message 3 of 11
(5,491 Views)

Increasing the buffer size doesn't help things. At 48 kHz in continuous mode I used a 500 kS buffer and the same error occurred.

 

Is it possible the USB device can't handle 48 kHz input and 48 kHz output at the same time? It seems unlikely but this is the device:

 

USB-4431 (USB-4431)

 

I got another error message which suggested using USB Bulk mode.

0 Kudos
Message 4 of 11
(5,480 Views)

The buffer size that you are changing is not the onboard FIFO buffer. It is the buffer on the PC memory. The error is associated with the output task and the buffer on board the device overflowing or underflowing. Would you mind posting as simplified code as you can for the AO task alone? What is the data you are outputting? Does it change over time or could we regenerate the same pattern for the durration of the test?

0 Kudos
Message 5 of 11
(5,464 Views)

I'm outputting a pre-defined sine wave. The wave may be looped many times. The size of the source buffer can vary. During this failure, the source waveform is 131072 bytes (128KB).

 

The source is like this (source_buffer_size = 131072, frequency is 48000 and playback buffer size is 50000)

 

while( !finished )
{
__int64 remainder = playback_buffer_size;

while( remainder > 0 )
{
__int64 run_remainder = source_buffer_size - source_pointer;
__int64 to_write = __min( remainder, run_remainder );
// slots is the number of output channels assigned to this task, it's synched to
// an input task on the same device
for( int i = 0, m = slots.size(); i < m; ++i )
{
memcpy( buffer + i * playback_buffer_size + output_pointer,
source_buffer + source_pointer, to_write * sizeof( double));
}
output_pointer = (output_pointer + to_write)%playback_buffer_size;
source_pointer = (source_pointer + to_write)%source_buffer_size;
total_samples += to_write;
remainder -= to_write;

}
}
if( 0> (err =DAQmxWriteAnalogF64(national_instruments.vTasks[dev_id],
playback_buffer_size, true, (int)(playback_buffer_size/national_instruments.frequency) + 1,
DAQmx_Val_GroupByChannel, buffer, &written, NULL )))
{
if( DAQmxFailed(err) ){
DAQmxGetExtendedErrorInfo(errBuff,2048);
strcat( errBuff, "(During output)" );
::MessageBoxA( NULL,errBuff, "App Error", MB_OK );
break;
}
}

0 Kudos
Message 6 of 11
(5,461 Views)

It might be a good idea to use regeneration. The DAQmx API has regeneration by default. Using a continuous AO task, you can write to the onboard buffer with the samples in the waveform once before the task starts. This will output the same pattern over and over until the task is stopped.

There is a white paper on the subject here:

http://www.ni.com/white-paper/3874/en/

 

I hope this helps,

Eric E. 

0 Kudos
Message 7 of 11
(5,449 Views)

Would that take up system RAM to carry out regeneration? Currently I'm using a RAM based souce buffer, but would like to move it to disk.

 

The app is 32 bit and already there're limitations as to how big the source and capture buffers can be. Currently they can be moved to disk, though the NI code doesn't support it yet.

 

I'm guessing regeneration will take up space in the application's RAM allocation.

0 Kudos
Message 8 of 11
(5,433 Views)

Nm. Both system memory and FIFO buffers are available.

 

Thanks! This has resolved my issue. I will post back in a couple of days whether this has completely solved my problem.

0 Kudos
Message 9 of 11
(5,426 Views)

Well... it's been a couple of days.  Did it work?  I've got the same problem, and am wondering if what you've tried was successful.  

0 Kudos
Message 10 of 11
(5,322 Views)