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

[wfarid]

We were using a Labview created DLL file which uses VIs from the DFD toolkit, but weren't able to make it work at all. Now, we replaced the DFD VIs with VIs that we built, and the DLL file is working fine. Is there any reason for that ?

Although it is working, this process is way to long and it is a waste of time because the DFD VIs are already implemented, so we need a quick fix for that, any suggestions.

When using the DLL file that utilizes the DFD VIs, there seem to be a failure always when loading specific VIs from the DLL file, does anybody know why ? The VIs that Labview looks for are in a path that looks like "DllFileLocation.dll \ Labview 2009 \ vi.lib \...... "

Thanks,

 Walid Farid

[Fred_V]

Hi Walid,

That's sounds like unusual behavior. Are you able to successfully compile a LabVIEW DLL that uses DFD VI's? Or is the problem related to running the DLL? 

Is there a particular DFD VI that causes the problem, or can't load? 

[wfarid]

Hi Fred,

 I was working on this issue yesterday and finally go it to work. I needed to have the DFD and the Advanced Signal Processing toolkits installed on the same machine on which the .dll file is called. Additional dll files that are used by the created .dll file ( example LVDFD.dll ) have to be in a specific path as well.

So, now my question is :

Can I use the created .dll file without having the toolkits or LabView installed ? How can I link all the used VIs on the machine on which the created .dll file will be running without having LabView installed ?

Thank you,

 Walid

[Fred_V]

Hi Walid,

Sure, it looks like you'll just need to include the Advanced Signal Processing .dll's as supporting files when you build your LabVIEW dll. 

see this KnowledgeBase article:

Why Is My Application Looking for DLLs When Using VIs from the Advanced Signal Processing Toolkit?

[wfarid]

Hi Fred,

 I still can't make it work.

 Here is what I've done:

 1) I added all the dependencies ( .vi files ) that the main vi uses, to the support directory which has the default name data, in this case.

 2) All the dlls that were specified in the link, were added along with LVDFD.dll and lvanlys.dll

Now, when I run a program which uses the created .dll file on a machine on which LabView and its toolkits aren't installed, I get a LabView window which keep browsing for .vi files and finally no outputs are returned. The vi files that the dll is searching for can be found in the specified support directory data, but it seems that the dll can't find them.

I attached the LabView window which notifies me of the vi files that the dll file is searching for, and I attached a a windows explorer view for the folder which contains the vi that the dll is actually looking for. 

Note: The file specified in the screens is not the only file that can't be found.

Thank you,

 Walid

[Fred_V]

Hi Walid,

Could you change the location of the support VIs to the application EXE instead of the data directory? The executable may be able to find those VIs if they're located within it. 

Within Application Builder go to the Source File Settings Category, and change the destination of the support VI's to the Application.exe directory.

[wfarid]

Hi Fred,

 Could you please clarify what do you mean by "change the location of the support VIs to the application EXE instead of the data directory" ? I'm trying to build a shared library. When using the application builder and going to the Source File Settings Category, I changed the destination of the support VI's to the SharedLib.dll directory. I guess that is what you meant. The files couldn't be located still.

I attached two LabView windows to show two files - out of many - that LabView was trying to locate. I also attached a view for the Folder that Labview created, which contains the .dll file along with a view for the data folder.

Note : I'm using

(1) LabViewRun-Time Library Standard ( 32-bit )

(2) Visual Studio Express 2010,

(3) The .dll file was built using LabView 2009 and it utilized built-in VIs from some toolkits like the Digital Filter Design and the Advanced Signal Processing toolkits.

Thank you,

 Walid

[Fred_V]

Hi Walid,

Given your screenshots, it looks like the LabVIEW runtime engine is looking for the Wavelet Analysis VIs, so they may not be automatically included when you compile the DLL. To work around this, could you drag the items in the Dependencies section of the LabVIEW Project Explorer, up to under the My Computer section? Then when you compile the DLL you can specify each of those VIs as Always Included, and they should also be copied to your data directory.

You should also be able to set the data path as the DLL file itself, and the support files will be copied into an internal path.

Hope this helps,

[wfarid]

Hi Fred,

(1) I did what you've suggested exactly. Some VIs are copied and other VIs are not ( For example : some VIs under vi.lib which are under .lvlib folders can't be copied ) and I'm still unable to make it work using LabView run-time engine only.

(2) Without going through moving the VIs from the dependencies folder to under my computer, we tried to generate a .exe file, and it was working fine ( In both cases : either when adding the VIs to a support folder or by including the files in the application.exe file ), so why isn't the generated dll working in the same way ?

I though of this solution, because we guessed if the exe wasn't going to work then the dll will definitely not work. So, are there any insights from having the exe working?

(3) When the application.exe is looking for a missing file, a browser window directs you to locate the missing VI. However, when the generated DLL is looking for a missing file, it bypasses that file and proceeds. Is there a reason for that ?

Thank you,

 Walid

[Fred_V]

Hi Walid,

Do you have a simple example that has this issue when compiled, or can you describe a simple case so that I can reproduce this? Given that you can successfully compile and run an application, there may be more to this issue than just missing VIs.

I'm not sure of the reason that files missing from DLLs get bypassed and files missing from executables can be located. I'll try to look into that while I try to duplicate this issue.

Thanks,