Do you use NIDAQ Tools MX?

I am now in the process of creating the next version of NIDAQ Tools MX. If you use NIDAQ Tools MX, you can influence this new version.

One of the things I would like to do with this next version is to add multi-threading. I can see a few different ways it could be done, and I would be interested in any info you might offer as to how you would use such a capability, or if you would use it at all.

1) Have the acquisition occur in a thread transparently to you. Your data would magically appear in Igor when the acquisition was finished. During acquisition, Igor's main thread and user interface would work as if nothing else was happening.

2) Have the acquisition occur in a thread transparently to you, with the NIDAQ Tools MX XOP transferring data from that thread to your waves periodically.

This option would not change how you use NIDAQ Tools MX much- it would be just like using DAQmx_Scan/BKG=1, but the acquisition work would happen on a different processor, possibly leaving Igor's main thread more responsive.

3) Make Igor thread-safe versions of the operations like DAQmx_Scan and related functions. That would allow you to write a thread-safe user-defined function that could do acquisition and computations on the result of acquisitions in Igor preemptive threads using the techniques in DisplayHelpTopic "ThreadSafe Functions and Multitasking".

This would allow you to do all your acquisition and analysis of acquired data in the background, on a separate processor. You might do this to keep Igor's main thread responsive, or you might do this to get greater performance by doing two acquisitions and associated computation in parallel on separate processors. Note that you would need two separate DAQ devices to do two simultaneous scans in two different threads.

This technique would apply only to operations that use waves; the FIFO options could not be used as Igor's FIFO's are not threadsafe.

4) ??? Have I missed some technique that you would like me to consider?

In addition to your feedback on the threaded data acquisition question, I will entertain other ideas for improvements to NIDAQ Tools MX.
I planned to replace some monstrous controlling / acquisition LabVIEW project by Igor/ NIDAQ Tools MX code. However, there was no time to realize that (yet?).
But I had some thoughts already and can comment a little:
A typical measurement comprised up to 8e6 SP data points in each of 2 channels at a sample rate of 1kHz (acquisition time ~2.5h; 61 MB) with several smaller measurements in one experiment.
It would be nice to evaluated the data simultaneously to the acquisition and see the progress of the experiment.

Hence, I would NOT prefer option 1. It is nice for small, short measurements but gets impractical on large data sets. (Restarting the acquisition might cause too much overhead.) It might also be appropriate for sequential measurements: e.g. increase U1 by 0.1V, measure a spectrum, and repeat.

Options 2) and 3) would both fit 'my' needs. Version 2) might be more user friendly, 3) more versatile.
In case 2) makes it into the code, I would appreciate a parameter to adjust the 'transfer periodicity' (this might allow for improved synchronization of retrieval and evaluation of data).

HJ
Thanks for opening up the development of the next version of NIDAQ Tools MX to discussion. We use NIDAQ devices regularly, and are looking to expand support in our Igor based software for their use.

Generally speaking, I think that hardware communication should be threadsafe.

Regarding the specific options listed above, I would say that option 1 would be the minimum requirement. Option 2 is better still. Option 3 is what we really want because we'd like to be able to push and pull data to/from the hardware and visualize the data as it is coming off the device. It is critical that the code that interacts with the hardware can do so independently of Igor's main thread. An additional argument for option 3 is also that this allows us to analyze/massage the data before displaying it while keeping everything responsive (across multiple NIDAQ devices).
I am not sure this comment i relevant for the discussion, but keep in mind that many experimental situations require simultaneous image acquisition using separate camera software running concurrently with Igor acquiring data through the NIDAQ Tools MX. We for example acquire image streams using an Andor camera controlled by SOLIS software while Igor is acquiring data at the same time.
Please consider circumstances where the waves (4) are being generated and scanned at fast (e.g. 50kHz) repetition rates, each followed by a Repeat Hook function. I don't know enough about multi-threading to understand the merits of your options, but the first seems easiest for us to use our present code with the least modification.