Labview created DLL which uses Labview built-in VIs from the ( Digital Filter Design ) "DFD" Toolkit

[wfarid]

Hi Fred,

Here is sample VI for you to re-generate the problem. I'm attaching a Visual Studio 2010 solution with the name "LabViewDll_Test" with 2 projects ready to run.

 Project(1) : DllWithDependenciesInDll_Project

 Project(2) : DllWithDependenciesInSuppDir_Project

As the name implies, the 1st project is a dll with the dependencies being located within the dll, while for the 2nd project the dependencies are located within the support directory.

The details needed are in the file main.cpp within each project. In each project there is a folder generated by LabView that includes the .dll files.

The second file attached contains the VI for which the dll was created but with the input and output attached. The name of the main VI is Test_Design.

Note: On the machine that has the LabView installed with the necessary toolkits, the projects are working fine (i.e. I get the logic output). However, when using the same projects on a machine on which the LabView run-time engine only is installed, the dll fails to locate some VIs and I get no output.

Thank you,

 Walid

DllWithDependenciesInSuppDir_Project

[Fred_V]

Hi Walid,

Could I get you to try one more thing, and move the support DLLs from the Support Directory (data) into the same directory as the calling DLL? The calling DLL will look in the same directory, as well as on the search path, and the support directory and the DLL path may not be sufficient.

[wfarid]

Hi Fred,

 I moved the support DLLs and the program is still not working. Where you able to regenerate the problem on your machine ?

 Please use the latest versions of MSVC++ 2010 solutions which are attached.

Thank you,

-- Walid

[Fred_V]

Hi Walid,

Just to update: I'm still taking a closer look at your code, and reproducing your failure case. I'll follow-up when I have some further insights.

[Fred_V]

Hi Walid,

I used Dependency Walker to run your sample exe and observe which DLL's the application was looking for, and unable to find. It seems that it was looking for the Infolder_DLL folder, and so after moving that file to the build directory, the executable works correctly on a test machine containing only the LabVIEW and the Visual C++ runtime engines.

I've attached the Release build directory below. Could you test this, and confirm that this will work for your larger application?

I hope this helps,

[wfarid]

Hi Fred,

I double-clicked on the file "DllWithDependenciesInSuppDir_Project.exe" which is included within the folder that you sent Release. However, the output is zero instead of being 5.93. It is not working on both machines ( the one with LabView installed and the one with LabView run-time engine ).

I applied your comments to the projects on my PC. The .exe file is working on the machine with LabView installed but not on the other machine which has the LabView run-time engine installed. I attached the 2 release folders for you to try it on your machine.

Thank you,

 Walid

[Fred_V]

Hi Walid,

Sorry about that - I overlooked that aspect of the code. I took a closer look at the results of the Dependency Walker analysis, but wasn't able to figure out which DLL it was looking for. I'll bring the issue to R&D on Monday to see what we're missing.

All the best,

[Fred_V]

Hi Walid,

R&D mentioned a few additional things for me to try, so I setup a duplicate case, just using a LabVIEW exe to call the DLL, and so far I'm observing similar behavior. No answers yet, but I do have a clear test case on my end.

I'll keep you informed. 

[wfarid]

Thank you Fred !

I'll be waiting for your update.

-- Walid F. Abdelfatah

Research Assistant, NavINST - Queen's University

[Fred_V]

Hi Walid,

I have LabVIEW code (and executable) that calls your DLL, and I observe the exact same behavior. However, it doesn't appear to return 0 because of a missing dependency - the DLL's all appear to load correctly.

I compiled another DFD example into a DLL and called that from a LabVIEW exe, and everything behaves correctly.

I suspect that there is something within your LabVIEW code responsible for this behavior beyond the use of the DFD.

Could you upload your code to NI's FTP site (ftp://ftp.ni.com/incoming) zipped and labelled with Walid? I'd like to examine the true cause more closely.