Do you use NIDAQ Tools MX?
johnweeks
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.
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
August 26, 2016 at 09:56 am - Permalink
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).
August 26, 2016 at 12:04 pm - Permalink
August 29, 2016 at 07:45 am - Permalink
August 30, 2016 at 06:50 am - Permalink