error 1003 when using call by reference

[RobBoyer]

Hello,

I'm trying to implement a late-bound call to a pluggable subVI from within a built executable.  So my initial stab was to use call by reference and at run-time pass the name of the actual VI that should be executed.  This works at run-time, but results in error 1003 when compiled into an executable.  I am aware that I can fix this by adding all of these pluggable subVIs as dynamic VIs in the application builder - but that defeats the purpose of having pluggable subVIs.  I am hoping there is some way to accomplish this, but I'm beginning to think this may be a true limitation of LabVIEW...  Does LabVIEW really not support this kind of late-binding behavior?  If there is no simple work-around, does anyone have any suggestions for other approaches I might try?  Perhaps if the pluggable subVIs are compiled into DLLs, I can skirt this issue using a library function node?

Anyway, any suggestions will be greatly appreciated.  Let me know if anything needs clarification.

Rob

[RobBoyer]

::bump::

Anyone?  I would have expected this to be a fairly regular question in the forum, but I can't find anything.  Even a simple confirmation that LabVIEW doesn't support this would be useful.  Thanks,

Rob

[smercurio_fc]

This actually has bee brought up before. This thread talks at some length about a plug-in architecture similar to what you're trying to do.

[RobBoyer]

Thanks for the pointer.  I read through the thread, but I'm still a bit confused.  From the thread, it wasn't clear to me how (or even if) the main application was working around needing to build the plug-ins into the executable.  I already have a working scheme for how to enumerate all the "plug-ins" and call them based on a configuration.  But, in order for it to work from the built executable, every plug-in subVI needs to be built into the executable.  Therefore, whenever a new plug in is created, I have to re-build every application that uses this mechanism.  It isn't a show-stopper at this point, but it certainly isn't robust.

If there is some mechanism that can be used to accomplish this, please help me understand.  Maybe I just didn't get something in the thread.

Thanks for you help,

Rob

[smercurio_fc]

You do not need to have the plug-ins built into the executable. I'm not sure how you have your setup, but I've attached a simple example project using a plug-in architecture, where the plug-ins are separate VIs that are in the directory with the application.

[RobBoyer]

Thanks very much for taking the time to do that, but would it be possible for you to convert it to LabVIEW 7.0?  I'm not able to open up any of the files...  Or maybe even just a basic description of how the build is managed and how the plug-in call is made?  I'm using call-by-reference and it always returns error 1003 if I attempt to call a subVI that wasn't declared in the build script as a "dynamic VI".  I am assuming that the build script requires this because the VI is built into the executable.

Rob

[smercurio_fc]

Unfortunately, I can't back-save to 7.0. Perhaps someone who has 8.0 and 7.1 can back-save the code. The structure is pretty straightforward. The Main VI just has a few buttons to call individual plug-ins, and each button activation calls a "Call Plugin" VI like this:


The Call Plugin VI looks like this:



The little VI with the anchor symbol resides at the same level as the Main VI and returns the correct path based on whether it's running in the development environment or the executable environment. It looks like this:



The build just has the Main VI, the Call Plugin VI, and the Anchor VI. That's it. The individual plug-in VIs are simply copied to the same directory where the executable resides.

For 7.0 you may want to take a look at this second example.


Message Edited by smercurio_fc on 04-10-2008 10:42 AM

[RobBoyer]

Hello again,

Thanks for the info.  It looks like the problem is different in my case then.  It sounds like it is related to shared subVIs similar to the thread you pointed me to earlier.  I was under the impression that it may be a limitation due to this KB article: http://digital.ni.com/public.nsf/allkb/410F2EC66F60F9B0862569EE006F4FA0.  It makes it sound like there is no way to accomplish true plugin functionality.

Anyway, I was able to get the simple example (and a simple test one of my own) working based on your responses, but I'm still struggling with getting my actual executable working correctly.  Based on what I've read so far, it sounds like there may be an issue with shared subVIs that are needed by my plugins being already loaded by my executable.  For example, say I have a subVI, "A.vi", which is used by the main executable and some or all of the plugins.  When I build the executable, it loads A.vi into the executable.  Then when it attempts to load the plugin, the discrepancy between the location it expects this subVI to be at, and the actual location (within the exe) causes error 1003.  Do this sound correct?  And if so, does this mean I have to make separate copies of all of these subVIs?

From the other thread, it sounds like they were recommending creating a whole separate copy of all dependencies all in a separate "namespace" (I assume that means from the LabVIEW 7.0 perspective - rename every single VI).  This could include a ton of code, much of it vi.lib code that I'd rather not duplicate.  Let me know if I'm missing something - this seems like an extremely tedious solution.

Thanks,

Rob

[smercurio_fc]

Unfortunately, shared VIs cause a problem, and that's pretty much what you're seeing. With 7.0 you're quite limited in what you can do since 7.0 doesn't have projects. That was something that was introduced with 8.x. However, as the thread alludes to, there were still a few hiccups when dealing with shared VIs. As far as I can see, with 7.0 the only practical thing you can do is to have two copies of each shared VI. One that gets loaded by the executable, and the other that gets loaded by the plug-in VIs. One thing that may work with 7.0 is to build the plug-ins into a DLL. I don't have 7.0 so there's no way I can test this.

[RobBoyer]

I've been trying to reproduce the problem with as simple code as possible, but I haven't actually been able to yet.  The reason I bring it up is that I'm afraid there must be some subtlety that I still don't understand.  I'll attach the simple program I've been trying to reproduce the issue with.

Basically, I have a VI, "DynamicCaller.vi", which is the main application VI.  It calls "DisplayString1.vi" and "DisplayString2.vi" dynamically based on user input.  TestMessage is used in both the VI that gets compiled, as well as DisplayString1 which does not.  I figured this should introduce the inconsistency that was causing me to get error 1003.  But alas, everything works fine!  ???  I guess there must be some other issue or complication that is causing the fundamental problem I'm seeing...  Any ideas?

Thanks.