TL;DR: Does LabVIEW need a setting to allow one DLL to load another DLL?
I have successfully used Call Library to load our C++ DLL (dacq.dll) into a VI to send text commands and scripts to our data acquisition system. It loads, I pass strings into it, it controls the hardware, and I can acquire and display data.
But I can't get dacq.dll to load a second DLL when run from LabVIEW. We have an optional post-processing function that we call by passing this command into dacq.dll:
POSTPROCESS C:\LABVIEW\NUC.INI
NUC.ini contains another script such as:
Function1 =TwoPtNUC|functions.dll
which instructs dacq.dll to load functions.dll and call TwoPtNUC().
I know the scripts are syntactically correct, because I can run it out of a C++ terminal-like application that we wrote, and it runs correctly. After dacq.dll does its job, it calls functions.dll, which performs the image correction.
When I run the exact same text scripts from LabVIEW, the second DLL call fails.
dacq.dll echoes inputs and errors to the Windows Debug stream, and I've logged the sequence of events when sending the scripts from the C++ app and from LabVIEW. The sequences are identical up until the very last call to functions.dll, where the sequence from our C++ app succeeds but our LabVIEW fails.
I am not loading functions.dll via a Call Library function; dacq.dll is supposed to take care of that. LabVIEW only knows about dacq.dll, and that part is working fine, as evidenced by the fact that it will set up the data acquisition system and acquire data.
Is there a setting, or permission, or allocation that I need to make (or ask LabVIEW to make) to allow dacq.dll to load functions.dll? I have put the complete path to functions.dll in my PATH environment variables, but that didn't fix the problem. I wasn't expecting it to, since functions.dll lives in a subdir of where dacq.dll lives.
Any suggestions?
Thanks!
