6115 memory underflow -200016

[bkast]

Greetings,

I am working on an application with a DO channel at 10Ms on a PCI-6115.  The application works fine for a minute or so and then generates a -200016 memory underflow error.

Platform: P4-1.7Ghz, Win XP, MSVC6, DAQ 7.4.1f4,  DAQmx 8.0.1f0

Is there anything I can do to reduce the likelihood of the underflow error?

Thanks,

Brian

[Thaison_V]

Hi Brian,

Underflow errors a function of a few things.  As the error description says, it is because the DAQ card outputs its data out of the onboard FIFO faster than your PC fills this buffer with data.  This can be because the PC is too busy doing other things to keep up (whether it's Windows that is too slow, or if you are doing too much processing of the data in your loop before calling DAQmx Write), the amount of data written per "DAQmx Write" call is too small, or it's possible your PC's processor is just not keeping up with the speed that the card is writing at.  10 MS/s is a very fast rate, so the PC must be writing to the 6115's onboard FIFO at that rate or faster to keep up.  You can also have the board loop the same data off its FIFO so that you don't have to continuously update the points from the PC (called Regeneration mode).  You should be able to do this in the DAQmx C API using the DAQmxSetDOUseOnlyOnBrdMem function.  Let us know if this helps!

Thaison V
Applications Engineer
National Instruments

[bkast]

Thanks for the response,

At 10MHz the 2k FIFO does need a LOT of attention. (Can I write to it explicitly?) The PC is not doing much and the app can run for a minute or so before throwing the error. The data is an information stream, regeneration is not an option. The large onboard memory looks very attractive and the text associated with the DAQmxSetDOUseOnlyOnBrdMem function hints that it may not be impossible to use it, but fresh data is required. Any ideas? Otherwise, I might be looking for another board.

Brian

[Thaison_V]

Hi Brian,

This might depend on how you are implementing your digital writes, but I am guessing your application is similar to the shipping example located in C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Digital\Generate Values\Cont Write Dig Port-Ext Clk .  When you write multiple samples with the DAQmxWrite function, you actually are writing to the on-board FIFO explicitly.  The buffer starts queuing up the samples if you perform additional DAQmxWrite calls before the DAQ card actually uses those samples for output.  So really, to use the large FIFO on the board, you need to perform your DAQmxWrite calls fast enough to keep up with the card, or you could increase the number of samples you are actually sending with each DAQmxWrite call.  In the example I mentioned above, this can be done by simply making the "data" array longer.  The example currently has an array of 8, so you can add more values to this array to "queue up" in the array, and then specifiy the number of samples in the numSampsPerChan parameter.  Let us know if you are having trouble with this though!

Thaison V
Application Engineer
National Instruments

[bkast]

Hi,

Thanks again for following up on this. To get the 10MHz clock, I built up from the example in: C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Synchronization\Multi-Function\ContAI-Read Dig Chan. The app is using DAQmxWriteDigitalU8, but with a many-MB buffer. Code behavior seems to indicate that large writes are occurring. My understanding was that these were going into a buffer in the DAQmx driver SW and transferred down to the 2k FIFO as needed. (Not true?) I tried constantly filling the buffer (instead of using the EveryNCallback). The bytes written indicated that the buffer was staying full, but the 200016 error still popped up with about the same frequency (100-1500M samples).

Is there anything I can do to isolate the issue?

Brian

[Thaison_V]

Hi Brian,

Sorry about the confusion.  I should be clear in saying that there are two properties we are dealing with: 1.) Regeneration and 2.) the memory used.  Having regeneration on will loop the data in the buffer.  The memory used determines where your buffer resides (PC memory or on-board memory).  You are correct in that you are writing to a software buffer that gets transferred down to the on-board FIFO (which is the default behavior), but the behavior I described of writing directly to the FIFO can be achieved by using the DAQmxSetDOUseOnlyOnBrdMem property.  What in particular were you looking at that indicates to you that this property won't allow you to use this?  If you set up your task to only use the on-board memory, while having regeneration turned off, you will be writing "fresh" data to the on-board FIFO as it is outputting, but if you write data to this FIFO faster than you are outputting, the data will be queued up until the hardware clocks it out.  Even with all this in mind, the 6115 is only spec'd to output at rates of 4 MS/s (http://digital.ni.com/manuals.nsf/websearch/5F6C3C3E7B29A28386256FAB005FDE3E), albeit this is system dependent.  10 MS/s may be out of its range even with all of the tweaks we have discussed.  Let us know if this helps clear things up though.

Thaison V
Applications Engineer
National Instruments

[bkast]

Thaison,

The comment in NIDAQmx.h:  

"#define DAQmx_DO_UseOnlyOnBrdMem      0x2265     // Specifies whether to write samples directly to the onboard memory of the device, bypassing the memory buffer. Generally, you cannot update onboard memory after you start the task. Onboard memory includes data FIFOs.”

discouraged me from taking that route, but I will give it a try.  

Thanks,

Brian

[bkast]

Oh well,

Error Text:

Operation failed, because an attempt was made to use only the onboard memory for generation when regeneration of data was not allowed.

Set the Regeneration Mode property to Allow Regeneration or set the Use Only Onboard Memory property to false.
Task Name: _unnamedTask<1>  Status Code: -200656

It looks like I'm going to have to try a 6534.

Thanks anyway,

Brian

[bkast]

It works!

Apparently my buffers were too large. Using a 4MS buffer and 100kS writes without the EveryNSample callback, 10Mhz is sustainable.

Thanks for the help

[Azazel]

Hello bkast,


I am trying to code a very similar application (stream at DAQ card limit) as the one you have succeded at using the PCI-6115, but instead of using a binary read I am using analog.  Could you post a jpg of your code you got working or can you post your code so I have something to work off of?

Thanks,

Azazel

Message Edited by Azazel on 08-28-2006 02:25 PM