10-14-2022 12:43 PM
We are supposed to be able to have multiple versions of LabVIEW on the same system and they can operate completely independently from each other. That doesn't seem to be the case. I have thousands of VIs and projects that were done in LabVIEW 2013. I recently also installed LabVIEW 2019 and 2022 on my system and only opened a project in a single directory that I wanted to upgrade to LabVIEW 2022.
A day later I started only LabVIEW 2013 and tried to open some old code in some backup directories from the LabVIEW 2013 start menu, and I got the error that the VI is of a later version (2019) than what I was currently using (2013). These were ancient VI backup directories elsewhere on the HD that I haven't opened in years and were written in LabVIEW 2013. I appears that when I installed LabVIEW 2019, it found every VI on my harddrive and updated all of them to 2019. This should not have been possible and could be disastrous.
What happened? I definitely did not open them or save them in LabVIEW 2019, and now I can't open them in 2013.
Solved! Go to Solution.
10-14-2022 12:57 PM
only opened a project in a single directory that I wanted to upgrade to LabVIEW 2022.
If this project has dependencies outside that are common with LV2013 projects, these dependencies will also be UPGRADED to 2022. I would presume that when you closed the project in LV2022, you clicked "Save All" without reviewing the files that it is compiling or saving.
Most of the professionals use multiple LabVIEW versions on their dev machine (I have LV 2019, 2020 and 2021) and successfully manage multiple projects (this does require experience and diligence not to save a file in a new version). If one is not careful, this will bite like in your case.
10-14-2022 01:07 PM
These were completely different projects in old archives. There are many VIs in the different projects that may share the same name as the ones in the project in my new directory as they are archived prior versions, but they are not linked to other projects, and are all contained in their own project. Everything I do is packaged into projects, with no cross sharing in other project folders. I do this specifically so changing a VI in one project will not affect the others. This should not have happened unless when I saved that project in 2019, it saved every VI on the hard drive that shared the same name as the VIs in that project.
10-14-2022 01:15 PM
@santo_13 wrote:
only opened a project in a single directory that I wanted to upgrade to LabVIEW 2022.If this project has dependencies outside that are common with LV2013 projects, these dependencies will also be UPGRADED to 2022. I would presume that when you closed the project in LV2022, you clicked "Save All" without reviewing the files that it is compiling or saving.
Most of the professionals use multiple LabVIEW versions on their dev machine (I have LV 2019, 2020 and 2021) and successfully manage multiple projects (this does require experience and diligence not to save a file in a new version). If one is not careful, this will bite like in your case.
On a side note, have you found strange quirkiness with 2019 that wasn't present in prior versions and were hopefully fixed in later versions? I am contemplating dumping 2019 altogether and just upgrading to 2022 Q3 from here on out.
10-14-2022 01:28 PM
At any point during your use of 2019 did you use the "Mass compile" option? Do you have any shortcuts to directories anywhere in your LabVIEW code files?
I had an issue a few years ago where I tried to do a mass compile on some code I got from another developer, but in that developer's directory there was a shortcut to a folder on a network drive as a "for reference" note, but LabVIEW followed that shortcut to the network drive and mass compiled a few directories there that messed up some other people's projects.
I can say that I am very certain that the mere act of installing 2019 or any other version would not trigger this by itself.
10-14-2022 01:37 PM
The only thing I can think of is that the project I was opening in 2019 happen to use an Agilent 34970 driver llb that was in its own directory, and that driver llb is used and referenced by all the other archived versions. When I closed my project in 2019 and clicked "save all", it must have also updated the agilent driver llb to 2019, and then updated all the other VIs and projects that also happened to call that Agilent 34970 driver llb.
Ouch ...
10-14-2022 02:49 PM
I have been installing and using multiple LabVIEW versions all the way from 2014 up to 2021 (typically have both 32-bit and 64-bit too) and never have faced your scenario, I would not suspect mere LabVIEW installation will cause this issue other than user error.
10-14-2022 02:50 PM
@jgvarner57 wrote:
The only thing I can think of is that the project I was opening in 2019 happen to use an Agilent 34970 driver llb that was in its own directory, and that driver llb is used and referenced by all the other archived versions. When I closed my project in 2019 and clicked "save all", it must have also updated the agilent driver llb to 2019, and then updated all the other VIs and projects that also happened to call that Agilent 34970 driver llb.
Ouch ...
It would only take some simple code to convert all those files back to LV 2013. The hard part will be finding all the undesirable links and fixing them.
10-14-2022 02:53 PM
@paul_cardinale wrote:
@jgvarner57 wrote:
The only thing I can think of is that the project I was opening in 2019 happen to use an Agilent 34970 driver llb that was in its own directory, and that driver llb is used and referenced by all the other archived versions. When I closed my project in 2019 and clicked "save all", it must have also updated the agilent driver llb to 2019, and then updated all the other VIs and projects that also happened to call that Agilent 34970 driver llb.
Ouch ...
It would only take some simple code to convert all those files back to LV 2013. The hard part will be finding all the undesirable links and fixing them.
What would the simple code or procedure be to convert them back to 2013? That would be fantastic if I could do that! I would praise your name for at least the rest of the week ...
10-14-2022 03:12 PM
@jgvarner57 wrote:
The only thing I can think of is that the project I was opening in 2019 happen to use an Agilent 34970 driver llb that was in its own directory, and that driver llb is used and referenced by all the other archived versions. When I closed my project in 2019 and clicked "save all", it must have also updated the agilent driver llb to 2019, and then updated all the other VIs and projects that also happened to call that Agilent 34970 driver llb.
Ouch ...
Yup, definitely possible, you got the culprit. If you have the code in source control, you can get the older version (if you don't this is a wakeup call for you to start following software development best practices).