OpenG librarys Bug in LabView 2024

[JÞB]

OK I'll chime in.

You are applying an inappropriate assumption.   To wit: the saved vi version is changing on disc.

It simply is NOT POSSIBLE for a vi saved in 2024 to become any other version on disc without LabVIEW open and specifically saving for Previous Version.   Files don't just change bits on their own!

So,  we must consider what may be happening.   

You have a minimum of 2 OpenG library copies on disc. The 2020 version your project opens and the 2024 version in the location that you are saving to.

BEST idea I have would be to 

• Close all programs 
• Use File Search to locate all <whatever-openg>.lvlib files
• Rename all except the copy you know is compiled in 2024
• Resolve conflicts when your caller cannot find the lvlib members by pointing to the right library copy

Now, I am going to accurately guess what you didn't do.   You did not use a LabVIEW Project to organize the vis called by your TestStand Sequence.  Nor did you call the lvproj members through the lvproj context.  HINT: VI Hierarchy view will confirm what context the caller uses

The lvproj view can even show the full filenames to the right side when View>>Show file paths menu option is selected.  AND files can be reorganized (moved) on disc from the files view to clean up the mess you have.

[Hatimelaiha]

To verify your theory, I performed the following steps:

1. I created a fresh virtual machine.
2. I installed only LabVIEW 2024 and OpenG Variant version 6.0.0.45.
3. I checked the source version in the VI properties, which was 20.0.
4. I then mass compiled the OpenG library folder.
5. After opening the library, the version upgraded to 24.0. However, when I attempted to close the VI under openg_variant.llb, I received a message stating: "VI returned to old version to comply with owning project or library." If I clicked save, it reverted to version 20.0.
6. Additionally, upon restarting LabVIEW, I found that openg_variant.llb reverted automatically to version 20.0.

I performed the same test process on all OpenG libraries (error, file, numeric, string, etc.). This issue appears to occur only with openg_variant.llb and openg_array.llb. The other libraries remained at version 24.0 after mass compilation.

Please note that this virtual machine contains only LabVIEW 2024 and OpenG libraries, with no other projects of mine.

[rolfk · Accepted solution]

LabVIEW 2024Q1 has a new experimental feature to maintain source code versions of VIs. This, when enabled, will save the VIs in the original version even when you work in LabVIEW 2024Q1. This has been a long requested feature so that when you work with multiple people in a project (especially important for open source projects), you don't invalidate the source code for other developers just because you (accidentally) opened it in a newer version and were careless enough to resave them. There are likely some corner cases that do not work as intended, such as your save dialog prompting you to save everything to the newest version and then saving the VIs in the original version back to disk. Since the TestStand engine likely is just using LabVIEW runtime and has no ability to recompile the VIs to the current version, things then go wrong

LabVIEW 2024Q3 will have this feature more officially present and most likely ironed out many such issues a bit more. The feature is VERY important for any collaborative projects where you usually can't mandate that everybody works in the same version of LabVIEW, so I applaud its introduction even though if it means initially to cause trouble like this.

My guess is that whoever upgraded the VIs for these two libraries was actually working in LabVIEW 2024Q1 and enabled the feature to maintain the VIs in source version 2020. So VIPM or whatever tool was used to create these packages will have to learn to disable the "maintain original source code version" flag when creating a package but that will likely require VIPM to save the VIs explicitly to that version itself by invoking "save for previous". Quite messy but progress has usually its price. 😃

[sam.karl@husco.com]

I am having the same issue, the library won't compile and is getting stuck in LV 2020 when installing using VIPM on 2024 Q1. I opened a issue on the Github repo for it. 

https://github.com/vipm-io/OpenG-Variant-Data-Library/issues/72