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 on LAVAG

[santo_13]

I am not sure if my idea is feasible, anyway here is how I would approach it,

1. Create a wrapper application that calls the DLL
2. This wrapper application will translate TCP to a DLL call
3. Wrapper application is initialized by your top-level application for every TEK instrument passing in the TCP port and the instrument alias that it has to control
4. Send TCP commands (you can implement them based on your needs) to the wrapper application which in turn controls the instrument

All the above works if the DLL is loaded into a different application instance.

[mcduff]

Would you each instrument call its own wrapper application?

The problem with the TEK supplied DLL is that there is no instrument alias; so calls to it go to all instruments, or you can only connect to one instrument at a time.

So my idea is keep a copy of the DLL in the application, make a temp copy of that DLL with a new name, and call that DLL by specifying the path. Obviously, if the temp DLL gets deleted then you have problems. Other than some Windows security setting, my main concern is that the DLL calls helper DLLs. I do not know what would happen if multiple DLLs call the same helper DLLs.

I think your idea would work also, but it's more work to implement.

[santo_13]

If there is no alias, how does the DLL know which instrument to control, does it randomly control?

[altenbach · Accepted solution]

---

@mcduff wrote:
So my idea is keep a copy of the DLL in the application, make a temp copy of that DLL with a new name, and call that DLL by specifying the path.

That's exactly what I do here. My fortran dll cannot run multiple instances, so when the program starts up, it will create N (matched to the number of CPU cores) unique copies in %TEMP%, then call them using the parallel instance ID by name. Works great!

Sorry, posting by phone. Can show some template code later. I even use a conditional disable structure to select 32 or 64 bit dll version, depending on LabVIEW bitness.

[mcduff]

Thanks! I thought it was possible, just wanted to confirm. My biggest concern is the helper DLLs the main DLL calls. Everything is supplied from TEK, so no changes possible. I will see if my end user can live with the possibility of cross talk between DLLs. Although TEK seems to imply this is not an issue.

[altenbach]

Just FYI, here's a simplified version of the code I use. The master DLLs (32bit&64bit) are located in the data folder of the built application (and same relative path in the dev environment, of course). Paths are cached in a feedback node for further calls. The P terminal of the FOR loop needs to be configured to output the parallel instance ID.

[mcduff]

---

@santo_13 wrote:

If there is no alias, how does the DLL know which instrument to control, does it randomly control?

---

There is a Device Connect that 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.

[santo_13]

Interesting and weird for such a long-time instrument manufacturer to create such a driver.