LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Moving VIs from one folder to another folder

The program that I've written is structured in such a way that I've organized all VIs is folder and subfolders to get things nice and neat....that makes sense I know. After several edits on some VIs, I create a new main folder for the version update and copy all from the previous folders and subfolders into the new version folders and subfolders.
 
My question is.....I've noticed when I do this and run my program from the current version folder some of the VIs that are running are located in the folders from the previous version. I've used the Hierarchy window to display all the VIs with Full VI Path in Label selected from View on the tool bar. This allows me to identify which VI is running but is there an easier way to do this???? Lets say I've got 100 VIs and this means I've got to go in and verify the location of each VI.....any help would be greatly appreciated.
 
tks
0 Kudos
Message 1 of 11
(3,959 Views)

ANy VI that you don't explicitely save in the a new location will continue to load from the old location as specified in the VI. You could close LabVIEW and rename the old folder. Now it will ask you to find all missing VIs. Once everything is loaded, do a "save all" to permanently update the new paths.

What I usually do:

Once you have a final version, you should do a "save with options".

Select "save as development distribution" and select a new empty folder as target. It will contain all VIs used in the project. Close everything, then run it from the new location.

Message 2 of 11
(3,947 Views)

Thanks for the info.....but I've got one more question for you. I'm using LabVIEW Ver 7.0 and could you tell me where I might find the "save as development distribution" feature?

tks

0 Kudos
Message 3 of 11
(3,939 Views)

You first need to select  "(menu)...File...Save with options..".

In the following dialog, select "Development Distribution".

See how far you get... 🙂

Message 4 of 11
(3,938 Views)

Thanks.....I sorta had a brain fart. I forgot that the pull-down menus on the toolbars dont always display all available selections....this was evident by the appearance of the double-down arrow at the bottom of the pull down menu.

 I think I've got it now.....thanks alot for your help and see ya

0 Kudos
Message 5 of 11
(3,917 Views)
There is a tool VIs_in_Memory found here that lists all VIs in memory and their paths. Great to find cross linking.


LabVIEW, C'est LabVIEW

Message 6 of 11
(3,912 Views)


@TCjr wrote:
... I forgot that the pull-down menus on the toolbars dont always display all available selections....
Go to "tools...options...miscellaneous" and uncheck "use abridged menus". Now you always see all menu entries. 🙂
0 Kudos
Message 7 of 11
(3,905 Views)

Just chiming in briefly to say that it IS possible to simply copy a vi hierarchy from one place to another.  This is the technique I've used as a poor-man's (or more accurately, lazy-man's) version control method.  Here's what I do:

1. My top-level vi (or vi's) reside in a particular folder.  My sub-vi's are all located in sub-folders underneath the main folder.

2. KEY STEP!  When my editing is done and I'm sure I've got the overall version that I want to backup / move, I completely exit LabVIEW.

3. Then I use Windows Explorer to copy the entire  top-level folder (including all sub-folders) and paste it wherever I choose.  (When copying to a backup archive, I typically rename the top-level folder to include the date.)

4. Inside the top-level vi, paths to all sub-vi's are stored as relative paths.  So if you now open the top-level vi from the new location, it will automatically be linked to the sub-vi's from the same new location.

Of course, as usual, you also wouldn't go wrong following altenbach's advice.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 8 of 11
(3,890 Views)
Kevin is right, this is a good way if you have a more complex hierarchy.
 
The "save as development distribution" has the advantage that it removes all "buildup", e.g. VIs that are no longer actually used don't migrate to the new location. (Be careful in the case of dyynamically called VIs, though!)
0 Kudos
Message 9 of 11
(3,883 Views)

Adding to all of the previous.

I use a "Tree.vi" to make sure all the VI's in an application are in memory while I am editing.

The Tree VI does not do anything and never runs. It just contains the top level VI's used by the app. Dynamically called and templates are included so that I can use the "Save with options techniques mentioned below.

By working with the Tree.vi open I can tell of any of my edits breal any of the other VI's that I may not notice because they are called dynamically.

In larger app's my top level tree generally consists of a bunch of sub-system trees. The multi-level tree approach lets me easy re-use parts of one application in another. All I have to do is find the tree that contains all of the parts I will re-use and do a Save with....

The Tree also helps when working teams of devlopers. If one developer makes a change that forces another VI to recompile, when the Tree is closed LV will ask if the affected VI's should be changed. As long as the devlopers do NOT hit "save all" they can let the rest of the team know about the need to re-save VI's.

 

Ben

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