LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

moving a VI breaks subvi paths

Here is some action I recently ran into that strikes me as rather peculiar.

 

Lets say I have a directory structure like this:

 

C:\Projects

    \BoardA

        \Test1

            TestCom.vi (has some subvi's from C:\Projects\Reuse

    \BoardB

        \Test1

            TestCom.vi (has same subvi's as above)

 

Both TestCom.vi files are identical.  So I want to move them to a common place that can be accesses by code running tests on BoardA and BoardB and future boards.  So I move one of the TestCom.vi files to C:\Projects\CommonTests.  I'm going to call the vi from that location from any Board test vi.  Well when I move it, some of the subvi paths are broken.  When I open the file in the new location, Labview searchs for the subvi in a path that does not exist (usually has some subdirectory missing from the path), and it asks me to locate the vi.  This is fine and dandy, but there are many subvi's with broken paths and there are about 50 common VIs that I want to move.  I don't want to spend time opening each of the 50 VIs and relinking each subvi over and over again.

 

Here is the peculiar part.  If I move the VIs to a path that has the same number of levels as the originals (like C:\Projects\CommonTests\CommonVIs\TestCom.vi, then the subvi links are OK.  I don't have to do anything.

 

Why do I have to create a directory structure with the same number of levels?  What happens if some of my common VIs lie in directory structures with different numbers of levels for different projects?  This is really odd.  It is worse if I try to manage it from the Project Window.  I get all kinds of conflicts and they can't be resolved (greyed out buttons to Load With Selected).

 

HELP!!!!

 

Edit:  Ooops.  I'm using Labview 2010.

 

 

- tbob

Inventor of the WORM Global
0 Kudos
Message 1 of 9
(3,638 Views)

tbob,

I can't reproduce exactly what you are seeing - where the same number of levels solves the issue. Could it be that some of your VI's use the Call Chain function, and are finding subvi's based purely on how many levels "up" they are? That would cause the witnessed behaviour.

Richard






0 Kudos
Message 2 of 9
(3,604 Views)

The best way to move a sub-vi if it's also used is by "Save as ..." and relocate the file. Then references will update automatically.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 3 of 9
(3,599 Views)

I am not moving a subvi.  I'm moving the main vi, and when I open the main at the new location, it can't find the subvi.  The path shown in the search dialog doesn't even exist.  The path is missing one level.  It has nothing to do with call chains because I'm not even running the main vi.  It comes up broken because the subvi path is wrong.  Now I did not move the subvi, just the main vi.  This has happened to me on more than one occasion.  Why would the search path for the subvi change?  Here is another example:

 

Main vi is at C:\Projects\ALS\ALS-100\Tests.   Actually there are many main vi's here that get called by a sequencer.  Notice that there are 4 directory levels here.

Subvi's are located at C:\Projects\ALS_Reuse\Common.  Many subvi's here.  Notice that there are 3 directory levels here.

 

When I move the main vi's to C:\Projects\ALS\CommonTests (3 levels), then all of the main vi's are broken.  When I open them, the search dialog comes up trying to find a subvi at a path that doesn't exist, like C:\Projects\Common (the ALS_Reuse part is missing from the search path, only 2 levels).  It is like if the main vi path is shortened by one level, then the subvi path is also shortened by one level, even though the subvi location has not changed.

 

If I move the main vi's to a path with the same number of levels as the old location, everything is fine.  My fix was to move the main vi's to C:\Projects\ALS\Common\Tests (4 levels like the old location).  Then the main vi's do not come up broken and all subvi links are OK.

 

My question is are subvi paths absolute or are they relative to the calling vi's path?

 

- tbob

Inventor of the WORM Global
0 Kudos
Message 4 of 9
(3,573 Views)

If you do a "Save As" then rename, and just move the VI of choice in that prompt, it will get all the sub-vi re-linking correctly.  I would guess that the VI that you want to move grabs things nearby using relative paths, including some (internally) that look like "..\..\..\Some Other Path"  The Save-as will keep the paths correct through the move.

0 Kudos
Message 5 of 9
(3,569 Views)

@tbob wrote:

My question is are subvi paths absolute or are they relative to the calling vi's path?

 


Internally they are saved as relative pathes. That is why the same number of levels works. If you are working in a project the Save As option is nice for relocating files since the project will update VIs within it. In your case you will probably need to do the "Save As" twice to effectively replace each instance of the common VI. This is because of LabVIEW using name spaces to resolve multiple VIs with the same name. You will have a "Projects A:Test.vi" and a Projects B:Test.vi. Repeat the save as for each call like this.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 6 of 9
(3,567 Views)

@Mark Yedinak wrote:

... In your case you will probably need to do the "Save As" twice to effectively replace each instance of the common VI. ....


So if I have to move 50 main VI's I would have to do 100 Save As.  I think I'll stick with the number of directory levels solution.


 

- tbob

Inventor of the WORM Global
0 Kudos
Message 7 of 9
(3,541 Views)

Sorry if I missed this but...

 

Did you try using a Source Distribution in the project to move the VI?

 

Also...

 

Using the file view in the project what about trying the Move on disk option?

 

RE: sub-VI path.

 

mark is correct that the paths are relative.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 9
(3,537 Views)

@tbob wrote:

@Mark Yedinak wrote:

... In your case you will probably need to do the "Save As" twice to effectively replace each instance of the common VI. ....


So if I have to move 50 main VI's I would have to do 100 Save As.  I think I'll stick with the number of directory levels solution.


 


No, you would only have to do it for however many "Project X\Test.vi" instances that you have. the Save As in the project will update all the VIs that use that particular instance. You may get lucky if you do this for the first instance and then remove all of the other copies from your project. LabVIEW may resolve the missing VI provided it has a VI of that name in memory. It may not though since the project enforces name space rules.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 9 of 9
(3,530 Views)