Do back-to-back EndReadMultiSample and BeginReadMultiSample calls give a continuous sample stream?

[MalcolmSharp50]

I'm developing an application in MS Visual Studio 2005 C# on XP using the current DAQmx drivers and .NET support classes. The application requires CONTINUOUS long -term (weeks) acquisition from multiple AI channels coupled 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 then pass them back for processing. Using this approach I know that the samples are continuous and I won't get overruns as long as execute the callback sufficiently frequently. The downside is that the number of samples returned varies 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 before it exits so the callback is executed again when the next 'n' samples have been acquired. My question is does this method guarantee that the samples returned will be continuous across the calls, i.e. do the DAQ AI conversions continue independent of the End/BeginReadMultiSample calls (until the DAQmx task is stopped or destroyed) 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 all samples returned wouldn't necessarily be continuous (i.e. equally spaced in time).

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 

[JonBowers]

Hi Malcolm,

You needn't worry about the DAQ device continously aquiring data. it is always aquiring data at the rate you specify then transfering it to the buffer. What the Begin/EndReadMultipleSample functions are doing is starting and finishing an asynchronous read operation. This is just to do with how DAQmx transfers data from the buffer into your application not how the card aquires the data initialy. You have to start a new asynchronous operation for each read you make in this way so thats why the begin is called multiple times.

I hope this explains it.

Regards

Jon B
Applications Engineer
NI UK & Ireland

[MalcolmSharp50]

Jon,

Thanks for the clarification. I 'kind of thought' this was the way it worked, with the calls managing asynchronous transfers of data to my application from some other buffer being continuously filled by the DAQ. It just wasn't stated explicitly in the documentation, at least any that I had read!

Thanks and regards,

Malcolm Sharp 

[JonathanN]

Hi Malcolm,

We are always looking to improve documentation and so I wanted to ask you a couple of questions.

1) Are you a new user to DAQ?

2) What documentation did you look through? Was it the NI-DAQmx Help or the NI-DAQmx .NET Framework 2.0 Help?

3) If you looked through the NI-DAQmx .NET Framework Help, did you expect fundamentals of DAQ to be located there? Currently the concepts of DAQ are discussed in the NI-DAQmx Help.  On that same note, did you take a look at the Asynchronously Reading and Writing with the NI-DAQmx .NET Class Library help topic?

Any information would be helpuful.

Thanks and Best Regards,

[MalcolmSharp50]

Jonathan,

In answer to your questions.

1) I guess I've 30+ years experience in data acquisition using computing systems controlling ADC equipment of all types. I'm a user of National Instruments boards and LabVIEW for a couple of years but in trivial applications. I've 5+ years programming in .NET and C# for industrial/scientific applications but a completely new user to programming applications using DAQmx in a .NET environment.

2) I read both the relevent sections of both the NI-DAQmx Help, the NI-DAQmx .NET Framework 2.0 Help and tried out a couple of the NI supplied code examples.

3) I particularly concentrated on the section Asynchronously Reading and Writing with the NI-DAQmx .NET Class Library and that confirmed my understanding of the use of callbacks (why don't Microsoft call them 'completion routines' like everyone else?) and thread safety. I actually had the code written and running correctly before I asked the original question. The question was more to gain a comfort level that the Begin/EndReadMultiSample and async callback mechanism was dealing with requesting async reads from an continuously filled internal circular buffer managed by DAQmx itself. The presence of this internal buffer is implied in the descriptions of the methods to change the default buffer sizes and the handling of data overwrites but I needed that extra confirmation that this was indeed the case. 

Maybe a block diagram showing the levels of abstraction in the data flow from the actual hardware through internal buffering to the .NET interface itself might have made it all gel a bit quicker for me. Another block diagram showing the functional areas of the various classes involved with getting at MAX global channel properties, setting up the DAQ and reading the data might be a bit clearer as I had a bit of a learning curve to climb here too. The information is all in the various namespaces and .NET help; it's just that for me personally a diagrammatic 'roadmap' allows me to visualize things quicker!

Despite the above comments I have to say that the DAQmx interface, the supporting documentation and forums etc. is by far the best I have ever used for application development in the real-time data acqusiition area. NI's long-term support of a solid and well documented common DAQmx .NET interface to all its hardware products was more of a deciding factor in our company's decision to buy NI hardware than the actual capbilities and range of  the hardware itself.  There's no getting around the fact that for a first-time user of managed code, threads and callback in .NET and DAQmx the learning curve is going to be steep. The NI documentation does contain all the information on the DAQmx functionality, nicely integrated into the development environment. Maybe all that's need for users like me is a couple more 'integrating overviews' of the operation and structure.

Thanks and regards,

Malcolm