From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

System subvi not located

Solved!
Go to solution

Hello. We are trying to execute some vi.s our colleagues wrote (Labview 7.1, both of us). There is this problem with one "a.vi": whenever it is opened, three situations might happen:

 

1. Pop out the below loading warning  concerning "Config Data Get Key Value", "Read Key.vi" called in "a.vi" (that  .dll is a user-generated library made by our colleagues using Labview)

 

2. Many of the "Config Data Get Key Value", "Read Key.vi" in the block diagram were replaced with question mark.

 

But this vi can actually run.

 

Next, when we try to open and run "b.vi", which includes "a.vi" as a subvi, upon loading it pops out the same warning message, and won't run. The error message indicated "a.vi": subvi not executable. And when I open "a.vi" from "b.vi", it cannot run.  The error message indicates that all those question-mark "Config Data Get Key Value"and "Read Key.vi" subvi's are not executable.

 

After I close everything and reopen a.vi, individually, it becomes workable again.

 

I am new to Labview, and what this seems to me is that the program confuses the location of the subvi's.  But "Read Key.vi" comes from the system path, which really couldn't be missed.  Could anyone enlighten me on this issue ? 

 

(PS: is there any way to specify an absolute path to your included sub vi's ? I could be wrong, it seems that in 8.6 you can easily do it in "call setup", while 7.1 doesn't come with this option.  This may sound desperate, which I am right now. )

 

Thank you very much.

0 Kudos
Message 1 of 2
(2,318 Views)
Solution
Accepted by topic author Xiaolan

It almost seems your b.vi contains subVIs that have the same name as some system VIs, but are loaded from elsewhere (a dll). When you then open a.vi, it will use the VIs already in memory instead of loading from the correct location.

 

If you open a.vi first, the opposite happens and b.vi will be broken.

 

It seems the offending VIs are loaded from a dll built using LabVIEW. Maybe you are missing the correct runtime? Can you show us some code? Maybe you should edit b.vi and replace the dll calls with the correct system subVI?

 

A lot of things have improved in this respect in newer LabVIEW versions. Frankly, I don't remember how these things were handled in the stone ages (LabVIEW 7.1). 🙂

Message 2 of 2
(2,312 Views)