Thread-safe version of VDT2 XOP

In the threadsafe version, does VDTOperationsPort2 set the port for the thread, so that each thread can operate on its own port?

That should be a great improvement.

Quote:

In the threadsafe version, does VDTOperationsPort2 set the port for the thread, so that each thread can operate on its own port?

No and you have a good point.

The main goal of making VDT2 threadsafe was so that you could do data acquisition in a thread. We did not give much (OK, any:) thought to multiple threads doing independent data acquistion. I suspect that this multiple thread scenario is rare. You can do data acquisition using multiple ports using one background thread though.

To support multiple threads doing independent data acquistion would require something that I have had in the back of my mind for a couple of decades - to add a /PORT flag to each VDT2 operation (VDTRead2, VDTReadBinary2, VDTReadWave2, VDTReadBinaryWave2, ...) so you can specify the port for that operation without using VDTOperationsPort2.

That would be a fair amount of work for, I suspect, a very small audience, but I am interested to know your thoughts.

You could use the VISA XOP for the multiple independent background thread application. The downside to the VISA XOP is that it requires the end user to install the VISA library.

I would greatly welcome the /PORT flag, it makes so much sense when acquiring data from multiple instruments. In my case, control of a HPLC setup, I need to communicate with 5 different instruments, possibly 10 if I tried to control two setups at once. Additionally, there is one instrument I cannot interrogate, it just emits data at its own rate; I would like to average its output to synchronise it with the rest of the data acquisition, which I think would be easier using an independent thread. Luckily, HPLC is a slow-paced environment so I will probably be able to do everything in a single background function and just use two instances of Igor to control 2 setups simultaneously. BTW, my Igor-based software replaces commercial software that costs about 6k initially and maybe 1k in maintenance per year (and, yay, that's per setup - called "time base" in HPLC jargon).

Asynchronous data acquisition from serial instruments whose response times can vary a lot would be a great thing. At the moment you're limited to a round robin approach where the sum of all instrument latencies is imposed upon each instrument. Actually, if you're careful you could stagger the writes and reads to speed things up a bit (assuming that the instruments use query-and-response-based communications). If you can figure out how to get multiple Igor instances to each control a port that could be interesting.

I think the port flag was added back in 2020. The help has

> The /P=portName flag for VDTWriteWave2 was added in VDT2 version 3.00, shipped with Igor Pro 8.05.

and IIRC we also use the VDT2 XOP in preemptive threads to concurrently talk to hardware.

And this is why I love this forum - thanks for your pointers to later Igor versions, I had totally overlooked this. I am at present stuck with IP7, but that's now bound to change. Interestingly, I can find neither a download link nor a blog/news section referring to version 8.05. There is however mention of the VDT2 port flag as a significant XOP change in IP 9:

https://www.wavemetrics.com/products/igorpro/newfeatures/whatsnew9

thomas_braun wrote:

the port flag was added back in 2020.

Oh, I completely missed this. Data collection in preemptive threads is the answer.

 I don't follow the VDT developments as closely as I used to back in the days when I didn't have technical support for data acquisition.

wharneit wrote:

And this is why I love this forum - thanks for your pointers to later Igor versions, I had totally overlooked this. I am at present stuck with IP7, but that's now bound to change. Interestingly, I can find neither a download link nor a blog/news section referring to version 8.05.

The last official release of Igor Pro 8 is 8.04, however the latest application available from the nightly build is 8.05. We never released installers for 8.05 because we dropped maintenance of Igor Pro 8 after we released Igor Pro 9.