Introducing Automatic Version Manager (AVM) for LabVIEW
Automatic Version Manager (AVM) for LabVIEW
This video is a demo of some software I wrote called Automatic Version Manager for LabVIEW. AVM is a solution for dealing with multiple versions of LabVIEW installed on the same computer. If you have ever used multiple versions of LabVIEW on the same computer, you have likely run into some issues. Continue reading for more information about AVM. After watching the video and reading this post, if you like what you see, you can go here to get a copy of AVM.
What is the problem with the default LabVIEW Behavior?
The issues stem from the way LabVIEW sets file assosiactions with Windows. When you double click on a LabVIEW file (vi, ctl, lvproj, lvclass, lvlib, etc) in the Windows Explorer, Windows uses the last version of LabVIEW that was opened in order to open the file. If the last version of LabVIEW that was opened is not the same as the version of the vi that you are trying to open, there are 2 possbible cases.
Attempting to Open a file with an older version of LabVIEW
The first case is more of an annoyance than anything. In the first case, the file version is newer than the last version of LabVIEW that was opened. For example, the last version of LabVIEW opened was 2015 and you double click on a vi last saved in 2016. In this case, the vi will fail to open and LabVIEW will notify you. It’s kind of frustrating because LabVIEW knows what the version of the file is. LabVIEW tells you. But it cannot open it with the appropriate version. That is just annoying and kills your productivity, but it’s easy to recover. Once you close the newer version of LabVIEW, simply open the correct version of LabVIEW and then double click the file, or open it from within the correct version of LabVIEW itself.
Opening a file with a newer version of LabVIEW
When you try to open a file with a newer version of LabVIEW the results are a little less pleasing. LabVIEW tries to be helpful. It will open the new vi in the newer version of LabVIEW. This isn’t necessarily a bad thing. My biggest issue is that is does not tell you that you opened it in a newer version. Combine that with the fact that the IDES for 2012-2016 look very similar and it can cause some serious problems. A simple dialog box here would solve a lot of problems.
An Example
So imagine this scenario: A colleague asks you to lookover something for him. You are working in LabVIEW 2015. First, you save what you were doing and close LabVIEW. Then, you check out the source code for your colleague’s project (You should be using source code control. If you are not – do yourself a favor and start now.) You’re not thinking clearly, or you don’t remember what version of LabVIEW it was written in so you just double click on the project file. Maybe you even say to yourself, “I don’t care because I’m not going to change anything. I just want to look at it.” Let’s say this project was written in a previous version of LabVIEW, say 2014. LabVIEW trying to be helpful, gladly opens it in LabVIEW 2015 and doesn’t think to warn you.
Once you open the code, you look at his code and immediately find the problem. After making a few quick changes, you save the one or two vis that need changed. When you exit LabVIEW, LabVIEW prompts you to save a whole bunch of stuff, but that is normal since some stuff likely recompiled. Since you know that you saved what you changed, so you don’t save all. Once LAbVIEW exits, you check the couple vis you changed back in. Now, thinking you are done, you tell your colleague that you fixed it and checked it in.
Suddenly, your colleague calls, saying the code is broken and it won’t even load. “What happened?” You ask incredulously. “I only changed 2 or 3 vis.” LabVIEW was trying to help you, but unfortunately in this case, it caused more problems. You did only chang 1 or 2 vis. Unfortunately, you happened to edit them in a newer version of LabVIEW and when you saved them, you saved them in the newer version. Therefore when your colleague goes to open his project file (which you didn’t save, so it is still in LabVIEW 2014), the project opens, but it complains that it can’t open the vis that you edited.
Now you are left with 2 choices for fixing the problem. Of course you can take your new edited 2015 vis and backsave them. However that creates all kinds of problems, particularly if the edited vis called up subvis. Those subvis have to be loaded and saved in 2015 and then backsaved as well. Once integrated with the rest of the code this will cause crosslinking problems. The easier option is to just roll everything back in source code control and redo your changes making sure that this time you are in 2014. If it’s just 1 or 2 changes, then no big deal. If you changed a lot, it can be a real pain.
Again I will note: A simple dialog box from LabVIEW notifying you that it is upgrading the vi to the new vewer version of LabVIEW would avoid all these problems.
There is a better way
In order to avoid all these issues, I designed some software that sits between Windows Explorer and LabVIEW, called AVM. When installed, AVM injects itself into the launching process. Instead of Windows associating vi, ctl, lvrpoj, lvlib, lvclass, etc with LabVIEW, these are now associated with AVM. Now, when you double click on them in the Windows Explorer, Windows will open them, not with LabVIEW, but with AVM. AVM then looks at the version of the file and the versions of LabVIEW that you have installed on your computer and makes an intelligent choice. If it can, AVM opens the vi in the correct version. If it can’t, it doesn’t automatically upgrade them. AVM will prompt you for what to do. Now LabVIEW will no longer be able to automatically upgrade your vi’s for you without notifying you. You have to manually do it, by intentionally opening a vi in a newer version of LabVIEW.
Get AVM
In order to get a copy of AVM, go to https://blog.sasworkshops.com/automatic-version-manager/ and fill out the form there. You will be e-mailed a link to download the installer.
