Call Library Function Node wildcard doesn't seem to work

[Gregory]

I'm using the Call Library Function Node to call a DLL in LV 2016. I'd like to be able to use 32-bit or 64-bit LabVIEW, and I have put the corresponding DLLs named USB30_DLL32.dll and USB30_DLL64.dll in the same folder as my VIs. 

My understanding is that I can specify the name as "C:\My Folder\USB30_DLL*.dll" and the * will automatically change to 32 or 64 based on the bitness of my LabVIEW. When I change the 32-bit path to the wildcard it seems to work fine. But when I change the 64-bit path to the wildcard it breaks the VI and says the library cannot be found.

32-bit: no problem

64-bit: breaks the VI

[raphschru]

Hi Gregory,

The documentation is not very clear.

It says the wildcard to the left of the extension is replaced by either "32" or "64" depending on the bitness of the platform (i.e. your OS), but says nothing about the bitness of the application (i.e. LabVIEW.exe or your own executable).

Have you tried USB30_DLL*.* to match exactly the given example?

Regards,

Raphaël.

[Kyle97330]

Is using the "Specify path on diagram" option something you can do?  Then you could just put the path into a conditional disable structure based on bitness, which should work off of LabVIEW bitness and not OS bitness.

[Martin_Henz]

I saw similar effects in the past. I removed the complete path and press ok (the VI is broken). Reopen the Call Library Function Dialog again and paste the new path with the wildcard. After that it worked.

[Andrey_Dmitriev]

---

@Gregory wrote:

I'm using the Call Library Function Node to call a DLL in LV 2016. I'd like to be able to use 32-bit or 64-bit LabVIEW, and I have put the corresponding DLLs named USB30_DLL32.dll and USB30_DLL64.dll in the same folder as my VIs. 

My understanding is that I can specify the name as "C:\My Folder\USB30_DLL*.dll" and the * will automatically change to 32 or 64 based on the bitness of my LabVIEW. When I change the 32-bit path to the wildcard it seems to work fine. But when I change the 64-bit path to the wildcard it breaks the VI and says the library cannot be found.

---

I definitively have seen something similar when after renaming to wildcards it was broken, but after reselecting DLL or function it went to good back.

Quickly checked with LV2024 and was unable to reproduce:

[rolfk]

First step is to test your DLL with the full name without any wildcard in both bitnesses. Your DLL may be linked with a dynamic library that is not present on your system and LabVIEW does not make any difference if the library itself can't be found or one of its dependencies, since when trying to load the library, the Windows LoadLibrary() function simply fails in both cases with the same error.

Once you have determined that both libraries load properly you can go and use a wildcard. I used wildcards many times and it always worked although you can have weird effects where LabVIEW somehow caches a DLL and gives you weird results when changing the library name. It usually also results in the situation that the DLL can't be deleted in Explorer despite you not having open any VI or project referencing that DLL anymore. A restart of LabVIEW is the best remedy to fix such strange situations.

[Gregory]

Hi all, thank you for your responses. It does seem like some strange intermittent behavior. After restarting my PC I could replace

USB30_DLL64.dll with USB30_DLL*.dll and still get a white run arrow.

But, then the problem came back when I opened in 32-bit. Changing from 

USB30_DLL32.dll to USB30_DLL*.dll gave a broken run arrow.

It seems I can do some sort of a "reset" by changing 

USB30_DLL64.dll to USB30_DLL*.* which gave a white run arrow.

I guess I will stick to the *.* wildcard when I need it.

[Andrey_Dmitriev]

Well, one trick which I using often to troubleshoot "Broken by not found" issues is Process Monitor from SysInternals.

Download it and on first run setup two filters to get events from LabVIEW only in attempt to open dll:

Now when something gets wrong (i can "provocate" this by entering wrong name):

then Process Monitor will show all attempts which file will be opened and where exactly:

May be you saved somewhere 64-bit DLL under *32.dll name and this occasionally loaded (just idea).

And not only DLLs, but other missing files like ini etc can be catched by this approach.

[Gregory]

Hi Andrey,

Thank you for the tip on Process Monitor. I was able to get the broken run arrow again, and when I looked at Process Monitor there is an operation with the DLL path that says FILE LOCKED WITH ONLY READERS.

Process Name: LabVIEW.exe

Operation: CreateFileMapping

Path: "...USB30_DLL32.dll" (this is the path I expect)

Result: FILE LOCKED WITH ONLY READERS