Unable to Access VIs Inside of a LabVIEW 8.2.1 Executable

[paris1_]

Hi... We have a large LabVIEW code (several hundred vi’s total) that we have historically built into an executable and we then distribute the executable to a number of targets. Until recently this code has been developed and maintained in LabVIEW 7.1... The executable build consists of one Top Level vi and approximately 100 dynamically loaded vi’s. Recently, we had a reason to choose to update this LabVIEW code to version 8.2 (8.2.1 to be more specific)... We Mass Compiled all the code and then tested it at the source code level. All seems to work ok. We then used the required LabVIEW project format to build a version 8.2.1 executable... And there we ran into problems described below...

We use a List Directory vi in 7.1 which is now a List Folder vi in 8.2.1 to locate a large subset of that 100 or so dynamically loaded vi’s I mentioned above... The input path to this List vi in the executable version under either 7.1 or 8.2.1 is something like C:\FolderLayer1\FolderLayer2\Myexe.exe where the important point is that the executable is the last element in the search for these files... In the 7.1 executable this works as desired but in the 8.2.1 executable the List Folder vi outputs an error code 13 (Resource file not found?) and the “file names” output (filled with appropriate file names in the 7.1 version) is instead empty...

We are aware of the NI document related to this topic called “Accessing VIs Inside of a LabVIEW Executable or DLL in LabVIEW 8.2 and Later” that can be found at this link..

http://digital.ni.com/public.nsf/allkb/8545726A00272EB0862571DA005B896C

When I first started reading that document, it seemed obvious that it provided the explanation for why our 8.2.1 executable was not working correctly as it says in one part,

“... this functionality was changed in LabVIEW 8.2 (Windows edition only), and is is no longer possible to call the VI within theEXE/DLL or to locate it with the List function.. “

However, further down on the same page of that document is the following note...

“Note: this does not apply to any VI server call to a VI, or List function, called from within the same executable or DLL. For example, VI 'a.vi' in an EXE can still call VI 'b.vi' located in the same EXE exactly in the same way as before. Also, this change still permits you to open application references to an EXE, and subsequent VIs referenced by name, through VI Server when it is enabled for the EXE.”

The above two quotes seem conflicted and are confusing... Can anyone confirm (or deny) that we truly can no longer access these dynamically loaded vi's in the same way we have in the past??? And two, assuming we must find a new method of accessing these vi's, can anyone suggest the best way to go about that??? The solutions described in the above mentioned document seem to be significantly complex. Can anyone suggest any simpler solutions???

Any help would be much appreciated...

thanks... bob...

[Christian Mergl]

Hey,

It's not possible to call or list the VI from outside the application! This is the difference between the two paragraphs you found in the knowledgebase.

I would suggest you to use the "Current VI's path" constant instead of an absolute path as input for the List Folders.vi.

Christian

[paris1_]

Christian... Hi... Can you be a bit more specific??? I did try what I guessed you were suggesting wherein I tried replacing our method of using an explicit path to get to the vi's contained within the executable with the "Current VI's Path" constant like you recommended but I got the same result as before... Though granted I am not at all sure I implemented precisely what you were suggesting... Note, if it helps explain the situation any better, that when we get to this place where we want to load this group of dynamically loaded vi's, at the source code level, those vi's are located in two distinct folders at two different locations within our folder tree and that the vi were are in at the time we want to do this loading of those two groups of files is in yet a third folder elsewhere in our tree... Then at the executable level, all those vi's are apparently contained in a single .llb contained with the executable??? Anyway, not sure that adds any useful information but if you could, holler back and be a bit more specific about how using the "Current VI's Path" might help me accomplish the task I originally described... thanks much... bob...

[ThSa]

Bob,

you have posted a lot, therefore I wanna come up with the most important information starting at 8.x upgrade to ensure, that I've understood everything in the right way.

You have LabVIEW 8.2.1, with one top-level VI (let's call it framework) and a lot of dynamic VIs are called dynamically during runtime.
After building and running the executable you don't get the expected result.

It seems that your quote isn't related on the restrictions of the newer LabVIEW versions at all, because you gonna try to open a VI reference inside the EXE to a VI which is located elsewhere. The restriction in newer LV versions is that it's not longer possible to open a reference from outside to a VI which is located inside an executable.
In LabVIEW 7.1 you could rename the .exe to a .llb and you have seen all used VIs -> this option is gone.

Anyway, I think your mistake is somewhere in the path or the way you have built the EXE and/or the llb with all dynamic VIs.
Attached please find a screen documentation on how to create a source distribution especially for dynamic calls by using VI server.

Additionally check out the new option in LV 8.x -> Debugging of an executable (Advanced section)
With this option it is possible to establish a connection with the source code to the executable and to use the common debugging techniques as highlighting, breakpoints, etc.
If you have questions to this stuff, either read the LabVIEW help to this topic or come by.

Thanks,
ThSa


Message Edited by ThSa on 01-18-2008 03:00 PM

[paris1_]

Hi ThSa... Let me attempt to summarize the issue... First of all the code we deploy gets deployed to a significant number of targets in the field, targets that do NOT have LabVIEW installed so we deploy stand alone applications (exe). Within the code, we come to a place where we want to load many (more than 50) dynamic vi's. In our current builds using LabVIEW 7.1, those 50+ files are contained (along with other vi's) in an .llb file within the executable... I know that last part only because various ni documents tell me that those dynamically loaded vi's are stored within the exe in that fashion. In 7.1 we then have a place within the code where an explicit path to those files connects to the input of a List Directory vi... That path looks something like

C:\Folder1\Folder2\Myapp.exe

where Myapp.exe is the name of the executable we've built... In 7.1, that all works fine and the List Directory outputs an array called "file names" that then contains the names of all the vi's found in that internal .llb file... We then pass that array on to some filters that pull out specific files we want to load...

Now, in 8.2.1, that no longer works. The List Folder (what List Directory is now called in LabVIEW 8.2) now produces an error 13 and and the file names array is empty... The ni document I referenced above lists four possible work arounds... Those are,

1. If you were using this technique, you were basically treating the VIs contained within the EXE or
DLL as exported VIs. Accordingly, one option is creating a DLL and exporting each VI you are using
from the DLL build specification. This makes your calling code more modular and is probably the
best design choice of these solutions.

2. Create a source distribution for your exported VIs. With a source distribution, you can create a
single LLB file to use just like you were using the EXE/DLL in the past. You still have the ability to
remove block diagrams, front panels, and still call the VIs through VI server.

3. Enable the ActiveX interface for the EXE you are calling into and use the VI Server ActiveX
interface (from the LabVIEW functions palette: "Connectivity»ActiveX»Automation Open) to run the
VI (Get a VI Reference, Set the Control Values, Run the VI, Get the Indicator Values), making this
change could potentially involve a lot of work for the caller of the function, and a little for the build
specification.

4. Enable TCP/IP support for VI Server for the application. Open an Application reference to that port
on your local machine (from the LabVIEW functions palette: "Programming»Application
Control»Open Application Reference", then use "Open VI Reference" and call the VI as you did in
the past. While it isn't much more work for the caller, you do have to actively manage your ports and
keep up with the right settings in the ini files for the EXEs.

I am currently trying to decipher what each of these options means and which, if any, might work for me.. I don't understant number 1 because you can't read files within a DLL any more than you can within an EXE in LabVIEW 8.2 so that one confuses me... I am currently looking at option 2...

Any help on any of the first three options (I don't think the TCP/IP option could work for us) would be much appreciated...

Thanks much.. bob...

[ThSa]

Bob,

attached please find an example project.
This project contains a simple main VI (don't take care of the GUI or the programming style, this is simple to validate the functionality), three VIs (Dyn1..3) which gonna be used to get called dynamically. Please check also the two build specifications -> EXE + LLB, whereas the LLB is the more important factor in your case.

ThSa