LabVIEW
Missing vi.lib files in Run-Time LabVIEW 2012
Solved!
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.
