creating a new thread for AO

[densmore]

In the example GenMultVoltUpdates_IntClk, the AO task is started in a new thread. But the BeginWriteMultiSample method that is used is a asynchronous write, What would be the advantage of creating a new thread for the AO? Thanks

JMD

[bilalD]

Hello

Im looking at the example and it uses WriteMultiSample() instead of the asynchronous version BeginWriteMultiSample(). This example uses WriteMultiSample() and then waits for the operation to complete (myTask.WaitUntilDone(10000);) , which is why a thread is spawned to avoid hanging the UI. If you do use the equivalent async function, you really do not get any additional benefit of spawning another thread and completing the operation there.

I have NI-DAQ 7.3 installed on my machine.

Hope this helps

Bilal Durrani
NI

[Chris_W1]

JMD:

When you call a synchronous, or blocking, write call like WriteMultiSample, the call returns when the samples have correctly been written to the device buffer (if the task uses any timing type other than on-demand). However, the device may or may not have yet generated these samples on the physical output line(s). This similar to what happens with an asynchronous call like BeginWriteMultiSample--your callback is executed when the samples have been transferred to the device, not necessarily after the output operation has actually happened. You can guarantee that the device has actually generated all the samples written to it by calling Task.WaitUntilDone. This behavior is the same in all DAQmx APIs.

So now let's talk about what that means for this particular example.

In this example, we want to create a Task, write some values, and then destroy the task. The example calls WaitUntilDone to ensure that all the samples are actually generated before destroying the task. Because WaitUntilDone blocks, the example calls it from a second thread to keep the UI responsive during the DAQmx operation. Were we to use the asynchronous I/O call BeginWriteMultiSample, we would still need to call WaitUntilDone inside the callback, which would freeze the application (assuming that we've set SynchronizingObject to the Form), keeping the UI from being refreshed until the DAQmx operation completed. If you choose to not use SynchronizingObject, you should be able to implement this fine with asynchronous calls, but in that case your callback is being called inside a driver thread rather than the UI thread, and it's not safe to do some things, such as directly access Windows Forms controls that were created in the UI thread. For this reason, all the MStudio examples use SynchronizingObject by convention, which requires us to use a second thread in this example rather than asynchronous I/O.

Hope this answers your question. It looks like our documentation for the Write methods could use some elaboration, so I'll go ahead and fix that. Thanks for bringing this up, JMD.

Chris
.NET DAQmx Team