New Feature: Developing a LabVIEW Project in an Older Save Version File Format

[AlexElb]

I have started a lvproj with LV24 and want to downgrade it to LV17. (Create a simple VI with LV24, add to new lvproj and set save version)

There seems to be a difference whether you

a) use the "Safe for Previous Version..." feature or

b) re-compile a VI with a "Save Version" set

E.g. I've found the Match Regular Expression node to be broken when using b) but it is working when using a)

Currently, it seems like we should be using the "Safe for Previous Version..." feature to explicitly downgrade all VIs of a lvproj to an older LV version.

Could you elaborate the difference between a) and b)? I would have guessed that at the end the same routines will be called.

Also, I see that if I use the "Safe for Previous Version..." feature from LV24 to LV17, commit to scc and do a mass compile on LV17, that all VIs gets changed. I would not expect this as well...

[Christina_R]

The main difference between the "Project/Library Save Version" feature and Save for Previous (SFP) is that this feature is not destructive.

SFP will save your VIs into the specified version, and if you're using a diagram object that wasn't supported by that version, it will replace the code with a picture or text as a placeholder. So if you then load those VIs into the original version, they will not match the original VIs.

This feature will instead save VIs into a later version than the specified save version. (Specifically, it will use the oldest version that supports the diagram objects used.) Also, this feature provides feedback on the VI toolbar that warns you that the VI isn't being saved into the specified version. And you can use the Error List to review the compatibility issues.

SFP was designed to give a copy of code to someone using an older version of LabVIEW. This feature is designed to enable you to collaborate on a shared project with someone using an older version.

I'll ask the R&D team to look into the two unexpected behaviors that you reported. But I think the first one is because vi.lib VIs are being affected by the Project Save version (which was previously reported and will be fixed before release). 

[Jim_Kring]

 I’m having this problem too. Edited the project in 2024, and when I open in 2020 the match regular expression, nodes are broken:

[Craig_S.]

The Match Regular Expression issue when saving to 2020 or earlier is a known problem with XNode mutation in the feature and is fixed in 2024 Q3; the fix should be available in the beta.

There are also issues saving Fuse Design System style controls or the Type Specialization node to 2017; these are also fixed for the 24Q3 release, but not in time for the pending beta.

[wiebe@CARYA]

---

@Craig_S. wrote:

The Match Regular Expression issue when saving to 2020 or earlier is a known problem with XNode mutation in the feature and is fixed in 2024 Q3; the fix should be available in the beta.

---

I'm confused. Are beta versions back?

[Craig_S.]

I don't know about "back", but there's going to be a beta version for 24 Q3, and they picked the build image for it late last week.  I do not know the timeline for the when the download will actually drop, but I'd expect it to be pretty soon.

[felipefoz]

I have started using this new beta feature in one my projects and I can say that I really like this new feature. Good job on that.

Besides this small annoying thing with the libraries not respecting the version, I think everything is going fine.

I also created a small tool to help me locate the offending VIs.

Or if you are into Git, you can check this incorporated into a git pre-commit hook that I created recently.

Pre-commit hooks for LabVIEW - https://gitlab.com/felipe_public/pre-commit-hooks-g

 

[Petru_Tarabuta]

Just used this feature for the first time in a real project a few minutes ago. Using LabVIEW 2024 Q1 to edit a project saved for LabVIEW 2022 Q3. The feature worked perfectly. Massive kudos. Thanks!

[Jim_Kring]

That’s fanitastic news. What’s nice about this feature is that we can now use/test beta versions of LabVIEW on existing/older projects without worrying about binary compatibility between beta/final releases.

(I’m recalling a time when saving files in a beta version of LabVIEW would cause them to be incompatible with the final production release)

[wiebe@CARYA]

So I've been trying this on a few projects too...

For 1 it's project, so if all the problems are ironed out, this will be a game changer.

But the other project is a pain. It doesn't help that the project has 32 bit ppls, and I have 64 bit LV24Q1... I don't expect that to work, but how LV handles it is just silly. For each VI from a ppl, there's a pop up, and 'OK' has to be pressed apparently for each used VI (~30 times for my project). Setting the project version to LV21 crashes LabVIEW.

So I installed 32 bit LV24Q1... Sadly no project files have separate compiled code on. I know this is required, but shouldn't there be a way to fix this in LV24? Is there a way to change this in LV24?

Maybe there's another problem (the VIs are in libraries and\or classes), but the entire project is converted to LV24, except 1 VI that's not in a library or class.