VI name collision using plugin type architecture

[TLE]

I am using LabVIEW 8 and am building an application that will use a "plugin" architecture. There will be a main program built into an executable that calls sub vi's that are in llb's. Some vi's in the llb's will call DAQmx functions, others will do calculations, etc. Some math functions will be done in the main program too.

The problem I am trying to address is how to deal with vi.lib vi's that are used in the plugin llb vi's and the main program. For example, I use Mean.vi in one of the plugin vi's as well as in the main program. Where should Mean.vi be stored? A name collision occurs if it is in more than one location (i.e. in a plugin llb and the main program executable). This can get very complicated if many vi.lib vi's are used in the plugin llb's and the main program executable. How can I distribute vi.lib vi's that are required for my application to run? The application builder is fine for simple distributions but breaking up the application into several modules (llb's) that have functions (vi's) like a dll has some great advantages.

As side issue, does anyone know of a way to assign a version number of a llb file that is visible from its properties window in Windows?

[allaba]

---

@tle wrote:

I am using LabVIEW 8 and am building an application that will use a "plugin" architecture. There will be a main program built into an executable that calls sub vi's that are in llb's. Some vi's in the llb's will call DAQmx functions, others will do calculations, etc. Some math functions will be done in the main program too.

The problem I am trying to address is how to deal with vi.lib vi's that are used in the plugin llb vi's and the main program. For example, I use Mean.vi in one of the plugin vi's as well as in the main program. Where should Mean.vi be stored? A name collision occurs if it is in more than one location (i.e. in a plugin llb and the main program executable). This can get very complicated if many vi.lib vi's are used in the plugin llb's and the main program executable. How can I distribute vi.lib vi's that are required for my application to run? The application builder is fine for simple distributions but breaking up the application into several modules (llb's) that have functions (vi's) like a dll has some great advantages.

As side issue, does anyone know of a way to assign a version number of a llb file that is visible from its properties window in Windows?

---

I also use the plugin approach where a compiled .exe plugs in VIs which share vi.lib VIs with the main.exe. I did not yet use LV 8 for this, bit LV 7.0.
In principle there is no problem: the main.exe loads into memory first and with it the vi.lib VIs it contains (say e.g. mean.vi). When a plugin using mean.vi is loaded, it uses the instance of mean.vi which is in memory, i.e. the one which is stored in then main.exe (typically with its front panel and block diagram removed).

The problem starts when the plugin is closed, since the it asks if it should be saved to disk because the path to its subVI 'mean.vi' has changed. This is at least annoying. A workaround is to rename all VIs from vi.lib (and user.lib, instr.lib maybe) and save them to a different location before the .exe is built. That way all namespace collisions are avoided. I wrote a tool to do this renaming automatically. AFAIK there is a better (=more professional) tool for this purpose: the OpenG Builder, see at  http://www.openg.org/index.php?option=com_content&task=category&sectionid=4&id=68&Itemid=47. I haven't used it, though.

OTH: My understanding was that all these namespace problems have been resolved with LV 8 since its new application builder supported such autoimatic renamings. From your post I understand the problem is still there in LV8!? So one more reason not to upgrade yet. Maybe others can confirm.

[TLE]

My application is intended to be run on a computer with only the RTE installed.

I can create a plugin llb out of my vi's using the Build Specifications in LabVIEW 8.  I included my user.lib vi's but not the vi.lib vi's.  The main application was built from another LabVIEW project into an executable.  It uses some of the same user.lib vi's and vi.lib vi's.

The main application executable can call vi's in the plugin vi successfully as long as the RTE can find the vi.lib directory.  I made sure it could by copying the entire vi.lib directory into my application directory.

I make the following conclusions:

1. If any vi.lib vi is in a plugin vi and used by the main program executable, a "1003" error occurs (vi not executable) when the main application tries to connect via the vi server to a vi in the plugin llb.

2. A user.lib may be in a plugin vi (and thus in the plugin llb) and used by the main program executable (and thus in the executable file) without any errors.

3. If vi.lib vi's are not included in either the plugin llb or the main executable, the RTE must be able to find vi.lib.  I tried using my applications ini file to point it at the vi.lib directory in the LabVIEW directory but could not get that to work.  I had to copy the entire vi.lib directory (parts of it may have worked too but figuring out what all to copy is time consuming) to my application directory.

[AESulzer]

You might want to install the latest patch for LabVIEW (8.0.1) (if you haven't already) as I know that it has fixed the error 1003 issue when dynamically calling from an executable subVIs that contain vi.lib VIs. In this sense, the patch to restores LabVIEW 8.0 back to the way it functioned in LabVIEW 7.1 from a plug-in architecture perspective. Also be aware of the caveats mentioned in this KB.

Kind Regards,

[TLE]

Thanks for the response.  I have already applied the LabVIEW 8.0.1 update and mass compiled.  The problem I am having is similar to that described in the knowledge base but not the same.

I have a vi in my plugin llb that calls mean.vi, which is part of vi.lib (now in a locked project library in LabVIEW 8).  If my main application, which has been built into an exe does not call mean.vi, the plugin vi works correctly.  If I place mean.vi on the diagram of the main application and re-build it into an exe, the plugin vi fails with a "1003" error.

The vi.lib vi's are being found.  The problem occurs when the executable contains a vi.lib vi that is also used in a plugin vi.

[Dynamik]

Hi TLE,

      The attached VI simply opens a VIs Front Panel.  I check for errors after a dynamic call, and run this if there's an error.  By opening the FP of a VI one can click on the broken-arrow and get valuable error detail (even in a run-time environment.) 

Cheers.

Message Edited by Dynamik on 05-02-2006 09:54 PM

[TLE]

When I open the vi in runtime, it comes up with a broken arrow.  When I click on the broken arrow I get the attached error message.

[Dynamik]

LOL! ... well that wasn't much help.  I found this on error -2002220 - does it sound familier?  Perhaps a reference to an undefined signal (undefined on the target machine.)

FYI: When the problem is missing type-defs, or DLLs, it will list them - which is very nice.