Multithreading in C# .NET 3.5 for synchronous sample Acq. & simultaneous processing

[Williamx]

Hi, referring to a post in 10/07, "Do back-to-back EndReadMultiSample and BeginReadMultiSample calls give a continuous sample stream?" I wanted to take the discussion a bit further and get a sanity check before diving in head first extending this approach for my application.

My objective is to execute the following procedure:

1) Read multiple samples from two AI's as fast & uniformly in time as possible by initiating the acquisition with the BeginReadMultiSample method.

2) When 1 seconds worth of samples are in the USB-6009 buffer, I'll execute the EndReadMultiSample method and likely transfer the buffer contents to a 2D array so that I can process each channel's samples separately and then write a "record" of values to a grid and also to .CSV file.

3) Check to see if the duration of acquiring and processing samples has ended. If ended terminate sampling, if not ended then goto 1).

My question is although more complicated, wouldn't using a thread for the acquisition process and another thread for the processing (and maybe a third thread for the data display & logging) be necessary to achieve the fastest sample rate while maintaining time-uniform sampling?

There isn't a specific sample rate that is required, it's determined by the capabilities of the USB-6009, good utilization of C#, OS resources and the operations being executed.

Does this seem like I'm heading down a reasonable path, or are there some gotcha's I've overlooked?

Thanks,
Bill

[AndrewMc · Accepted solution]

There is actually a shipping example that does almost exactly what you are talking about (in <public (all users) documents>\National Instruments\NI-DAQ\Examples\DotNetxx\Analog In\Measure Voltage\ContAcqVoltqageSamples_IntClk_ToFile).

It registers a callback to be fired every x samples.  Inside of this callback, it writes the data to file and displays it on a graph.

As far as performance considerations, note that DAQ already has an internal buffer that is used; therefore, an additional buffer would only be advantageous in parallelizing the actions of transferring data from the DAQ internal buffer and processing/logging that data.  At extremely fast rates (for example, 1 MS/s+), this kind of optimization would be necessary; however, for most DAQ applications, this optimization would not be necessary since the time spent copying the data from the internal DAQ buffer is not substantial.  Since you are using a USB-6009, I'm pretty sure you won't need the additional thread, so it might be more trouble than it's worth. 

I would recommend that you start with the shipping example and modify it to add whatever processing you need; then, if the performance is not enough (that is, you get an exception indicating that you are attempting to read invalid samples), then go and try to optimize by adding another thread (and queue of some sort).

[Williamx]

Andy,

That's excellant to hear that you've already gotten close to what I need! Thanks so much for that good news and your prompt reply.

Bill