programmatically choosing the dll and function within the dll

[hartzde]

Attached is a screen shot of the problem VI.  The front panel data is from a run in the development environment and shows the data being fed to the VI.  When built and run, the dialog box shows the correct relative path to the VI.  The error message is as described previously with the extra paths.

[dkfire]

You can't use a "relative" path. It will be relative to inside the exe, NOT relative to the application folder. That is how exe works in LabVIEW. 

You need to build an absolute path to your files.  Use the Application Directory.vi, that you are already using, and the Build Path. 

[hartzde]

That is what I have coming in as the VI Path.  If I use the absolute path, I get the following

Possible reason(s):

LabVIEW:  File not found. The file might be in a different location or deleted. Use the command prompt or the file explorer to verify that the path is correct. =========================

NI-488:  Nonexistent GPIB interface.

VI Path: C:\Users\hartzler\Documents\LabView Stuff\TesterExec\Build\ELI380DCPS\CurrentTest.vi  

Built Application or Shared Library (DLL): Make sure all dynamically loaded VIs were properly included in the build specification for the application or shared library.

LabVIEW Real-Time: VIs built into executables cannot be accessed through VI Server calls. Use Source Distributions to dynamically call VIs on Real-Time targets.

As I typed this I noticed that there was no reference to the LLB file in the path.  I added that and the result was:

Possible reason(s):

LabVIEW:  The VI is not executable.  This error may occur because the VI is either broken or contains a subVI that LabVIEW cannot locate. Select File>>Open to open the VI and verify that you can run it.

VI Path: C:\Users\hartzler\Documents\LabView Stuff\TesterExec\Build\ELI380DCPS\ELI380DCPS.llb\CurrentTest.vi

Again, this works fine in the development environment.

[nathand]

Can you start with a simple dynamically-loaded VI that doesn't call any subVIs and make sure that you can load it? If so, then start looking at the VI that is causing you problems. Maybe the dynamically-called VI calls a function from vi.lib that isn't included in the build because the main application doesn't need it; I believe that could cause the error you're seeing because the dynamically-loaded VI wouldn't be able to find that required subVI.