LabVIEW
Call library function node: library not found or failed to load. Trying to use third-party library.
This DLL depends on:
BTI1553.dll
BTI717.dll
BTICARD.dll
BTICSDB.dll
BTIDIO.dll
BTI708.dll
BTI429.dll
BTI422.dll
MSVCR90.dll
All the BTI files are drivers from Ballard/Astronics and don't seem to be delay loaded, so would likely need to be present too somewhere on your system. The MSVCR90.dll is from the Microsoft Visual C Runtime 9.0 Distributable Installer that comes with Visual Studio 2008 and which was very standard on Windows 7 systems but isn't automatically present on Windows 10 anymore.
Microsoft is pulling many downloads from their site for unsupported software and Visual Studio 2008 support ended in 2018. But I found one patch fix installer they still have up: https://www.microsoft.com/en-us/download/details.aspx?id=11895. It's a slightly never version than what comes with Visual Studio 2008 but should work.
@Sidkay wrote:
BTI1553.dll
BTI717.dll
BTICARD.dll
BTICSDB.dll
BTIDIO.dll
BTI708.dll
BTI429.dll
BTI422.dll
MSVCR90.dll
The above mentioned files are already present in system32 folder as a result of driver installation I think (picture attached).
I installed Microsoft Visual C++ 2008 Service Pack 1 but same problem.
Well, one of those DLLs is either not 64-bit or depends on other DLLs that are not present or not the right bitness. But someone really thought it was a good idea to copy NI by creating a myriad of different DLLs for their hardware. Except that NI supports all in all maybe 1000 different hardware products where this Ballard hardware consists of a dozen or more different hardware products.
Unfortunately your indication that the C program works is not entirely conclusive here. The BTIVI.dll seems to be a specific for LabVIEW created DLL that wraps all the other BTI dlls in some way that depends on each of these. Your C program almost certainly is not using this BTIVI.dll but calling directly the according target DLL for your hardware. So it will work if all dependencies for that hardware are present, without needing all dependencies for every ever released Ballard hardware no matter if you actually use it or not.
It's definitely a support problem that Ballard/Astronics should help with. Only they can determine all the dependencies of their drivers and locate possible deficiencies in their installer. It's very possible that one of those DLLs the whole shenanigan depends on, was compiled in a different Visual Studio version and needs its own C Runtime Library. Without delay loaded dependencies this is what one gets when making such a driver monster.
@Sidkay wrote:
Hello, Any responses for me please?
Sorry, I'm not working in customer support of Astronics/Ballard. Tracking down dependencies of dependencies is not an easy task if you don't have the source code of the according DLLs to consult.
You really have to get the manufacturer involved, as frustrating as that may be. I don't know about Ballard but worked in the past with an 1553 card from AIM. And while they had some LabVIEW support, they had basically no-one who could do technical support for the LabVIEW interface. It was a painful exercise to get everything working right. But I do not have hours and hours to spare to do free technical support for a product like this, especially since I have no personal experience with this hardware.
