Random Ramblings on LabVIEW Design

Community Browser
Labels
Showing results for 
Search instead for 
Did you mean: 

A Tidy Project is a Happy Project

Active Participant swatts Active Participant
Active Participant
‎02-19-2016 02:26 PM
‎02-19-2016 02:26 PM

Howdy Doody my precious programmers

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

CleanProject.png

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.


Project Flossing

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.

FlossingProject.png

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.

Dynamic.png

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....

FindCallers.png

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.

Lots of Love

Steve

Comments
Member GregPayne
Member

Yet another informative article by Mr Watts,

You mention that you stay away from instr.lib. When you are using an instrument driver, do you have that driver in your project folder for each project? (Duplicate copies) The same applies to common reuse code, does that go in your project folder, for each project?

One process I always dislike going through is setting up a new PC and installing all the nessessary drivers into instr.lib. Having them packaged with your project will make this whole process much quicker and easier, just copy and paste a single folder.

Active Participant swatts Active Participant
Active Participant

Where practical we want everything under the project, so the short answer is yes. The slightly longer answer is that we strive to avoid loading toolkits, addons, packages etc. So we'd certainly commonly remove drivers from the instr.lib wrap them in an lvlib. Even stuff in the vi.lib will sometimes get the same treatment. An example is the ftp toolkit. It is missing functionality we need, so rather than change it for reuse across projects we have another copy in each project.

Member Terry_ALE
Member

I am following your posts more and more Steve and often share them with my team as good examples or at at minimum good discussion seeds, looking forward to meet in person in Berlin this April.

When the project came out in LV8 we used auto-populating folders.  We have since gravitated away to virtual folders, auto-populating folders remain the exception.  We felt that there may be some developer offshoots and experiments in the folders that we didn't want in the project but also didn't want to remove them from the directory hierarchy.  I like the floss analogy so maybe those extra files should be flossed out and noted somewhere in the project notes as 'unused nuggets'.

I noticed your screenshot has auto-populating folders.  Are they the rule and virtual folders the exception?

Active Participant FabiolaDelaCueva Active Participant
Active Participant

Steve,

 

I find this article very interesting, specially since it is very different from the way we organize our projects (see: http://delacor.com/a-method-to-project-madness/). It seems that you embrace auto-populating folders, where we embrace virtual folders under project libraries (.lvlib).

 

The flossing of dependencies is handled in our case by creating an auto-populating foler of the library folder, the .lvlib take precedence to auto-populating folers, so if there are .lvlib in the auto-populating folder, the auto-populating folder will only show the VIs and controls that are not claimed by the .lvlib. This helps to clean up: either a VI has to be deleted because it is no longer used or it has to be moved to be part of the library, because it is lost and we forgot to make it part of the library. Other than cleaning up, we don't use auto-populating folders that much.

 

Regarding the Dynamic VIs example, why not use the "diagram disable structure" instead of the case structure with a false constant wired to it?

 

You and us have had the discussion on dependencies several times, we favor using VIPM packages and a vipc file with all the dependencies for the project. With VIPM pro, instrument drivers that were downloaded from ni.com/idnet can be packaged into a VIPM package and included in the vipc for the project. We rather have that than end up with copies of the same instrument in different projects and risking there being slight differences between them. We can still have different versions of the same instrument, but VIPM package has the added benefit of having release notes for each version where we can list what is the slight difference for each version. The same approach could be followed using SCC externals.

 

Thanks again for sharing your thoughts.

 

Regards,

Fab

Active Participant swatts Active Participant
Active Participant

Hi Terry,

I use auto populated folders only, we all tend to agree (within SSDC) that we like to know where stuff is on the hard drive. Our view is that experiments etc are still part of the project, while it is actively being developed at least. Like most things with us, it's easy and doesn't give us problems.

Sadly I won't be in Berlin as we're doing NIWeek this year .

Glad you find the articles of some worth!

Active Participant swatts Active Participant
Active Participant

FabiolaDelaCueva wrote:


                       

Steve,

I find this article very interesting, specially since it is very different from the way we organize our projects (see: http://www.walkingthewires.com/2015/06/07/a-method-to-project-madness/ ). It seems that you embrace auto-populating folders, where we embrace virtual folders under project libraries (.lvlib).


                   

One thing I've learnt when designing processes is that if there is extra manual process involved I won't do it (ditto my colleagues). We're just lazy I guess but it's been a fairly constant thing in many years of putting processes into factories.

So auto-population gives me the gift of not having to do it myself. So a flawed system that takes no effort is better for us than a perfect system that takes some effort. All these are methods that work for us and the most interesting thing for me is hearing what works for others, especially this kind of internal methodology. (I'll say this quietly, I find it more interesting than talking about LabVIEW).

FabiolaDelaCueva wrote:


                       

Regarding the Dynamic VIs example, why not use the "diagram disable structure" instead of the case structure with a false constant wired to it?


                   

The simple advantage is that the IDE tells me if the dynamic VI is broken, updates on a save-all and transfers when I do a Save..As and save the entire hierarchy (a forceful way to clear-out the project).

I'll re-iterate that we need to add THIS WORKS FOR US... at the end of every proclaimation. Age has shown me that there are things that are just wrong that need challenging, and there are things that are 50 shades of right and understanding these lead to improvements.

Thanks for your input everyone.

Member joerg.hampel
Member

swatts schrieb:


                       

Sadly I won't be in Berlin as we're doing NIWeek this year .


                   

I'm sorry to hear that, I was looking forward to meeting you again. It was fun last year ;-)

Active Participant swatts Active Participant
Active Participant

It was fun, and my daughter rates Berlin very highly. But it's not fair on the rest of SSDC if I spend all company time and resources on jollies. I have a solid business reason to go to NIWeek, with the CLA summit the justifications aren't quite as tangible so both trips on one year is hard to find money for.