How does USB-6210 handle overruns?

[grdetil]

I've gotten my USB-6210 multifunction DAQ device working using both DAQmx Base 3.4.0 under Scientific Linux 5.5, and the full DAQmx version 9.3.0f2 under Windows.  It seems to be working well (though slow to start up under Linux), but I can't seem to figure out whether it's handling buffer overruns the way I want.  DAQmx Base doesn't provide any means of checking or setting the overrun behavior, and I can't find any informaiton that says what the default is.  As for the full DAQmx library, there are functions in 9.3.0 for setting and reseting the behavior, but the documentation says nothing about what the default is.

I thought to be on the safe side, at least under Windows, I'd put a call in my C code to set the behavior to stop the task and give an error message.  So, I added this call, just before I call DAQmxBaseStartTask():

    ret = DAQmxBaseSetSampClkOverrunBehavior(thandle, DAQmx_Val_StopTaskAndError);

The thing is it returns error code -200452 (DAQmxErrorAttributeNotSupportedInTaskContext), which gives this error message:

Specified property is not supported by the device or is not applicable to the task.
Property: DAQmx_SampClk_OverrunBehavior

Task Name: _unnamedTask<2>

Status Code: -200452

So it seems the USB-6210 doesn't support setting this property.  I even tried explicitly setting DAQmx_Val_IgnoreOverruns instead and get the same error.  I don't get any error messages even when running the device at full speed with a lot of other activity on the system, so how do I know it's not actually getting buffer overruns, ignoring them, and silently discarding samples.  That would be very undesirable behavior in a production environment in our field (electrophysiology in neuroscience research).  But unless I can catch it in the act and show that it is indeed dropping samples, or better yet get a satisfactorily assuring confirmation that it's NOT doing that, then there's a big unknown hanging over my head as to the suitability of this device for our application.

Can I get some advice from the engineers about this matter?

Thanks,

Gilles

[bstreiff]

The DAQmx_SampClk_OverrunBehavior property is only applicable to output tasks. If you're doing an AI task that would be the reason why the error is thrown.

I believe you may actually be referring to buffer overflows; those will cause the task to stop with an error (in most cases, -200010) by default.

[grdetil]

OK, thanks.  I'm new to NI products and therefore to its terminology.  (Other manufacturers talk about overruns on input and underruns on output.)  So I take it that no news is good news as far as the lack of error messages even when the system is busy?  I.e. the buffering (either on the device or in the driver and/or library) is adequate enough not to lose samples, or I'd hear about it by default?  I do check the return value of DAQmxBaseReadAnalogF64 or DAQmxReadBinaryI16 after each call, which I assume is the one that would report the overflow if it happens.

Gilles