Dynamically Copy, Rename, and Use a DLL

[mcduff]

This is a somewhat out of the box idea and want to bounce it off people to see if there are any issues. (It would take some time to test, so I want to check if anyone has done anything similar.)

I am trying to write a program that controls a TEK RSA507A. It has a DLL API that can interface with LabVIEW.

The main problem is that the DLL does not support multiple instruments running at the same time; that it, there is no handle/address analogous to a VISA Address. 

On this site it says "In order to communicate with multiple RSA’s simultaneously you will need to call multiple instances of the RSA API. The API will need to be called for each RSA. "

I assume that means if I have name the DLL differently for each instance, then I can call multiple instruments.

Idea:

1. When EXE opens, detect the number of instruments, then copy and rename the RSA.DLL in a temporary folder, e.g., RSA_1.dll, etc.
2. Use the temporary DLLs to call functions for each instrument.

Possible Problems:

1. These DLLs call other DLLs, do not know if there will be any data corruption when that happens. I cannot rename the other DLLs.
2. Will Windows let me copy and use a new DLL? Is that some kind of security problem?

Am I missing anything else?

Cross posted here

Edited December 8, 2022 by mcduff

[ShaunR]

Hmmm. This seems just plain wrong (on so many levels).

The Tektronicss RSA API has the following two functions

DEVICE_SearchInt
DEVICE_Connect

Which would suggest it can quite happily support multiple devices.

Interesting though. I didn't see a "Close" or "Disconnect" function in the examples (I don't have the actual driver to check).

Edited December 10, 2022 by ShaunR

[mcduff]

Yes, it has both of those functions and a device disconnect also. 

The Device Connect specifies a particular instrument. All other calls have no specifiers, even Device Disconnect. The API kind of stinks. My guess is, you specify an instrument in the beginning and that is it; everything else defaults to that instrument.

EDIT: These functions are using the RSA.DLL

Edited December 10, 2022 by mcduff
More Info

[ShaunR]

The Disconnect can take a device ID (according to the matlab example). However. this little gem was in the python:

note: the API can only currently access one at a time

I would expect better from them (intern?). Their proprietary software supports multiple devices so its just what they are supplying with the RSA API.

All their GPIB and Ethernet devices are SCPI compliant so I wouldn't be surprised if it was just SCPI over USB with Bulk transfers for IQ data streaming. But considering the state of the API, you never know. You'd need the programmers reference.

 

Edited December 11, 2022 by ShaunR

[drjdpowell]

Just to second ShawnR's suggestion to look for documentation on the underlying communication protocol.  Multiple times I have found poor quality LabVIEW libraries just use better quality communication protocols underneath, and I just implement that protocol with my own library.

[JCAndersen]

Yes, like drjdpowell says, you will find that the LabVIEW API provided by many instrument manufactures have been made on a Monday morning by an intern, just be be able to state in the marketing material that they have a LabVIEW driver. I have re-written many of those for scratch using the programmer guide and SCPI commands.

[ShaunR]

The caveat here though is that USB is not an easy interface even in LabVIEW. I've heard that many people decide to make a MAX configuration instead of USB driver because it's just so damned low level and does anyone remember the difficulties with webcams?

I use libusb and a 3rd party wrapper for the RTL-SDR which is not only far easier but much faster. A wrapper and DLL driver is probably a must for asynchronous callbacks -  it's not for the faint-at-heart. The only time a USB device is easy is when it presents itself as a COM port which I very much doubt for streaming high speed IQ data.

[mcduff]

TEK did not make a LabVIEW API. I used the DLL import wizard along with the RSA DLL. Not sure what API Matlab is using but below is a screenshot from the programming manual; no device ID for a disconnect. These are the functions exposed in their DLL.

This Spectrum Analyzer has its own DLL and it can continuously stream data up to 56MB/s; as ShaunR said, this type of streaming is not well suited for a COM port.

This device is not using SCPI  commands with their provided DLL. However, it can use SCPI commands if you install their software (Signal Vu) and make a virtual VISA Port. But if you do that, then no high speed streaming which is needed for this application.

[ShaunR]

6 hours ago, mcduff said:

TEK did not make a LabVIEW API. I used the DLL import wizard along with the RSA DLL.

Interesting. I assumed you used the TEK one here.

It looks very much like the whole API is a "work in progress" as many functions are not supported and...

Quote

- When Connect and Disconnect procedure is repeatedly run for extended time duration (> 2 hours), segmentation fault is observed.

Do they distribute the DLL source code as part of an SDK?

[mcduff]

2 hours ago, ShaunR said:

Interesting. I assumed you used the TEK one here.

It looks very much like the whole API is a "work in progress" as many functions are not supported and...

Do they distribute the DLL source code as part of an SDK?

Their "LabVIEW distribution" is nothing more than using the DLL import function for the RSA.DLL.

I have not looked at the other sources on the GitHub page; not sure if the source code for the DLL is included on that site or not. I have only downloaded the DLLs.

[Rolf Kalbermatter]

1 hour ago, mcduff said:

I have not looked at the other sources on the GitHub page; not sure if the source code for the DLL is included on that site or not. I have only downloaded the DLLs.

It is not! All the language interfaces they have on that page are simply wrappers around the DLL. Some more complete than others. The C# one seems to import all the functions (well at least a lot), the LabVIEW wrapper is extremely minimalistic.