LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Executable with Dynamic VIs

Solved!
Go to solution

LV 8.6.1f1

 

I'm having a hard time figuring out the ALWAYS INCLUDE field under the SOURCE FILES section of the BUILD properties in my BUILD SPECIFICATION.

 

My app uses "plug-ins".  You configure a channel (in my editor) as a plug-in channel, you give it a name "X".

 

The code looks for "X.vi" in a certain folder, runs it once to check out if it exists, figure out its prerequisites, and gets ready to run it for real. 

 

These plugins do things like compute a power channel from a speed and torque channel, or things involving chemistry.  Basically, they're fake channels, but the user can treat them just like real channels by adding alarms, graphing them live, etc.

 

These plugins use certain subVIs, and control typedefs (ENUMS, mostly) that are in the main program.

 

All this works fine in the development system.

 

If I build the app, my config puts the app alongside the main VI's library file, and the executable works just fine.

 

However, If I move the app (and the supporting folders with the plugins) to a different place (without the main source code present), I have trouble.

 

Specifically, when I make a channel ACTIVE (and thus try to dynamically load it), I sometimes get an error 1003, meaning the VI is not executable (broken).

 

When I flip the ACTIVE switch, I can see the LOADING dialog appear for just a tenth of a second or so. If I keep trying, I can eventually read the name of the VI it's looking for (some subVI, or control, used by the VI I'm loading).

 

If I modify the build spec to include that control in the project, it doesn't change anything.  I don't really expect it to, since the main VI already knows it needs this particular control (in a lot of places besides the plug-in).

 

However, if I add this control to the ALWAYS INCLUDE list, then things work just fine.

 

The question is: WHY?

 

I can guarantee that this control is in the EXE; it's used in a lot of places (including the editor that checks out the plugins).  I just did a search and found 807 instances of it. 

 

The help for ALWAYS INCLUDE says "Specifies the dynamic VIs and support files always to include in the application, even if the startup VIs do not contain references to the files".

 

I just confirmed that if i remove it from the ALWAYS INCLUDE list, it fails; if I add it back in, it succeeds.

 

Maybe it has to do with paths - in the development folder, I have :

Root\Main.llb\Main.vi                  { the main VI } 

Root\Libraries\Units.llb\Units.ctl   {the control in question }

Root\User\Plugins\Whatever.vi    {a plugin that uses it }

 

When I build the app, it goes into the root:

Root\Main.exe

and everything else is the same. 

 

I move the app into a testbed:

Root\Testbed\Main.exe    {the main program } 

Root\Testbed\User\Plugins\Whatever.vi   { a plugin }

 

and there's where the failure occurs.

 

So the questions are:

1... Why is this happening?

2... What rules do I need to follow so that it doesn't happen again?

 

I don't want to just dump stuff into the ALWAYS INCLUDE bucket until I understand what's what.

 

Ideas? 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 1 of 12
(4,915 Views)

Hi Steve,

the control is in the exe, but if you only have your plugin vi without the control, then the vi is not executable. Every vi, you want to load dynamically, has to be executable independently from the exe which calls them.

 

Hope it helps.

Mike

0 Kudos
Message 2 of 12
(4,892 Views)

The control is in the exe, but if you only have your plugin vi without the control, then the vi is not executable.

 

--- I don't understand what you're saying.  The control does exist in the EXE, it's used in lots of other places in the EXE.  So I was expecting the plugin to be able to find it. 

 

 

Every vi, you want to load dynamically, has to be executable independently from the exe which calls them.

--- That's not exactly true, specifically the "independently" part. 

 

 

More testing with lots of these plugins has yielded the following rules for my case:

 

  1. The plugin itself does NOT have to be in the ALWAYS INCLUDE list.  That's obvious, or it wouldn't truly be a dynamic VI.
  2. If the plugin uses a typedef control, then that control must be in the ALWAYS INCLUDE list.  It doesn't matter if it's used in the main already, even 800+ times.  It simply has to be in the list.
  3. Any subVIs that the plugin calls have to either A) be already used in the main, so that they're in the EXE, or B) in  the ALWAYS INCLUDE list.

 

My confusion comes from the difference between 2 and 3.  Controls are fundamentally different from VIs in this treatment, and I didn't (don't) understand why. 

 

I said that your "independently" comment was not true because of #3.  These plugins are capable of finding subVIs in the parent EXE.  They're dependent on the EXE, but they can still work if that dependency is resolvable.  

 

For some reason, they're not capable of finding typedef controls in the parent. 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 3 of 12
(4,871 Views)
Solution
Accepted by topic author CoastalMaineBird

CoastalMaineBird wrote:

...

 

 

For some reason, they're not capable of finding typedef controls in the parent. 


Hi CoastalMa...,

did you uncheck the "remove typdefs from exe" in your application builder?

 

Mike

Message 4 of 12
(4,865 Views)

BINGO!

 

It's actually called DISCONNECT TYPE DEFINITIONS in the ADDITIONAL EXCLUSIONS category.

 

But that was checked, by default.  And I never noticed it.

 

So the EXE was removing all TYPEDEF connections, and the plugin needed one, THAT's why it couldn't find it!

 

SIDE EFFECT: the build time went from 4:15 down to 0:46 !  (Yea!)

 

SIDE EFFECT: the EXE size went from 10,891,376 to 13,882,368   (Boo!)

 

 

Now that I know WHY, I can make a choice of what to do.

 

Thanks, Mike! 

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 5 of 12
(4,858 Views)

Hi Steve,

sorry for the confusion before. I checked it with my application i working on and you are correct, if the vi is already in the exe, then it works. Last time i used it before, was with LV7.1, maybe there were some changes till now.

 

Mike

Message Edited by MikeS81 on 07-02-2009 01:41 PM
0 Kudos
Message 6 of 12
(4,856 Views)

  sorry for the confusion before

 

No sweat, Mike.  We got the right answer eventually.

 

Thanks, again. 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 7 of 12
(4,851 Views)

Just for the record, I want to point out something.

My config normally builds the apps to reside right next to the libraries the VIs are in.

Thus the path from the EXE to the plug-in to the typedef in the CTL file is the same as the path from the LLB to the plug-in to the typedef in the CTL file.

So when I built the app, these plug-ins were loading the typedef from the usual place AND I NEVER NOTICED THE PROBLEM. 

 

 

It was only after my client tried the EXE on a machine without the source code that we noticed the problem.

 

Note to self:  test EXE builds in a clean, different environment (just a clean, different folder will do). 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 8 of 12
(4,835 Views)

I built quite a generic test framework with which I want to run any VI (of course with always the same connector) dynamically from an Executable. Since I don't know what kind of VIs will be programmed in the future I cannot include all the needful SubVIs in advance.

 

I made the following workaround:

In the application folder, at the same level as my EXE, I placed a copy of the whole vi.lib, which is normally placed next to LabVIEW.exe. (Remark: VIs from the vi.lib are NOT included in the runtime engine). The file structure with all the dynamic VIs, including all its SubVIs is also placed in the application folder.

When calling a dynamic VI it will load all its SubVIs from the stored paths - either in the file structure with the SubVIs or from the vi.lib.

 

It is very important that all the dynamic VIs are mass compiled before copying them into the application folder of the EXE. Unlike as in the development system it is not searched for SubVIs - when a SubVI is not at its expected place, the whole dynamic VI cannot be loaded.

 

 

Almost everything worked fine like that. In some special cases the dynamic VIs could not be loaded from the EXE. When a dynamic VI holds some special SubVIs the mechanism doesn't work and the VI cannot be loaded. The following VIs caused that problem:

 

- NI_MAPro.lvlib:Extract Single Tone Inforamtion 1 Chan.vi

- NI_AALbase.lvlib:Butterworth Filter (DBL).vi

 

Both of the VIs call some DLLs in their SubVIs, perhaps that's the problem.

Did somebody try out the above described solution and did somebody experience the same problems?

0 Kudos
Message 9 of 12
(4,604 Views)

Your case is interesting, but different from mine.

 

In my case, I have only a few, well defined set of subVIs needed.

 

I am deploying this on multiple systems.   I wonder about the licensing and legality of deploying a whole copy of VI.LIB on systems where there is no LabVIEW license.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 10 of 12
(4,580 Views)