Is there any reason putting my VIs in subfolders will mess anything up? Is there a "path" in LV?

[optoelectro]

Hi, my project is starting to have about a million VIs and it's getting confusing when I need to find one. Right now my VIs are all in one folder, Documents\LabVIEW Data. I'd like to put some folders in the LabVIEW Data folder and reorganize my VIs into those subfolders.

So I have two questions:

1. Will this mess anything up in general? My guess is that it shouldn't matter because when I insert a VI into the block diagram of another VI, I have to select it from its location anyway (in the dialog box), so it should know where it is.
2. Related to that, if I simply move everything around right now, will it mess up VIs that already have VIs inserted in them? I'm more worried about this one because if it expects to find a VI in a given place (the place I selected it from) and then it's moved, I could imagine that causing errors.

Sorry if this is a dumb question, I briefly searched for "labview and path" but couldn't find the answer. thank you.

[Wolleee]

Hi,

Most the time if the VIs are located in the same root folder labview will find the correct subvi when you open the main vi and ask you to select the new path for it. If you are changing them to a completely separete folder then you can go to the files view in the  project, right click and select move on disk, this will ensure you have no path issues.

[Bob_Schor]

A simple, logical, and consistent Style when doing LabVIEW Development is a Good Thing, not to be feared.

Whenever I start a new LabVIEW Project, I do the following steps:

1. Decide where I want the Project Folder to reside.  It is often, but not always, in my "LabVIEW" folder (I don't use NI's default "LabVIEW Data" folder -- I reserve that for the stuff that NI wants to save, but create my own LabVIEW folder in my User "My Documents" folder).  Once I know, I create a folder and name it for the Project (e.g. NeuroBlock).
2. Within my Project folder, before even creating the Project, I create the following sub-folders:
   • Documentation (obvious what goes there)
   • Resources (where .ico files go, by default, and sometimes other things)
   • Data (if I'm going to be saving Data internal to the Project, like "static" Configuration info).
   • Types (for my TypeDefs).
   • Test (for test routines).
   • Obsolete (for routines I want to abandon, but am not ready to "banish" yet -- this folder should ultimately be deleted!
   • Utils (sometimes called SubVIs).  This gets most of my VIs, and might be sub-divided even further, for example DAQmx, Camera, Action Engines).
3. Now I create the Project, putting it at the top level of the Folder (i.e. not in a sub-VI).  I create "Shadow" Project folders that mimic the folder structure I just created (which allows me to make these folders "Auto-populating", but I generally leave this off).  I put the Main (top level) VIs here (plural since I could have a Main and two Support Routines, though if so, I might create a Support folder, as well).
4. If I'm doing a Real-Time Project, then there are top-level Host, Remote, and Common folders that have the above sub-folder structure.

Bob's Rule -- you can't have a (large) LabVIEW Project that is "Too Organized".  Bob's Second Rule (learned from Peter Blume, though he might not want to take the blame) -- "In LabVIEW, Style is at least 75% of the Battle".

Bob Schor

[RTSLVU]

I do it this way.

VIs that I made to use "everywhere" are placed in the user.lib directory. That way they show up in the User Libraries palette.

Projects are put in their own directory with the main VIs for that project in the "root" of the project directory.  

Sub Vis and controls that are project specific are place in a sub directory under the main project directory.

My projects are stored in My Documents-->LabVIEW20xx--->Project name

 

[Ben]

Ditto what Wolleee posted!

Adding to that suggestion...

If you are using dynamically invoked VIs and you do not already have a "Tree.vi" start by creating one.

A "tree.vi" (also called a Catalog.VI by old time Mac users) is a VI that is never intended to run but contains all "top-level" VIs used by the application. It's purpose to to allow you tou to load all of the VIs associated with an application into memory when it is opened and (provided you wire up required inputs on VIs) a way to ensure that all of your VIs are run-able (not broken).

Prior to doing the "move on disk" suggested by Wolleee open the Tree.vi and keep it open as you proceed. Everytime you move a VI, go back the Tree.VI and do a "Save All". That will update any VIs that are calling the VI you moved such that it will now point to the new location. If you fail to update them all, some of the VIs may try to load the "moved" vi in its previous location.

Now if you are going to go through the trouble of rearranging all of the furniture (this is good, thank you for doing so!) may I suggest you go a step further and make it BETTER.

I have grown quite fond of Libraries. They have a lot of benefits. The grouping aspect of a library is obvious but closely following the grouping is the "Name mangling" that you get with a Library. "Name Mangling" is a term that speaks to the fact that all VIs in a library get their names prefixed with the name of the library in which they are found. This lets you use common names for similar VIs in different Libraries. It shortens the name and eliminates the archaic practice of prefix VI names to keep the names all unique. The prefixing does that work for you.

Another benefit of the library is the ability to specify public and private members of a library. I use public scoping for VI that are suitable to be called from VIs outside the library and private to ensure the VI that are intended for special functions inside the library can not be dropped on a diagram of a non-member of the library. The public vs Private settings makes it easier for others that want to use your library to limit their search to only those VIs that were developed for public use.

But the benefits do not end there!

Once you have a good library that does what you want, it can be easily "cloned" by using the "Save Library as..." option. Once performed the entire Library will be cloned off, and a new set of VIs created with the right linking of sub-VIs with no danger of cross-linking to the old files.

Once a library is cloned the icons can quickly be adapted for the new library by simply changing the icon for the library and applying the change to all of the member VIs.

And now to close my attempted sales pitch for libraries let me show how libraries can solve the problem you mentioned in your original post "hard to find".

The VI Hiarchy screen has an option to group VIs based on the libraries! Knowing nothing about the application you have written, an educated LV developer can quickly identify a small sub-set of VIs that are involved in the work of a library.

From one my old NI Week Papers...

I hope this helps!

Ben

[optoelectro]

Hmmm, so I created a few folders, for organization, in my Documents/LabVIEW Data folder, and sorted all the VIs that were in LabVIEW Data into those folders. Now when I open one of them, it brings up some window that's searching through C:\x86 program files\labview or something, for the dependencies that VI needs. Unfortunately I don't think it's finding them because then it brings up a dialog box asking me to find its dependencies (which are just in another of those subfolders in LabVIEW Data) manually.

[Wolleee]

If you moved the subvi's without using the project management, such as right click, move on disk.  Then it will ask you to find the subvi's.  Find them manually and then save your project and it will save the paths.

[optoelectro]

Hi Matt, I think I've actually solved the problem: I went to Tools->Options->Path, selected the "VI search path" drop down, and added "<user dir>\Documents\LabVIEW Data\*" and now it finds them when I open it. It asks me to verify, but that's a simple click once.

Thanks for all the advice, I'll do it more intelligently in the future!

[Bob_Schor]

I fear we may have misled you.  I and several other posters (who posted examples to show you) assumed you were using LabVIEW Project to organize your VIs.  When VIs are inside a Project, the Project file (extension .lvproj) (tries to) keep(s) track of the location of the VIs and Controls.  The other "Organizational Principle" many of us follow is to keep "projects" (lower-case "p", meaning something more like "what I'm working on at this moment") in a folder with all of its attendant VIs.

If all you have are 3-4 (little-p) projects and a few dozen VIs, then keeping everything in a single folder in LabVIEW Data is not (totally) foolish, particularly if they are things you use once and then never use again, or (the 100% opposite) things you use a lot, but it is the only code that is important to you.

Once you graduate to doing "serious" LabVIEW work where you have, say, a dozen projects each of which may have 40-50 VIs (mostly different), then organization into LabVIEW Projects and placement of each Project in its own Project Folder, with (or without) sub-Folders (both "physical", meaning they exist on your hard drive, and "virtual", meaning they exist inside the Project folder) becomes more important.

Once you get really advanced, you will probably have a small collection of routines and utilities that all (or many) of your Projects (capital "P", meaning a LabVIEW Project) are using.  Here is where you can use VI Package Manager (VIPM) to bundle these common files into a VI Package that can be installed inside VI.lib, where all of your Programs can see and use them without you needing to directly specify the location of the source VI.  If you use Quick Drop, and you've "packaged" it correctly, I think they will even appear as Quick Drop shortcuts.  But that's Advanced Stuff (I keep meaning to do this, myself ...).

Bob Schor