I'm often asked "How do you keep your project so shiny, clean and smelling so minty fresh?"
Well first let's have a look at a clean project
This is our General Application template and you'll notice that the main VI (GenAppMain.vi) sits atop the hierarchy and that's because he is the king and everything should be relative to him. This is how LabVIEW like things organised, it will always look below itself in the hierarchy first as standard behaviour.
You'll also notice that we use auto-populating folders showing the entire hierarchy, the way we structure our projects lends itself to having no virtual folders (IMO it's an abstraction too far)
Dlls, config database file, startup VIs are also at this top level. All of this stops LabVIEW going searching when you move the project around. Keeping everything at this level also helps when you build an executable. It's much easier just to search in your own directory.
Like Unit Testing? well look in the TestVIs directory (we are trying to use Teststand if we need to do Unit Testing, this is quite new to us as we far prefer lots of functional testing)
Next we need to make sure there are no conflicts. Click on the exclamation mark and solve the problems.
What we are aiming for is a portable project. Ideally I want to dump my project directory on a new computer and the it to work. At the very least I want to be able to move the project around on the computer you are developing on.
All this preparatory work is to allow us to upload the project into our repository (SVN). If the project is portable we can then download the project onto any SSDC machine or even across customers machines.
We take an uncompromising view on dependencies and in truth anything outside of SCC (Source Code Control) is something that can change how your software works in unpredictable ways. See here for a discussion on this. With this in mind we can see that the Dependencies section is pretty light and we aim to keep it that way.
Over time scrappy bits of old project can get caught in the gaps, and these need cleaning. This is because they are indicative that a lack of control and understanding. One common area that needs regular flossing is in the Dependencies.
In this example we can see that although there are no conflicts, there is still some ugliness in the Dependencies section.
Cleaning these out is fairly straight-forward, you just need to find the unused VI in the project that is referring to these dependencies. But if you use dynamic VIs you should employ the following trick first.
Sticking any dynamic VIs in a non-called case of the main calling VI will not effect the running of the VI (LabVIEW will compile them out), but it will allow the IDE to tell you if they are broken. It will also allow LabVIEW searches to ascertain if the search VI is in the hierarchy.
Now you are ready to floss....
Right-click on the offending Dependency and select Find>>Callers, because the main calling vi is not broken and all dynamic VIs are on the main calling VIs block diagram we can be pretty sure that there is a broken, unused vi in the project. Find it and delete it (using the SCC delete function!)
Also notice the \user.lib folder, for us this is a sure sign of something untoward in our project structure. This is because we NEVER use user.lib. Also view instr.lib with suspicion, anything that is not part of the standard LabVIEW install should be moved out and put under the project (use lvlibs to protect the namespace).
Having a tidy project makes cross-linking and unpredictable loading a rare thing and it may even prevent gum disease.