Plugin architecture - problem opening VI by ref

[PA-Paul]

Hi All,

I've been developping an app based on a plugin architecture for device drivers and I've run into a problem. The basic idea is that we have one central application and then we can drop the appropriate intstrument driver packages (.llb) into a directory which then gets queried at run time. It's all been working fine, both in source code and from an executable application. Now, all of a sudden I have one plugin llb which refuses to run from the executable application. It runs with no errors when I run the app from source code (calling the exact same llb file as the plugin).

when I try to run my exe, I get an error saying :

Error 1390 occurred at Open VI Reference in ME Initialise hardware system.vi->Measurement Engine.vi->UMS Project Library.lvlib:UMS_Main.vi

LabVIEW: You attempted to open a VI Server reference to an out-of-scope VI. A VI can open VI Server references only to other VIs that it could call as subVIs. After the reference is opened, that VI can return the reference to other VIs that could not normally open the reference.

VI Path: C:\Program Files\UMS 3.0.2\Device Plugins\Gimbal-PA MK1.llb\GIMBAL-PAServo1-Plugin interface.vi

But calling that exact same llb file from the source code version of the application runs fine. There are other plugins which are called (and written) in an identical fashion, and they work fine. It seems to just be this one.

Has anyone come across anything like this before?

The only thing that makes this plugin different is that it calls a dll file inside it, whereas the others are purely labview based, but from the error I'm getting I can't see that this should be causing the problem?! The error seems to be being generated when labview tries to open a reference to the plugin VI (which is the top level vi of the llb), not when it subsequently tries to run that vi...

I really don't understand this issue, so if anyone can shed any light, I'd be most grateful!

cheers!

Paul

[Ton Plomp]

What application ref did you provide for the 'open VI ref'?

And the error code looks like you provided a VI that is the parent of the VI trying to open the reference.

Is the plugin VI a 'private' VI for a given library?

Ton

[PA-Paul]

Hi Ton,

Thanks for the reply.

I actually didn't wire anything in to the "application ref", should I have? If so, what?

The plugin VI is set as "public" scope in the lvlib where it was created. I also went through and made sure anything it was calling was also public (just to see if that helped) but it made no difference.

The thing that really puzzles me is why it works fine when called from the source code, but not when called from an exe...

Also, why do other plugins made in the same way work fine both from the exe and source code?!

Any suggestions most welcome!

Thanks

Paul

[Antoine Chalons]

We're having a similar problem with a plug-in we made for Vision Builder AI, Vision Builder is a LabVIEW exe made by NI and in LabVIEW 8.5 there is a framework to develop user plug-in.

The issue I have is a bit different because the plug-in works fine with the exe only if LabVIEW dev system is installed on the computer, if it's not the plug-in won't work and VBAI will not give any error message. We have someone at NI investigating that issue, I'll let you know if when we get a solution.

[Mark Smith]

This sounds similar to a problem I had (about LV 8.2/8.5 - that's the latest version I was using when I worked on that project) so this info might be useful. What happened is that the exe had a call to some public member of a lvlib. So the exe build, in the interest of keeping the size down, only included the lvlib members that were called and also modified the lvlib "table" or whatever keeps the lvlib info in the executable to only include the members actually called. Then, when I included members for the same lvlib in an llb called dynamically, the exe had already read a lvlib "table" that did not include the members in the lvlib in the llb and decided that those members called were not part of the lvlib and threw a similar error. It was the kind of error that will make you absolutely crazy, since it requires knowing how the exe builder treats the lvlibs. The "fix" was to explicity include all of the lvlib members in the exe build so that "table" would recognize the ones in the dynamically called llb. Kind of breaks the "plug-in" concept since you have to know when you deploy your exe everything you might call in the future that's in a lvlib. I don't know if newer LV versions treat this the same way.

Mark