I started to write this article in June 2007 and a recent post on LAVA made me realize that it may still be of use

National Instruments (NI) has provided LabVIEW developers native OOP support (LVOOP) since LabVIEW 8.2. Users of LVOOP can quickly build single inheritance ByValue object hierarchies that are very powerful. However, there are a few corruption issues related to LVOOP that have made me realize that without SCC I would be getting nowhere on my current LVOOP project. I think these principles also apply more generically to all LabVIEW project files.

There are several hurdles that will basically ruin your day when developing in LVOOP without a good backup system in place. SCC systems provide backup and version control for all of the files that you modify during the course of development which allows you to revert your code to a known state when your files get corrupted. SCC systems basically allow you to take snapshots of your project so that you can revert your code at a very granular level should the need arise. Using SCC should be important to anyone who wants to be able to work on code which means this document applies to solo-developers and not just people working on development teams. There are no excuses for not using an SCC system!

I’ve created a very simple project to highlight some of the issues that relate specifically to LVOOP.

You’ll notice that the project is saved and not modified (no *) in title.

Here is the XML of my project at this moment:

Here are some of the issues that I have faced where using an SCC system has saved me:

1) The class file (*.lvclass) contains binary data.

In the example project above, ‘Class 1′ has the following XML structure:

You’ll notice that there are numerous fields that contain flattened binary data. This means that as a developer, if your .lvclass file is corrupted or somehow not saved properly, you may get stuck having to revert code (you definitely will not be able to just edit the .lvclass file and fix the corrupted item). This can be very painful when there is a problem.

2) The class inheritance can be tricky to change.

It is possible when changing the class inheritance to create problems which will crash LabVIEW. In such cases, it is really important to be able to revert the code. I noticed this in LabVIEW 8.2 and luckily since then I have been more careful about naming classes and setting inheritance up so I’m not sure if these issues still exist in LabVIEW 8.5.1.

3) The .lvproj file can get corrupted.

It is possible for LabVIEW to crash in such a manner where the .lvclass file is not saved before the .lvproj file – leading to the project believing a class member exists despite the class not declaring that it owns the class member. Sometimes this problem is easy to remedy by removing the missing file and then re-adding the member back into the class.

If I open ‘Class 1′ from the project menu, I can see the class looks as follows:

You’ll notice that class has been modified (* in title bar). This is despite the fact that the project did not have a * so you would think that it meant all of your class members were not modified.

Now, you can see by careful inspection of the XML data that the .lvproj file knows that Untitled 1.vi is a class member but somehow the .lvclass is not saved with Untitled.vi as a class member. (I’ve made ‘Untitled 1.vi’ bold in the project XML, see if you can find it in the class XML data…)

If LabVIEW crashes unexpectedly when you are in this state then you have a problem. If you try to open Untitled 1.vi this is the error you will get the following error:

In LabVIEW 8.5 you will also get a dialog that tries to help you resolve the error by allowing you to add the VI back into the class (which is the fix for the problem). However, I’ve seen LabVIEW 8.5 crash when I tried to do this so I usually say ‘Remove from library’ and then manually add the VI.

The point is this: it is easy to get LabVIEW into these really unexpected states and sometimes you can get stuck in a state where LabVIEW will basically crash no matter what you do until you go back to an earlier version of your project and/or class file.

In summary, there are many ways class files can get corrupted, and just like a corrupt VI, there is no external way to edit the file and get it working. To prevent this from wreaking havoc on your project, use an SCC system. Here are the best practices that I’ve been following to keep my project working:

1) Save All VIs and Commit to the repository often.

It is OK to commit code that is broken or not fully functional. The point of the repository is to give you a lot of flexibility and control when reverting code – the more often you check in the code, the more flexibility you will have.

2) Make good comments when you check in your code.

Try to be descriptive about what you are working on. The SCC will keep track of the files that were modified so you don’t have to list them in your comment, just make sure it is clear what feature or component of the software you were modifying.

3) Don’t forget to add new VIs to your repository.

Most SCC systems will automatically select files that have changed on your system that it knows about, but will not know what to do with new files. Use a good project file system and be sure to add your new class member VIs.

4) Understand how to revert the code when things go awry.

If (or more likely when) LabVIEW crashes, if you are having issues opening the project file, try to revert to the last working point. Take the time to understand how to revert using your repository and don’t be afraid to ‘go back’ (this will be a lot less painful if you check in your code often). The revert feature is the number one reason to use an SCC system – this is what will separate you from the developer using a folder system. Keep an eye on what VIs have changed each time you commit the code so that you can narrow your search for corrupted VIs if that is necessary.

5) Changing class properties can affect a lot of VIs. When the attributes of a class change, VIs that use the attributes (which are generally every VI in your class) will be changed. This means you will have to get used to checking in a lot of VIs despite what may seem a simple change. You have to get used to this. Even worse is the LabVIEW error dialog behavior of having 1 broken class member break every VI in the class (I think this may be fixed in version 8.5.1).

I hope these tips will help you to avoid corruption in your LabVIEW Projects and Classes!