Called Labview VI can't find it's controls or sub vi's

[Timmar]

My application consists of:

A standalone .exe that calls cusomized VI's containing generic controls and VI's.

My app works fine in the development environment but when I deploy, the subpanel cannot find it's generic controls or vi's (it uses paths of the vi's from the development environment).

I have included these files in the .exe with the expectation that the called sub vi would know where to find them.

Alas, this is not the case.

These controls and vi's are used in the normal fashion, and not by "open vi reference" so strip path style operations are not an option.

--

An easy solution is to insert multiple copies of them into the .llb library of each of thesub panel sub vi's

These files are generic and used in multiple sub vi's,  in the spirit of re-use and code management,  This method is bad practice.

One file vi is a functional global variable shared between both the calling and called vi.  Which will most likely break the code by executing it in 2 seperate instances.

----

Is there a way for the subpanel sub VI to find it's generic controls and VI's in the calling .exe?

---

A solution to this problem would be highly appreciated.

Tim L.

[GerdW]

Hi iTm,

"it uses paths of the vi's from the development environment"

Can you elaborate this a little bit? Do you use Vis from vi.lib and do you call them using their path??? Or did you change VIs from vi.lib?

"cusomized VI's containing generic controls and VI's"

What are customized VIs? How did you customize? Where did you save them?

"subpanel cannot find it's generic controls"

Do you use subpanels? So you have to use VI server and calling by path?! Which "generic" controls?

Lots of questions, little information...

[Kristoff2]

Timmar,

I agree with Gerd in that we need a bit more information.  Please respond to his post, and also include your code or executable for us to try.  Please include as much information as possible in your post so that we can provided you with the best solution to your problem.

Regards,

Sam K

Applications Engineer

National Instruments

[Timmar]

Gerd,

Sorry for my terminology, Most of it comes from project development, not Labview.

See attached diagram for structure.

Hope this is enough.

[Timmar]

For data secutiy I can't publish my code.

Attached is a mockup I did representing what I need.

You will need to compile the .exe (I didn't include it for virus reasons).

The fault is that it can't find the "Big LED" control included in the .exe build

[Kristoff2]

Timmar,

I was able to build the example you provided into an executable and get it to work by moving 'Hello World.llb' and 'My App.llb' into the same folder as the exe.

Please let us know if this works for you.

Regards,

Sam K

Applications Engineer

National Instruments

[Timmar]

Sam,

Thanks for your insight.

I have been coming to the same conclusion that this is a way to work around the deficiency.

In my opinion it is an ugly workaround. 

In this example, the same control is present in 2 places, both in the .exe and the .llb

This creates a diabolical problem with version control and begins the proliferation of libraries.

I have ruled out allowing the builder to managing the destination of vi's (.exe, .llb, folder) as the called vi won't be able to find the files until the .exe has been built.

This program will be in use on many computers in several countries.  If any of the functional global variable VI's get out of sync, it will be sure to break.

I have another application that uses VI's as Daemons in the same topology with the exception that these VI's are included in the .exe build.  As such know where to access shared controls and VI's.

I was expecting the same courtesy from a VI called from a library.

Intuitively I thought that a vi called from an .exe should look in the .exe for the controls and vi's it can't find.

-----

I have re-worked the code so that it uses queues to pipe data back to the .exe in raw instead of pre-processed form.

There is a bit more data chucked about but it is a small price to pay for simpler distribution.

-----

Perhaps you could pass this on to your Labview Coders and find out the exactly how a VI in this architecture links to it's sub vi's and controls.

Thanks,

Tim L.

[CoastalMaineBird]

Be aware that the BUILD SPEC used to make your EXE has several options, which might be killing you in their default state.

In the ADDITIONAL EXCLUSION category, look for DISCONNECT TYPE DEFINITIONS, REMOVE UNUSED POLYMORPHIC VI INSTANCES, REMOVE UNUSED MEMBERS of PROJECT LIBRARIES.

I would turn them OFF and re-build, just to see if they're causing the problem.

#1 and #3 will bite you if your stand-alone VIs call a subVI, or use a TYPEDEF that's not used in your main and excluded here.

If that FIXES your problem, then you need to put a STATIC REFERENCE to said subVIs (and/or TYPEDEF controls) in the main, to force them to be included in the build.  Then you can turn the options back ON, and save yourself some bloat.

[CoastalMaineBird · Accepted solution]

In my opinion it is an ugly workaround. 

In this example, the same control is present in 2 places, both in the .exe and the .llb

--- Perhaps you are missing the point - if moving the LLBs into the folder with the EXE fixes the problem, then the point is NOT that this is a fix, the point is that something in the LLB is NOT available in the EXE.

If it's a CONTROL, then maybe it's a TYPEDEF'ed control, and maybe the DISCONNECT TYPE DEFINITIONS option is killing you. 

(I've  recently been thru this in an RTEXE, so it's all fresh for me:

Mystery Error 1003 )

[Timmar]

Thanks Steve,

This is a handy thing to Know.

I had assumed that Putting the files in SOURCE FILES->Always Included would be enough.

Do you think that they could be stripped out even if they are in the always included list?

Tim L.