LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Calling subvis dynamically from within an exe (avoiding error 1003)

Solved!
Go to solution

Hi,

 

I'm using an architecture where the main program (compiled to an exe) can be supplied with user-"plugins" that are collections of vis of specific types inside a specially named folder relative to the exe. They can be called from within the exe via "open vi reference" supplied by the corresponding strict vi types and the corresponding relative paths.

I want to avoid having to include any of the plugins in any way in the application builder, since users should be able to create own plugins that the application is totally unaware of during build.

 

In principle this approach works quite well, since these plugins are not extremely complex, but occasionally I get an error 1003 when loading a plugin.

I've read many old posts about this error in this particular situation, mostly using LV versions 7 or 8 (I'm using 2012). One suggestion was to build a source distribution for every plugin, including everything that is used from vi.lib, instr.lib, and user.lib. This indeed helped in my particular case - however, it bloats the plugin "distribution" (which consists originally only of a couple of user vis) extremely and makes user-side developement more complicated.

Now some plugins run nicely from within the exe without having to build a source distribution for them (they still use many vi.lib vis) while others don't and I have no clue why...

 

These plugins are wrappers for hardware drivers which allow controlling any hardware instrument from within the main application through a certain API. So, in a particular case, a plugin which produced error 1003 is using VISA serial functions (all inside ...\vi.lib\Instr\_visa.llb) and one without error doesn't (yet it uses many functions from ...\vi.lib\Utility\...).

I can fix the VISA-problem in a simple way by including (only) the used VISA-vis (and typedefs) inside the plugin's folder and explicitely link to them (i.e. replace the VISA-vis from vi.lib with the copied ones in the plugin's folder - I guess this is also what the source distribution does).

 

However, I'm confused why some plugins with linked vi.lib vis work while others produce an error 1003 unless those particular vis are explicitely distributed and linked with them...

Oh and just for completeness: All plugins work fine if called from within the developement system, the problem occurs only if called from within an exe.

0 Kudos
Message 1 of 5
(3,843 Views)

Shooting from the hip.  do your your plug-ins manage thier own VISA sessions or are you passing in a VISA resource name of a different class?  (You'ld be surprised how little consistancy in class is in the IDN.)


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 5
(3,838 Views)
Solution
Accepted by topic author Novgorod

Novgorod wrote:

However, I'm confused why some plugins with linked vi.lib vis work while others produce an error 1003 unless those particular vis are explicitely distributed and linked with them...

Oh and just for completeness: All plugins work fine if called from within the developement system, the problem occurs only if called from within an exe.


Do the plug-ins that work rely on VIs in vi.lib that are already part of your executable because the main program uses those same VIs?

 

All the VIs that your plug-in needs must be available, where available can mean either already loaded into memory (by the main application or another plugin), or can be found on disk and loaded.  An executable does not include all of the VIs from vi.lib - it only includes the ones that it uses (as well as any VIs that are marked "always include" in the build specification).  I suspect that the plugins that work rely only on vi.lib VIs that are also used by the main executable.

0 Kudos
Message 3 of 5
(3,832 Views)

There are some VIs in vi.lib that call other VIs dynamically.  Sometimes you have to explicitly add these to the EXE or distribution.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 5
(3,825 Views)

@Jeff: the plugin manages its own VISA session, no such ressources are passed from the main app.

 

@nathand: That might be the solution! I think all vi.lib vis used by the "just working" plugin are also used by the main app (things like error handler or config file vis). No VISA stuff is used in the main app, so those vi.lib vis are not included... This has to be considered when making a plugin, so probabely there's no way around building a source distribution (a plugin developer is normally not aware which vis are included in the main app and which not)...

 

Thanks for the advice!

0 Kudos
Message 5 of 5
(3,822 Views)