Source code control in LabVIEW – Why and How

You are an engineer that has been using LabVIEW for a long time. Most likely you’ve heard about Source Code Control (SCC), but you think it’s imposible to use it for a software like LabVIEW. Maybe you think you don’t need it because you work alone. However, using SCC in LabVIEW can be quite beneficial even in this context, and i will explain in this article why you should start using it as soon as possible in your projects, and where to start.

Building software in LabVIEW is actually programming.

When you open LabVIEW and start placing VI’s in the block diagram you are actually programming in a graphical programming language called G. This means, that if you want to start building reliable solutions you have to start thinking as a software engineer.

In software engineering one of the things considered a good practice, between many others, is source code control.

Why is it so useful to use SCC in LabVIEW?

It’s all about the history of your project. And it applies to any project you may have… Let’s say you create a new project, you give it a name and you click «Save». Then, you add a new VI and save it again. You, as a unique developer with just one VI will most likely remember why you added that VI, when, and what was affected. But, what happens when you add more and more VIs? or when you add more wires and subVIs into that VI?

In this common scenario it’s normal that you loose track of changes. Therefore, if at some point, you realize that you have messed up with your project and doesn’t work anymore, how do you know what changes caused the issue, what was affected, and when? Well, in this case you would’ve wish have used source code control in LabVIEW.

How source control in LabVIEW works?

Let’s go back to the initial scenario. You created your project and your first VI. But, instead of wiring without awareness of the project history you are going to start tracking your changes. In this case the basic option is the least efficient one, and you have probably done it. For example, start saving copies of your code in different directories with different names:

• Version 1
• Good Version 1 with some changes
• Better Version 2 with changes in the changes

This approach has several issues but lets start with the obvious:

• The names of the project directories don’t give information about what changed and why. Just that «something» changed
• You will not know exactly which files were affected between one version and the other
• These versions were created after large edits in the code, as a consequence, if you need to go back to an older version you will loose important features.

However, you can get rid of all these issues by just installing a source code control software and start using it to track your changes.

Selecting the Source Control Software

First you can take a look at different source code control softwares out there. But I would personally go with git. This is a distributed, and open source, version control system. And has become more and more popular between companies, because of it’s branching model system.

Once you install git, then you can choose if either you want to work with Git Bash, to run git with command lines, or if you want to use a graphical user interface (GUI) client to work with it. Personally, I like Sourcetree and I don’t feel ashamed to actually wanting to see things graphically.

Your first Git repository

But let’s give this example with Git Bash. Once you installed git, Git Bash should appear in your computer. When you double click and open it, you should be able to see the terminal.

First thing we want to do is to create a directory. This is the directory where we will create and store our LabVIEW project. In this case I wanted to create a directory in the D: drive of my computer where other LabVIEW projects are stored. For that I executed the following commands.

cd D:/
mkdir "D:/LabVIEW Projects/GUI Sample Project"
cd "D:/LabVIEW Projects/GUI Sample Project"

After executing these commands, git bash will be working in the created directory. In it we will create our repository. In order to do so, let’s execute the following command:

git init

This command creates a repository in the folder. You’ll know if that operation was successful if a new directory «.git» appears inside the folder.

Congrats! You have just created your first repo!

Using Source Control in Your LabVIEW Project

Now it’s time to create or save the project (if you already have the project) in the directory with the git repo. In this example, I created a project with no VIs at all and saved it in the directory where the repository was created. The folder now looks like this:

Now, in this case, git is not capable of tracking the changes in the project yet. Why? because first we need to «add» the files to the staging area, for it to start tracking the changes.

How do we do that? Let’s execute the following commands:

git add "GUI Sample Project.lvproj"
git add "GUI Sample Project.lvlps"

Now, it’s recommended to ignore the .aliases file, since LabVIEW creates a new aliases file every time you open your project. And it’s not worth to create a commit of this file every time you open or close the project.

Once the files are in the staging area we are ready for the first commit. A git commit, captures the changes made for the staged files. But first, let’s see what we have so far. For that, i recommend running the «status» command to see what the current status of the repository is.

git status

The output will show the files that we are tracking and that are ready to commit. As shown in the terminal below, this is the current status of the project.

Git Commit for your LabVIEW project

The files that we added to the project are ready for the «git commit», while the .aliases file is not being tracked. We can later add this file into a git ignore file to stop showing it as an untracked file.

Now, we are ready to execute the git commit command. Is always a good idea to add a meaningful message about what changed in that commit. That way we will have a better tracking system.

git commit -a -m "Project created and tracked"

You can review the documentation to see all the options you have when making a commit, but in this case, we are adding the «-a» parameter to indicate that we want to commit all the staged files, and the «-m» to indicate the message.

After executing this command, we will see the commit ID, also we can execute a «git status» command to review the current state of the repository after the commit.

Congratulation! if you have reached this point you are ready to start using source code control in LabVIEW like a jedi!

Unleash the power of source code control in LabVIEW

Now, for this example, I will add a couple more commits. First I am going to create a blank VI and add it to the project and repository, and then I will add a button in the front panel of that VI, and create another commit to track that change.

To show you what I have done I have executed the «git log» command. This shows the commits history of the repository. As you can see in the image below, there has been three commits. The one where I created the project, another one where I added the blank vi, and another one to track the stop button I added in the front panel.

Navigating Through the commits

Now, here comes the «magic». Let’s say we want to see how the project was before I added the button in the interface, for example, you didn’t liked the button, or something was broken after I added it so we need to see a previos state.

We will use «git checkout <commit id>» command, and point to the commit before the last commit where I added the button. After executing that command, if we execute the «git log», the commit history shows that the head is currently pointing to the commit before I added my latest commit.

Now if we open the project at this point we will notice that the button in the front panel is gone! And of course that makes sense. We are at a point in time just before I added the button in the front panel!

And if we want to go back again to the latest commit and see what happened, we will just execute the «git checkout <commit id>» command again, and point to the latest commit.

When opening the GUI.vi now we will see the magic. The Stop button is right there! Seems like now we have Dr. Strange super powers!.

Execute «git checkout master» to reattach the git head to the working master branch, this is, leaving everything as it was before doing all the checkouts..

Clone this repository

Up to this point we have what we call a local repository. This means that we are tracking the changes we made locally into our system. But we could have a copy of the repository in a remote server. And that’s a nice thing to have because we can pull and push changes to that remote repository, and actually different people could work together in the same project.

I have used GitHub to store the remote repository of the GUI sample project. You can find it here. As a challenge, clone this remote repository to a local directory in your PC.

One last tip

When using SCC in a LabVIEW project, make sure you separate the compiled code from the source code. According to ni documentation «if you separate compiled code from all files in a VI hierarchy or LabVIEW project, changes to one file do not produce unsaved changes elsewhere in the hierarchy or project. This behavior allows you to check out only the VIs you want to modify instead of all VIs that call the changed VI».

You can make this the default behavior by going to the menu and select: Tools -> Options -> Environment and check the option «Separate compiled code from new files».

Conclusions

I hope now you can see why you need to start using source control in LabVIEW. It’s an amazing tool that will give you the ability to travel «back in time» to a previous stage of the project, see the changes, create branches etc.

We have so far only scratched at the surface of what a source control software like git can do for you. So, i hope now you feel inspired and go and install it so you can start testing it in your projects.

And if you think that this will be too complicated for LabVIEW, remember that a good LabVIEW software is the responsibility of good LabVIEW developers. Take a look at this article that i hope will change a bit your perspective.

Ahorra y aprende según tu estilo de vida Aprende en cualquier momento y lugar con hasta un 80% de descuento por tiempo limitado en Udemy. Link en la imagen abajo!