07-12-2016 10:09 AM
I have a programming computer that has several versions of LabVIEW installed. Once I finish a program, I move the program to the "target" computer (or touch screen) that have only one version installed.
The problem I have is when I run a VI, the VI always loads the version of LabVIEW that was used last. When the VI is saved, it compiles to that version and will no longer work on the "target" computer.
It seems that saving for a previous version of LabVIEW does not always work (it may be related to going from Win 7 to Win XP).
Is there a way to force the VI to open the version of LabVIEW that the VI was compiled with?
Solved! Go to Solution.
07-12-2016 10:40 AM
1. Go give this idea a Kudos: Version-aware LabVIEW launcher
2. This would be a good reason to have a Virtual Machine
07-12-2016 04:43 PM
The problem comes from Windows File Associations. When you double-click a VI, Windows asks "Who is supposed to open files with the extension .VI?". The answer is contained in the Windows Registry -- if it says "Open with LabVIEW 2015", it opens with LabVIEW 2015, but if it says "Open with LabVIEW 2012", it will (try to) open with LabVIEW 2012.
When you manually open a version of LabVIEW, LabVIEW decides "This is the Version to use, by default", and resets the Registry Key. Ordinarily, this is a Good Thing, since if you open LabVIEW 2013 to work on a VI and then double-click another VI, it will also open in LabVIEW 2013.
So the way to set up LabVIEW to use a particular Version by default is ... start that Version. That sets the Registry to use the specified LabVIEW Version as the "default". Now you can double-click at will.
Bob Schor
07-13-2016 08:22 AM
Bob,
So are you saying if I double click the VI without having LabVIEW alreay open, the proper version of LV should open for that VI (and not the last version that was run on the computer)?
I just checked, and it doesn't work like that. Here is what I did:
Opened LV 2015 then closed it.
Double clicked a VI created with LV2013. This opened LV2015 and showed the VI. I need this to open LV2013.
07-13-2016 08:28 AM
@metzler wrote:So are you saying if I double click the VI without having LabVIEW alreay open, the proper version of LV should open for that VI (and not the last version that was run on the computer)?
I am pretty sure Bob said the complete opposite of that statement. Open LabVIEW and that version is saved in the registry so that the last version of LabVIEW you used is the one that is used the next time a VI is opened.
07-13-2016 08:54 AM
Yes, I tried (but failed) to clearly say what Crossrulz "says I said". Opening LabVIEW directly modifies the Registry to "register" itself as the "Open With" program for files with "LabVIEW Extensions" (including .vi, .ctl, .lvproj, .lvclass, etc.).
Bob Schor
07-13-2016 10:57 AM
Thanks Bob for responding. I think my brain got in the way of what you typed, so I had it backwards.
The problem still exists if you don't know the version of LV that the "target" computer runs.
To prevent this, I used to update all of the "target" computers to the latest version, but then had some compatiblity issues, in addition to the time it takes to update the computers.
07-13-2016 03:01 PM
@metzler wrote:
The problem still exists if you don't know the version of LV that the "target" computer runs.
Your targets should not be actually running LabVIEW. They should be running an executable that you build (preferrably with an installer). Then this becomes less of an issue and you have the bonus of not needing LabVIEW licenses for all of your target computers (RunTime Engine is free to distribute).
07-14-2016 07:48 AM
Good point. It's just really handy to be able to change the VI on the target machine to correct one of my mistakes.
I guess it all pays the same
07-14-2016 08:18 AM
@metzler wrote:Good point. It's just really handy to be able to change the VI on the target machine to correct one of my mistakes.
I guess it all pays the same
And then it turns into a configuration nightmare since you have to keep track of which targets have which fix and how do you know they are all the same or some technician didn't go in and change something to force something to pass. Yes, I have fought all of these problems and they almost all go away just by using executables.