I thought this had been fixed before LabVIEW 8, but up until now I'd never had a need to check:

I've got an executable that I've created, and in the spirit of modularity, I'd like to call a VI that is completely external to the exe - it wasn't included anywhere in the build. I use a strict-type call to trawl through a folder with a bunch of VIs in it until I find one with the correct connector pane (an old trick I got from the AAD course a few years ago), and then try to load it. Sure enough, I get a "Error 1003 occurred at Open VI Reference - The VI is not executable." - only VIs that I include in the build (even if they aren't referenced by any other VI) will load properly.

Again, I thought I saw a way around this a while ago - can anyone please enlighten me?

I remember going down this path as well. It seemed like you were ok if you had the LabVIEW development environment on your computer, but if not it became a real hassle. This technique is useful for plugin's which is probably how you are using it. When I tried to get around the problem of having to have the LabVIEW development environment on the machine with the EXE I had to make the "plugin" into an EXE itself, then rename the EXE to an llb, then extract the file out of the LLB using LV, then place it in the folder of interest on the non-LV development machine. If it sounds complicated, it is. I don't remember if I get this technique to work correctly, but I abadoned it because it was quite a bit of hassle for the work I was trying to accomplish.

Surely there is a better way...

Chris

Good point - my test machine has the LabVIEW dev environment on it, but I still can't get it to work - and the final install probably won't have LabVIEW on it
Are you suggesting that building a VI in with a generic exe and then copying it out of it again works? you're right - that's nuts! I wonder if that means that there's some sort of flag in the VI that determines if it's been "built" or not...
Anyone from NI care to chime in on this one? (pleeeeeeeeease?)

Hmm... too bad that CLA courses do not teach how to solve problem.

Easy to think it's a bug, but it may not be, you are missing subvis (I will explain below).

[Advertisement ON]
Well, I have figured this out and have been using this plug in technique for quite a FEW years. This plug in technique especially has been intensively used in IVision callback vis and our standalone end application (only LabVIEW runtime engine needed) that uses IVison and data acquisition dynamic called engines etc. Our applications (this and this) have been distributed in different countries with different local languages without problem.
[Advertisement Off]

Make the EXE only for the top level vi, you don't need to include dynamic called vis. Then make a llb for all dynamic called vis, then save the dynamic called vis out of the llb in a folder. And of course your top level vi should point to the right path where these dynamic called vis are. I guess (I am not NI, so guessing) you got error message because your dynamic called vis are broken because couldn't find some subvis. LabVIEW runtime engine does not know where to search for subvis, unlike development environment.

Irene

I use the plug-in architecture with executables and it works as expected. It is important that the whole hierachy of the VI be accessible and that the executable installer has correctly installed the required resources (serial, math lib, etc.) I usually do that by Save with option>Application distribution. It saves a lot a VIs that may already be in the app.exe but it is harmless.

If you can give more details on how you proceed maybe we might find the source of the problem...

I specifically don't want to include my plug-in VIs in the distribution with the executable - I want to call them by name and path only.


Very droll Irene (or, at least, I think you're being droll - you forgot to add a smiley to the end of that sentance )


Hmmm - that's just crazy enough to work! My VIs do have subVIs, and I thought that the implicit internal location that is saved within the VIs that I call would be enough to load in the subVIs too... Thanks - I'll give it a shot!

Ok,

I think what JP Drolet is saying is that you have to make sure you have all the support libraries (whatever they may be) for your plugging VIs. One way to do that is to actually try to do a source distribution of your plugging including everything (VI.lib etc...).
Your plugging VIs dont have to be part of executable distribution.

PJM

Ahhh - I see: thanks for the clarification. The reason I was confused was that I did have all of my support libraries available - opening a plug-in VI with subVIs worked fine under LabVIEW, and after a couple of experiements, it looks like the very talented (and lovely I might add) Irene looks to be on to something - it looks like the VIs loose their link to their subVIs, resulting in the error message. I'll try a few more experiments tomorrow to confirm that having a VI in the same folder/llb as its' subVIs works - like a flat structure - stay tuned

LabVIEW knows where vi.lib, user.lib and instr.lib are located but the executable does not. It expects these folders to be in its own application folder. A VI that opens fine in LabVIEW will be broken in your application when subVIs are located in these special folders. They are special in the sense that the path of subVIs located there are stored as symbolic path ( e.g. <userlib>\path\to\sub.vi ) so subVIs are found wherever these libs are located in a particular installation. Other subVIs paths are stored in the caller as relative paths so any changes in relative paths to subVIs will also break the VI. When the VI is opened in an application, all subVIs must be at the symbolic/relative path they are expected or the VI is broken.

That's why saving for application distribution solves the path problems, saving the whole hierarchy at the same place and relinking VIs to the new location.

Since the process might duplicate subVIs (both in application and plugin llb) now when the application opens the plugin VI where the subVIs be loaded from?
First the memory is looked for a VI with the same name. If not found there the internal LLB of the apllication is searched for a VI with the same name. If found there the actual path of the subVIs is ignored and the internal VI has the precedence to be opened. If not found in the internal LLB, the subVIs is looked at the stored relative/symbolic path. Finally, when the subVI is not found, the search paths specified in the search path list (in the options) are searched (the seaurch path can be stored in the app ini file)

Indeed in my first post I didn't mean that the plugin VI to be distributed with the application and its installer but just dropped in a folder where the application will look for plugins.

I hoped you solved the problem, and not that this helps but I ran into a similar problem with my dynamic loader that I use on lots of test setups. But it occurred on just one customer computer and no other computer so that I could duplicate what was going on. I could not see anything obvious, and so on just that one system I included a bunch of subvi during initialization and the problem seemed to go away. I was convinced there was something about the early version of Win XP on that system but not exactly sure on that. That was LabVIEW 7.1 and probably the first XP released.

Thankyou



Well, I've finished doing some tests, and sure enough - it's all about location location location! As long as your plugin VIs and all of their subVIs are in the same flat location (irrespective of whether it's one big folder or an llb) then it works! As soon as you have a plugin VIs or one of its' subVIs refer to a VI that's outside of that location (even if it's in a subdirectory), then the plugin is toast: "Error 1003 occurred at Open VI Reference - The VI is not executable."

I am using a similar approach in LabVIEW 8 and am also getting a "1003" error. Here is a thread regarding that issue:

http://forums.lavag.org/Plugin-Architecture-VI-Name-Collisions-t3136.html

The error occurs if a vi in my plugin and the main executable both call a vi that was from vi.lib. I think it has something to do with the fact that the vi's in vi.lib are now bundled together in locked project libraries.

I can open the plugin vi without any errors in development but get a broken arrow in runtime. The error message is attached when I click on the broken arror in runtime.

This post has been edited by Tim Erickson: May 4 2006, 03:52 PM