I'm developing an application in MS Visual Studio 2005 C++ using the DAQmx drivers and .NET support classes. The application requires CONTINUOUS long -term (weeks) acquisition from multiple AI channels with some background processing. Samples rates are in the 100 to 1kHz range. The NI DAQ device is a NI USB-6210.
I know I can start continuous acquisition using a BeginReadMultiSample(-1, ...call and then create a Windows Timer class with a periodic callback containing a ReadMultiSample call to 'harvest' the samples that have arrived since the last time through the callback and pass them back for processing. Using this approach I know that the samples are contiguous and I won't get overruns as long as execute the callback sufficiently frequently. The downside is that the number of samples returned varies around the number expected as the Timer callback isn't synchronous with the DAQ activity.
The approach taken in NI's continuous acquisition examples in C++ is to set up a callback synchronous with the DAQ that is entered when the desired number of samples 'n' have been acquired by using BeginReadMultiSample(n,.... You then use EndReadMultiSample in the callback to read the data acquired. For continuous acquisition another call to BeginReadMultiSample(n, is made in the callback so the callback is executed again when the next 'n' samples have been acquired. However does this method guarantee that the samples returned will be contiguous across the calls, i.e. do the DAQ AI conversions continue until the task is stopped or destroyed independent of the End/BeginReadMultiSample calls or does the EndReadMultiSample actually stop the DAQ AI conversions and then the BeginReadMultiSample call restart them? If the latter is the case then surely the samples returned wouldn't be really continuous (contiguous).
Any help or pointers to information you can give me clarifying the operation of the End/BeginReadMultiSample calls in the above manner would be really apreciated.
Regards,
Malcolm Sharp