Error 1003 Missing vi.lib dependencies

[DuncanW]

I have a LabVIEW 2010 project which includes some VIs, which are called by reference.

The project runs fine in the development environment, but generates Error 1003 (which indicates that the child VI is broken) at runtime when compiled as an executable.

I have tried using both an Invode Node and a strictly typed Call By Reference node and both methods return Error 1003. The VIs called aren't broken, but only appear to be so when compiled as an executable.

When the parent calls the child, the LabVIEW dependency searching dialog pops up and it frantically searches for a couple of seconds before throwing the error. I have identified that the VIs it is searching for are part of vi.lib.

I've looked in the build log and the vis were logged as being included and if I change the build to include dependencies as files stored in the Support directory rather than compiled in the executable, the files are present.

If I add a 'viSearchPath=' line to the application's ini file directing it to the Support folder, that still throws the error. If I add the absolute path to the vi.lib folder in the viSearchPath, the searching dialog now finds the dependencies and the child vi runs, albeit slowly as it keeps having to find dependencies at runtime.

So, the questions are why aren't the vi.lib files included in the built application so it doesn't need to try searching for them and secondly why doesn't the runtime know where to find the vi.lib folder ?

Many thanks

Duncan

[MahdiehG]

Hi Duncan,

This article explains well why you would be getting the 1003 error:  http://digital.ni.com/public.nsf/allkb/705C2ECA081F3C7986256C0F00559B02?OpenDocument

Here is how you can install the support files in the same directory as the exe. Hopefully this should stop LabVIEW from the frantic searching:

http://digital.ni.com/public.nsf/allkb/2EBA44FCF6EF0F5686256A41005DA1F5?OpenDocument

Please let me know how you get on.

Kind regards,

[MahdiehG]

Hi Duncan,

I’ve managed to find some more information for you.

The -1003 error can stem from the fact that the vi.lib is not accessible to that particular VI when running in the Run-Time environment. My recommendation is to create source distribution (llb) of the VI that you are trying to call programmatically and then call into that source distribution. The trick is that the source distribution should include the vi.lib. You can include the vi.lib by unchecking the Exclude files from vi.lib in the Additional Exclusions in the Source Distribution Properties.

I also think you will find this link useful: http://digital.ni.com/public.nsf/allkb/8545726A00272EB0862571DA005B896C?OpenDocument

And this is how to build a dll: http://zone.ni.com/devzone/cda/tut/p/id/3063

I hope this helps you out. 

[DuncanW]

Hi MahdiehG,

Thank you for replying to this.

Unfortunately this first link is to resolve Error 1003 during build, which indicates that one or more VIs were broken in design time when building. The issue I have is in execution with the runtime engine not loading all dependencies and I couldn't find any appropriate workarounds in there.

The second link is to manually add individual files in the build. The project explorer correctly identifies and automatically includes the files needed in the Dependencies folder in the project and builds them into the application or the support folder. This is happening and the files are there as part of the normal build process, but requires a search to find them.

If I were to manually add theses same VIs to the project as specific files, I'm not convinced it would be any different to the project explorer containing them as dependencies and building them in. Also, I can see it getting in one heck of a mess with conflicts as the VIs are low level vi lib files. For example, one VI it fails to find is the Get Key Names VI, which is in vi.lib/Utility/config.llb, so I'd need to include the whole of the library to get all it's dependencies and then hope the project removes them from the project explorer dependencies folder.

Kind regards

Duncan

[DuncanW]

Hi Mahdieh,

Thank you for your update.

So, if I understand this correctly, I need to create a library, add it to the project and add to that as many vi.lib library elements as necessary to stop the searching from taking place. This sounds like a nasty workaround, which I'm not confident will work because of conflicts, but will try it and see how I get on. The check box you refer to uncheck is not present in LabVIEW 2010.

Kind regards

Duncan

[MahdiehG]

Thanks Duncan,

This particular problem is quite difficult to debug. As a general rule here's how you can debug an exe: http://digital.ni.com/public.nsf/allkb/3087D91EEADBAF3D862571D1004AF192?OpenDocument

Have you tried moving all your files(subVIs) into the same folder as your exe? 

Does it run fine when it's not made into an exe?

Where you using a different version of LabVIEW to create some of the VIs?

I would also recommend that you try and do a mass compile of your files: http://digital.ni.com/public.nsf/allkb/654877E62A97B72986256C95006F9B24?OpenDocument

Another solution that you might want to try:

1.Open your LabVIEW project and delete My Computer>>NI_LVConfig.lvlib if you included this in your project
2. open My Computer>>Dependencies>> vi.lib and make sure NI_LVConfig.lvlib is now there
3. create a new Application following these next steps
3.a. include the sub vi in the always included section (this is the only file that needs to be always included)
3.b. Build your application

Let me know how you get on with this.

Thanks

[DuncanW]

Hi Mahdieh,

Thank you for this.

Using the debugger, it identified the source of the error was the Open VI Reference VI, which is not surprising. I don't appear to be able to view the child VI as it's called by reference and so doesn't appear on the block diagram. If I add the child VI to the parent's block diagram (so I can click on it in the debugger), the application exe obviously runs without error as the child's dependencies are loaded when the parent is loaded.

I've created a test project which exhibits this problem, and I have attached it.

The test project consists of 2 VIs; a parent & a child. The parent calls the child by reference and the child contains code to read & write sample configuration data to an ini file.

When I run this in the development environment, it works fine.

When I build this with everything compiled inside the exe, I get Error 1003 as described above.

When I build this with the parent & child compiled inside the exe, but the dependencies saved as files in the data folder, the exe runs without error, but produces the searching dialog box when it loads the child.

Hopefully you'll be able to see the same if you run the same project.

Many thanks

Duncan

[Thoric]

Duncan,

Not sure this will help you, but it's worth mentioning. I came across this exact same issue yesterday - Error 1003 when opening a VI reference within a built application, for a similar plug-in style architecture. I've found that if I bundle my 'plug-in' VI into a LabVIEW library (.lvlib), then create a Packed Library (new in LV2010) from it, and call into the packed library, that the 'plug-in' VI works fine.

I'm new to packed libraries, but I understand that these contain compiled code, and therefore contain everything they need to load and function, eliminating the need for it to find all those dependencies. Unlike an application build with all dependencies from vi.lib included etc., the file size is much smaller (mine is 49kB, instead of 40MB!)

Hope this helps!

[DuncanW]

Thank you Thoric,

Yes, I understand what you're saying here, but the issue is that the runtime isn't using the vi.lib dependencies, which are compiled in.

Mahdieh has been helping me offlist and we've found that if you check the "Use LabVIEW 8.x file Layout" in the Advanced section of the build specification, it solves the problem and the child VIs now have their dependencies at runtime.

This appears to be a bug in that if you want to do call by reference, you need to check this seemingly irrelevant option to be able to have your child VI's dependencies loaded.

Many thanks to Mahdieh & her team at NI for helping to resolve this.

Duncan

[Thoric]

Interesting. I tried the using the 8.x file Layout and that didn't help me, mainly because the calling built application didn't have the plug-in vi dependencies within it and so the plug-ins were still forced to search for their dependencies as soon as they were loaded. I'm unable to anticipate all the plug-in dependencies in order to add them to the main build, and my customer will develop further plug-ins of their own, which will have unforseen dependencies, so I need to find a way for the plug-ins to stand independently. Why they lose their dependency file locations when loaded in the run-time environment baffles me, especially given they are all within the LabVIEW installation folder.

Thanks for the reply Duncan!