error 1124 VI is not loadable

[Adnan]

SITUATION

Labview 7.1.1 Run Time Engine

OS : Linux Redhad WS4 or Mac OS X (we don't have time to really test it on WinXP, but it would be done soon)

Machines : Dell Bi-Xeon 3Ghz 1GB and Apple G5 Dual 2.5Ghz 1GB.

Application : ~2000 VIs, with lot of dynamic launches of parallel processes (VIT instanciation). Every 10 seconds, 4 processes are launched and destroy themselves after 7 secondes.

PROBLEM

Error 1124 appears randomly on Open VI Reference for instantiation of process VIs (it take between ~20 minutes and 24 hours~to happen). We try to handle this error by filtering and re-trying the launch but the application crash with a "memory.cpp in line 1038".

From LabVIEW General Error Codes page we have Here :

"VI is not loadable. In a built application, this error might occur because the VI being loaded was last compiled for a different OS, in which case you must save the VI on the current platform. This error also might occur if the VI is a polymorphic VI, which cannot be loaded in the LabVIEW Run-Time Engine. You must load an instance of the polymorphic VI instead of the polymorphic VI itself."

We have done a mass compile of all VI hierarchy before building application, and our process VIs are not polymorphic.

Some weird think seem to happen with intensive use of VI Server and multi-threading in LabVIEW. It remind me an another problem we have here (NI is aware of this bug but not resolved today), and I've seen something similar on this page.

Someone know what is really mean or ever seen this kind of problem?

[sib592]

SITUATION

Labview 7.1.1 Run Time Engine

OS : Linux Redhad WS4 or Mac OS X (we don't have time to really test it on WinXP, but it would be done soon)

Machines : Dell Bi-Xeon 3Ghz 1GB and Apple G5 Dual 2.5Ghz 1GB.

Application : ~2000 VIs, with lot of dynamic launches of parallel processes (VIT instanciation). Every 10 seconds, 4 processes are launched and destroy themselves after 7 secondes.

PROBLEM

Error 1124 appears randomly on Open VI Reference for instantiation of process VIs (it take between ~20 minutes and 24 hours~to happen). We try to handle this error by filtering and re-trying the launch but the application crash with a "memory.cpp in line 1038".

From LabVIEW General Error Codes page we have Here :

"VI is not loadable. In a built application, this error might occur because the VI being loaded was last compiled for a different OS, in which case you must save the VI on the current platform. This error also might occur if the VI is a polymorphic VI, which cannot be loaded in the LabVIEW Run-Time Engine. You must load an instance of the polymorphic VI instead of the polymorphic VI itself."

We have done a mass compile of all VI hierarchy before building application, and our process VIs are not polymorphic.

Some weird think seem to happen with intensive use of VI Server and multi-threading in LabVIEW. It remind me an another problem we have here (NI is aware of this bug but not resolved today), and I've seen something similar on this page.

Someone know what is really mean or ever seen this kind of problem?

I am currently having this problem on the 9012 crio and am running Vista. Does anyone know if this issue has been resolved or how to fix/work around it?

[Antoine Chalons]

I am currently having this problem on the 9012 crio and am running Vista. Does anyone know if this issue has been resolved or how to fix/work around it?

Hi,

You are digging out a fairly old post (17 fev 2006)... Can you tell a bit more about what you are doing.

Apparently you're trying to launch a VI dinamically, and this VI for some reason is not runnable.

Is this VI part of an llb?

Do you try to launch it from an EXE you developped in LabVIEW or from some code that hasn't been compiled?

A thing that can help you figure out the issue is doing this :

Hope this helps

[sib592]

Thanks for the response.

To answer your questions. Yes it is the main vi within an llb that I'm trying to read. The code is being launched from an rtexe located on the 9012 crio. This same code is used in an exe and has never had a problem. The llb is located in the same directory as the rtexe. The path is passed into Open VI Reference as you show above and this is where the error 1124 shows up. Is there something different that needs to be done for the rt build? I couldn't find the VILinkerErr property you have shown.

[Antoine Chalons]

Thanks for the response.

To answer your questions. Yes it is the main vi within an llb that I'm trying to read. The code is being launched from an rtexe located on the 9012 crio. This same code is used in an exe and has never had a problem. The llb is located in the same directory as the rtexe. The path is passed into Open VI Reference as you show above and this is where the error 1124 shows up. Is there something different that needs to be done for the rt build? I couldn't find the VILinkerErr property you have shown.

How do you build your plugin llb?

Since your plugin is called on a RT target, you need to make sure each VI used in the plugins will be found at run time so you should try to include user.lib, vi.lib, etc when you build your plugin llb.

To be find the "VI Linker Error" you need to install and activate the LabVIEW API : see here.

Hooe this helps

[Mellroth]

Thanks for the response.

To answer your questions. Yes it is the main vi within an llb that I'm trying to read. The code is being launched from an rtexe located on the 9012 crio. This same code is used in an exe and has never had a problem. The llb is located in the same directory as the rtexe. The path is passed into Open VI Reference as you show above and this is where the error 1124 shows up. Is there something different that needs to be done for the rt build? I couldn't find the VILinkerErr property you have shown.

Are you loading the same llb in both the exe and the rtexe?

If you are, the code you are trying to load is in the wrong format for the rtexe.

To get around this, add a source distribution build script for the top level VI, on the same target type as your rtexe (in this case a cRIO 9012).

Let this build script create a llb for you and be careful to include any specific HW drivers in the build, and check the Additional exclusion page to include/exclude other items.

Once built, you will have a llb (and possibly a data folder with support files) with code specifically for the cRIO 9012 target. Try to put this llb and its data folder on the 9012 target instead.

Good Luck

/J