Error 1003 after building application

[BenD]

Hi everyone,

I'm building an application with a plug-in architecture that calls VIs not built with the application dynamically. The app builds and runs just fine, but when I get to the part of the executable that starts calling the VIs, the application seems to choke on opening them and spits back an "Error 1003" from the Open VI By Reference.vi (I think that's the name, anyway)

This architecture has worked fine in the past but I've inherited this code and it's the first time I've tried to build the application as there have been some minor changes to the VI that the executable is built from. These small changes are also not ones that would cause this error to occur.

I do remember the previous owner of the code going through considerable trouble getting it to work as an exe but I'm not finding their notes to be enough of a help to get it up and running. Has anyone worked with this kind of architecture before?

Thanks!

[Neville D]

QUOTE(BenD @ Mar 21 2007, 12:26 PM)

Hi everyone,

I'm building an application with a plug-in architecture that calls VIs not built with the application dynamically. The app builds and runs just fine, but when I get to the part of the executable that starts calling the VIs, the application seems to choke on opening them and spits back an "Error 1003" from the Open VI By Reference.vi (I think that's the name, anyway)

This architecture has worked fine in the past but I've inherited this code and it's the first time I've tried to build the application as there have been some minor changes to the VI that the executable is built from. These small changes are also not ones that would cause this error to occur.

I do remember the previous owner of the code going through considerable trouble getting it to work as an exe but I'm not finding their notes to be enough of a help to get it up and running. Has anyone worked with this kind of architecture before?

Thanks!

First thing to check would be the paths to the plug-in VI's. You might need to double-strip the path for the exe and only single strip to get at the VI in the dev. environment.

Put an indicator up on the main VI so you can see what path its using.

Neville.

[PJM_labview]

QUOTE(Neville D @ Mar 21 2007, 12:35 PM)

...Or how about trying the nifty new LV 8x feature of being able to debug executables?? (Haven't tried it myself..)...

I have and this is a nifty feature that can save you a lot of times (an it is perfect for this kind of situation when everything work in the IDE but not in the deployed build). Of course this assume that you are trying to build in LV >= 8.0.

Did you import this project from another LV version? If so NI might have inserted some compatibility VI in your plugins and when invoked from the build framework, they fail.

Also, are your plugins "build" (for example as an llb) separately?

Anyway, please give us more info.

PJM

[BenD]

QUOTE(Neville D @ Mar 21 2007, 03:35 PM)

First thing to check would be the paths to the plug-in VI's. You might need to double-strip the path for the exe and only single strip to get at the VI in the dev. environment.

Put an indicator up on the main VI so you can see what path its using.

Or how about trying the nifty new LV 8x feature of being able to debug executables?? (Haven't tried it myself..)

Neville.

Thanks for the quick replies! As far as the paths go, they're relative to the location of the exe. What I'm seeing is that it looks like the exe finds the plugin VIs just fine, but for some reason the VIs are not seeing some/all of their subVIs and controls. This is strange to me, because if I run the VIs on their own without the exe they work just fine. I'll take up your suggestion of using the debug feature - I saw this during the build but have yet to look into it more. Thanks again!

QUOTE(PJM_labview @ Mar 21 2007, 04:37 PM)

I have and this is a nifty feature that can save you a lot of times (an it is perfect for this kind of situation when everything work in the IDE but not in the deployed build). Of course this assume that you are trying to build in

LV

>= 8.0.

Did you import this project from another

LV

version? If so NI might have inserted some compatibility VI in your plugins and when invoked from the build framework, they fail.

Also, are your plugins "build" (for example as an llb) separately?

Anyway, please give us more info.

PJM

This project was imported from 8.0 to 8.2, so you may have something there. I'll do some more digging and play with the debug feature a bit. My plugins are just normal VIs (not llb) and not "built" at all. In the IDE, everything runs smooth as butter so there's definitely something funky going on with the exe that I'm not seeing.

[Mellroth]

QUOTE(BenD @ Mar 22 2007, 12:14 PM)

Thanks for the quick replies! As far as the paths go, they're relative to the location of the exe. What I'm seeing is that it looks like the exe finds the plugin VIs just fine, but for some reason the VIs are not seeing some/all of their subVIs and controls. This is strange to me, because if I run the VIs on their own without the exe they work just fine. I'll take up your suggestion of using the debug feature - I saw this during the build but have yet to look into it more. Thanks again!

Have you tried making a developer distribution of the VI you want to call dynamically?

I've seen error 1003 when the dynamic VI hierarchy contains VI.lib/user.lib files not compiled to the exe, e.g. if the exe does not contain any timed loops, but the dynamic hierarchy do.

/J

[Chris Davis]

What you are seeing is the fact that your plugin VI's can't find the vi.lib files it needs to execute. You'll have to package your plugin's as LLB files using either the OpenG Builder (what I reccommend, particularly since you will probably need "name mangeling") or the NI application builder. Basically an EXE doesn't have access to vi.lib, and the application builder only includes the vi.lib files your exe needs to run. BTW, when you build your plugins, either in the OpenG builder, or with the NI Application Builder, you will have uncheck the option to exclude vi.lib files, user.lib files, and (possibly) instr.lib files. There has been discussion on this topic elsewhere on LAVA before, but I can't find it right now.

[BenD]

QUOTE(chrisdavis @ Mar 22 2007, 08:49 AM)

What you are seeing is the fact that your plugin VI's can't find the vi.lib files it needs to execute. You'll have to package your plugin's as LLB files using either the OpenG Builder (what I reccommend, particularly since you will probably need "name mangeling") or the NI application builder. Basically an EXE doesn't have access to vi.lib, and the application builder only includes the vi.lib files your exe needs to run. BTW, when you build your plugins, either in the OpenG builder, or with the NI Application Builder, you will have uncheck the option to exclude vi.lib files, user.lib files, and (possibly) instr.lib files. There has been discussion on this topic elsewhere on LAVA before, but I can't find it right now.

Thanks for the clarification - this is exactly what I've been thinking the problem was, it's just that I know for a fact that there's a way around it but it's not easy!

[Mellroth]

I read Chris post, and realized that I was a bit unclear in my previous post, thanks for the clarification Chris :thumbup: .

I was trying to examplify that you could get the error 1003 ,when trying to call a dynamic VIs without a proper development distribution, i.e without necessary supportfiles.

QUOTE(chrisdavis @ Mar 22 2007, 01:49 PM)

...You'll have to package your plugin's as LLB files using either the OpenG Builder (what I reccommend, particularly since you will probably need "name mangeling") or the NI application builder

You don't have to use an LLB, it will work by selecting single destination in the Distibution settings as well. If the dynamic VIs calls a DLL or any other external files this might be a better (the only?) option IMHO.

If the dynamic VI uses any functional global to share data with the main application, be careful with the "name mangeling".

/J

[PJM_labview]

QUOTE(BenD @ Mar 22 2007, 08:21 AM)

Thanks for the clarification - this is exactly what I've been thinking the problem was, it's just that I know for a fact that there's a way around it but it's not easy!

If you do not want to build your plugin (source distribution of some sort), the only sollution is to make sure that each plugin contain only primitives (no SubVI calls of any kind).

PJM

[BenD]

Thanks for all the responses, and it looks like I've found a solution: ditch 8.2 and go back to 8.0.1. The previous build works just fine with this architecture but as soon as you pull it into 8.2, recompile and rebuild, it breaks down again. We'll just have to roll back our work since we upgraded and move forward with 8.0.1. Turns out this is a known issue with no real fix if you read through the upgrade issues when going from 8.x to 8.2: http://digital.ni.com/public.nsf/websearch...DE?OpenDocument

Thanks again!

[JohnRH]

Hi,

After beginning to wonder if there is some kind of evil LabVIEW gnome trying to mess with my head, I found this thread and think the light might be starting to turn on - or at least flicker. (for some reason I am having a really hard time getting my head around this problem)

I'm in a situation where I am dynamically calling a rather complex vi, which has several layers of sub-vi's. If I am understanding the posts to this thread correctly, I am going to need to either make the dynamically called vi flat (no sub-vi's), or else build some kind of source distribution. (am I missing something, or shouldn't this be considered a bug?)

With much difficulty, I guess I could 'flatten' the vi, but the amount of work to do so makes me very interested in the second option - building something.

Finally to the questions. Do I build a source distribution which contains only the dynamically called vi? To do this, do I need to create a new project which only contains the dynamic vi? (am I even headed in the right direction?)

Sorry for the ignorant questions. Any guidance is GREATLY appreaciated here!

Thanks!

John

[Ton Plomp]

QUOTE(JohnRH @ Apr 30 2007, 08:57 PM)

I'm in a situation where I am dynamically calling a rather complex vi, which has several layers of sub-vi's. If I am understanding the posts to this thread correctly, I am going to need to either make the dynamically called vi flat (no sub-vi's), or else build some kind of source distribution. (am I missing something, or shouldn't this be considered a bug?)

No it's not a bug.

A VI will first look which VIs are already in memory, if not look at their locations as they are stored in side the calling VI, now an exe has no <vi.lib> or <user.lib> or <instr.lib> which are really the only 'virtual' paths inside LV.

If your VI is called from within the same LabVIEW Development envirenment and the VI (or it's subs) haven't moved their shouldn't be a problem!

Their is quite an easy way to build a distribution where everything is completely independent of vi.lib!

Build a source distribution, select 'Single destionation' (is LLB if you want to move it around easily), in the Additional exlusions select 'Remove as much as possible' and deselect the lower three options

Again OpenG builder is a great tool to avoid these issues!

Ton

[JohnRH]

QUOTE(tcplomp @ Apr 30 2007, 03:33 PM)

No it's not a bug.

A VI will first look which VIs are already in memory, if not look at their locations as they are stored in side the calling VI, now an exe has no <vi.lib> or <user.lib> or <instr.lib> which are really the only 'virtual' paths inside LV.

If your VI is called from within the same LabVIEW Development envirenment and the VI (or it's subs) haven't moved their shouldn't be a problem!

Their is quite an easy way to build a distribution where everything is completely independent of vi.lib!

Build a source distribution, select 'Single destionation' (is LLB if you want to move it around easily), in the Additional exlusions select 'Remove as much as possible' and deselect the lower three options

Again OpenG builder is a great tool to avoid these issues!

Ton

Looks like I'm going to have to familiarize myself with OpenG builder! (I've often wondered what advanatages it had over the regular NI App builder.) In the mean time, it suddenly dawned on me that there is no reason I can't build the dynamic VI into it's own executable and launch it from the main app as a system command. (the vi is just a stand alone UDP server) At least for now this gets things working.

Thanks!

John