What is error of type 2002200

[henry.xie]

I  use lv 8.0 to build a stand alone application.  I didn't found any error message during the build.  however when I deploy the application to a computer without lv installed on it.  I got the following error message: "VI has an error of type 2002200.  The full development version of LabVIEW is required to fix the errors"  .  This error message was not shown up when the computer had lv installed.  Can somebody tell me what is the error type of 2002200 and how to fix this problem?

thx in advance

Henry

[becktho]

Hi Henry

I can't tell you about the error code you mentioned, but basically, if you have built LV application, you have to make sure that at least the LV runtime engine is installed on the target system. In addition, there should also all necessary drivers be installed.

The easiest thing is to create an installer with LV8.0. There you can select additional things to install (e.g. the runtime engine).

[Charlie S.]

Hi Henry,

I think becktho hit the nail on the head. You may want to check out these resources when you are building your installer:

Distributing Applications with the LabVIEW Application Builder

Best of luck!

[peter]

Hello,

 I have got the same message.

I have three executeables. Every executable for itself is working.

When I start my three exes with a loader (using vi server) always the two first exes are running and the last one gives me an error 1003 "This vi is not executeable". Regardless which exe. It is always the third.

The Run button on the Front Panel is broken, when I click it, the message you got is displayed (2002200 Full Development System may solve the problem. Repeated serval times). The text of the error messages is translated by myself since I am using a german version of LV.

When I start the sources (vis) with the loader (also as vi) everything is working.

I am using Labview 8.0.1 with Imaq. All trials were made on the same machine with the whole Professional Development System in place.

If anyone has some Ideas...

[Charlie S.]

Hi Peter,

I tried reproducing this with a simple example (no hardware/drivers), and it worked just fine. Which, of course, begs the question: what's the difference? Can you try it without the IMAQ drivers? I did quick search and found a lot of issues relating to this error code and the IMAQ drivers in .exe's. Maybe that was just a lucky (unlucky?) coincidence, but it's worth a shot.

I also wanted to bring something up in case you're thinking of upgrading. The way we handle exe's and VI Server has changed a little in LabVIEW 8.20, so depending on how you've architected this application it may not work in the new version. If your interested, check out this post on LAVA:

 http://forums.lavag.org/index.php?showtopic=3767&st=0&p=15267&

Hope this helps!

[RGDCX]

Greetings,

I'm a little late to this discussion, but I've just recently installed LabView 8.0 and when I try to create a stand alone executable for another machine, I, too, get the "error of type 2002200" when I try to run the app.  I have installed the V8.0 run time engine and the applicable hardware drivers on the destination machine, but clearly something is missing.  The same executable runs on my development pc outside of the development environment. 

I am looking at doing an installer for this app to see if it makes any difference, but I have no idea what to do with the registry settings.  Is there some help in this area?

Thanks

[Charlie S.]

Hello RGDCX,

It sounds like you have most of what you need on your target machine for your executable to work (runtime engine & drivers), but as you said something is clearly missing. Are you using any LabVIEW modules (DSC, FPGA, RT, Simulation, Vision, etc) or any toolkits (report generation, database, etc)? Many of these require additional steps in order for the executable to function properly. Are you making any dynamic calls using VI Server or using subpanels or ActiveX controls in your VI? Any third party drivers?

Generally speaking, you should not have to worry about registry settings for deployed applications -- only if you use them somehow in your program explicitly. If you've already installed the drivers & runtime engine, you do not necessarily have to create an installer from the build specification -- though, maybe doing so will help catch something you may have missed...

Let me know what you find out & we can go from there -- hope this helps!

[RGDCX]

Charlie,

Thanks for your reply.  I seem to have solved some of the mystery.  The executable only seems to execute without that error message in the directory where it was built.  I changed the destination folder in the build specificaton to the folder name where I wanted to execute it from and it now runs without the error.  It is not machine specific.  I set up the same folder structure on another machine and it works fine there too.

I'm supposing this has something to do with the fact that you are not making the build for distribution? 

[Charlie S.]

Hi RGDCX,

When LabVIEW creates an executable from a build specification, many of the dependencies (if any) will appear in a subfolder "data." This folder will appear whereve the .exe is created. If you move the .exe file to a different folder manually and do not move the "data" folder with it, you could very well confuse the LV runtime engine -- hence the error message. Does any of this sound/look familiar to your application?

If you build an installer for your LabVIEW executable, it will installed the exe and any dependencies for you when you move to a target machine. Of course, you could just as easily replicate the folder structure yourself (as it sounds like you already have done).

Hope this sheds some light on the issue,

[RGDCX]

Charlie,

Thanks again for your reply.  I see the data folder, but the only thing in it is "lvanlys.dll" file with a 10/6/2005 date.  There is a .ini and a .aliases file that get created with each build along with the executable.  Copying those files over did not seem to matter, it seemed to be the path to the executable.  Anyway, I seem to be set for now.