Missing vi.lib files in Run-Time LabVIEW 2012

Question

Hi
I've got a problem executing VI's under RT in LabVIEW 2012.
Our system consist of multiple independent modules which are opened and run from a Manager VI. VI paths to the modules are read from an .ini file by the Manager VI.
We have build a single executable (RT Launcher) that takes the path of the Manager VI as argument (Attachment : RT Launcher.png).
The RT Launcher is placed in the ..\National Instruments\LabVIEW 2012 folder as the LabVIEW.exe.
The RT Launcher is called from the CLI.
"C:\Program Files\National Instruments\LabVIEW 2012\RT Launcher.exe" "C:\Workspace\Labview\Manager.vi"
This will run the Manager.vi in the RunTime Environment and the Manager.vi will open the .ini file and execute the Module VI's one by one.
By calling the RT Launcher.exe from the same folder as the LabVIEW.exe, the search paths should be the same.
The system worked fine in LabVIEW 2010.
The Manager VI is opened with broken arrow and the errors indicate that vi.lib sub VIs are missing (attachment : Manager VI errors.png)
I know there are issues regarding object cache and separated compiled code from LV2010 -> LV2011 -> LV2012, but simply can't figure out how to come around this problem.
Can anyone explain the difference and how to solve the problem ?
Thanks
Regards Kahr
Certified LabVIEW Architect
CIM A/S
Solved!
Go to Solution.
Attachments:
RT Launcher.png ‏68 KB
Manager VI errors.png ‏35 KB

Answer 1

Hi Kahr.
It sounds like you are making some dynamic calls to VI's, eg. by using 'Open VI Reference'. My answer is based on that assumption. 
You are absolutely right. In LabVIEW2010 we introduced a function called 'Separating Compiled Code from VI'. At that time none of the VIs from VI.lib had that option enabled. In LabVIEW2011, many VI's in VI.lib have, by default, a separation of compiled code and VI. This option cannot be changed (greyed out) for these VI's as well. This feature was introduced in order to simplify source code control.
Separating Compiled Code from VIs and Other File Types
The drawback is, that it is no longer possible to call VI's dynamically from an application (executable), when this option in enabled, since the compiled code no longer exists. The method of calling a VI dynamically from an application has been (and still is) used to make some kind of a plug-and-play architecture, meaning we have one EXE-file that only gets distributed once and a set of subVI's that gets redistributed according to new versions (new features added to the subVI), meaning we can make changes in the subVI without having to redistribute the EXE-file.
With the release of LabVIEW2011 and LabVIEW2012 we can no longer distribute VI's that uses functions from vi.lib, this also include DAQmx calls even though the DAQmx driver is installed.
The simple explaining is, that it has never been intended that VI's got distributed. Eg, when Microsoft is making a new software update for Windows7, they don't send out the source code to all the users.
The solution is therefore to wrap up the source code into 'something' that includes all the compiled files. In LabVIEW we do that in a couple of different ways.
1) Include the VI's in the EXE-file.
When building the application, we have the option to include files, that normally is not included in builds. If we call a SubVI dynamically this will not automatically be included! However, the drawback of this method is, that if you need to change  something in one of your SubVI's, you would need to build and distribute the entire application. Thereby, we are not making use of the plug-and-play architecture that we originally wanted. However, this method will fix the error.
Error 1003 When Using VI Server in a LabVIEW Application
2) Now, if we still want the plug-and-play architecture in LabVIEW2011+2012 (and this will properly be the same for the next many released of LabVIEW), this can still easily be achieved by making a Source Distribution. When we make a Source Distribution, we can include the VI's from VI.lib and thereby the compiled code. When using this method, two important things should be remembered:
a) Make the files into a LLB file. This will pack all the VI's into one single file, that is easy to distribute.
Go to Destinations ==> Destination Type ==> LLB.
b) Make sure not to 'Exclude files from vi.lib', as this method will then simply not work.
Go to Additional Exclusions ==> Remove checker mark in 'Exclude files from vi.lib'.
How Can I Call a VI Dynamically from an Executable Without Including Those VIs in the Build?
I have made a small example to demonstrate this:
Example: Using vi.lib
This example has two mainVIs and two EXE-applications. Build the two EXE-files, but do NOT build the source distribution yet.
1) Main(IncludeSubInExE). This version has included the subVI in the build distribution for the EXE-file. When running this EXE everything works fine, even when calling the subVI dynamically. However, since the subVI is build into the exe, we would have to redistribute the exe for every new version of the subVI. This breaks the hole idea.
2) Main. The subVI is no longer included in the build. When running and trying to call the subVI, you will get this error (on both your developer and run-time machine):
Now, build the Source Distribution and run this EXE again. The exe is running perfectly with no errors.
I hope this answers your question.
Best Regards
Alex E. Petersen
Certified LabVIEW Developer (CLD)
Application Engineer
Image House PantoInspect
Attachments:
Using vi.lib.zip ‏83 KB