VI seen as not executable from LV runtime, correct in LV development

[jjd]

My current problem is the following:

On the same PC, having TestStand 4.0 & LabVIEW Development 8.5, I try running a sequence with both adapters: LV development 8.5 and LV runtime 8.5.

My sequence steps call VIs that call subVIs in a full hierarchy (let's say 1500 VIs are involved in a test sequence).

The sequence runs with the development adapter, and with the runtime, I got a -18002 LabVIEW error: Vi not executable, broken, etc.

Of course, when I open the VI within the development environment, everything is correct.

As I'm testing both adapters on the same PC, the full hierarchy, including LV libraries provided with LV development are at the same location.

Due to the large amount of VIs I use, I cannot guess which LLB could be missing or not inaccessible.

Is there a way to investigate the cause, despite the fact that everything is correct under the development environment?

Is it possible to tell the LV runtime where it should search for LLBs or other required dependencies that the LV development seams able to find?

Thanks in advance for your help,

JJD

[jjd]

In addition:

I forgot to say that I'd prefer not "deploying" my VIs into a linear SubVIs LLB, because some of my subVIs, anywhere in the hierarchy, unfortunately acces data files (.txt, .ini or .xls) with relative (to them) paths.

So I wish to keep my full hierarchy (nothing and nobody is perfect!)

JJD

[Mathieu_R.]

Hello,

I've seen this error when two VIs withthe same name were loaded in memory; this VI was called from a TestStand sequence and from the user interface (very poor design of a customer that I will not mention ^^).

I'm not sure to understand youy problem: everything works fine when you are using Developpment system (Active Version 8.5) but, do you have this error when you set the adapter to LabVIEW Run-Time Engine 8.5, right? Are LabVIEW and/or VIs used in your sequence open when you run your sequence in Run-Time mode?

Cordially,

[jjd · Accepted solution]

Yes it was a problem of subVIs sharing the same name (someone has copied and customized a part of code).

After code cleanup and a mass compile everything is back to normal..

Note: the problem appeared with LabVIEW and VIs closed before running the sequence in both cases.

Thanks for your help.