Oh well, I have another thread here where I wrote many things about what we have done at Omnimetra using NAT boards.
The board being used is the 6220M.
We run up to four aquisitions at the same time, 8 channels (voltage and current each one).
The acquisition and data display (graphically) is real time.
And we use a callback for the AI read running at fixed 30KHz.
By the way... the callbacks in Traditional are much more efficient, faster and without the thread troubles.
Start and Stop can happen from the main thread (usually a user button click) as also from other threads running in real time to stop automatically or when aborting a script (that also runs in a thread of course).
Thus, the point is that we had a bad surprise (one more... using the nidamx) for porting our software from the Traditional to the nidaqmx when we got the error telling that the thread must start, stop, clear or unreserve from the same thread the event callback was registered.
Also, the very cumbersome problem here is that the AI task needs to be stopped, cleared and recreated sometimes, because of GAIN changes the user can input in our software interface.
Using 8 channels with 4 possible input ranges (or gains) each... it is not feasible to create so many tasks in advanced to avoid the recreation in realtime.
The documentation is not very useful when talking about the methods of synchronization of the callbacks and how to start/stop them when using several threads. In fact, it says NOTHING.
And as I wrote, it only accepts a zero as the parameter, that the doc says the callback will run on a NAT thread and not in a program thread.
But things do not seem to work as the doc says, because I tested and the task can be stopped from inside the callback.... although as the doc says, the callback calling thread is not the one that created and registered the callback AI task (it is usually the main program thread). There is something wrong in all this stuff.
Ok, I can do more programming trickies to fool or bypass the many troubles and difficulties the nidaqmx creates.
After using the Traditional for so many years without problems, I can say I really dislike very much the nidaqmx.
Anyway, if you say the device (6220M) is not capable to work using synchronous callbacks, I wonder if there are real advantages to change the Traditional (6023E) for the nidaqmx (6220M) for demanding real time applications.
🙂