12-08-2022 04:28 PM - edited 12-08-2022 04:30 PM
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:
Possible Problems:
Am I missing anything else?
Cross-posted on LAVAG
Solved! Go to Solution.
12-08-2022 09:46 PM
I am not sure if my idea is feasible, anyway here is how I would approach it,
All the above works if the DLL is loaded into a different application instance.
12-08-2022 10:22 PM
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.
12-08-2022 10:58 PM
If there is no alias, how does the DLL know which instrument to control, does it randomly control?
12-08-2022 11:17 PM
@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.
12-09-2022 10:29 AM
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.
12-09-2022 11:00 AM - edited 12-09-2022 11:00 AM
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.
12-09-2022 12:07 PM
@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.
12-09-2022 01:13 PM
Interesting and weird for such a long-time instrument manufacturer to create such a driver.