LabVIEW Public Beta Program in 2024
New Beta Feature: Developing VIs that Can Be Used in an Older Version of LabVIEW
Warning: Installing the LabVIEW 2024 Q3 Beta will replace LabVIEW 2024 Q1 if installed. Also, you will need to uninstall LabVIEW 2024 Q3 Beta before installing the release version; upgrading with NI Package Manager will not work.
This feature allows you to use LabVIEW 2024 Q3 Beta to edit VIs that can be opened with older versions of the LabVIEW editor. This allows you to collaborate on a project with others who haven’t upgraded to the same version of LabVIEW that you are using.
Section 1. How to Use the Feature
For this feature to take effect, VIs and libraries must enable the property “Separate compiled code from source file.”
- For VIs, this setting is in VI Properties>General.
- For libraries, this setting is in Properties>General Settings.
In the Project Properties dialog box, in the Project category, you will find a new “Save version” option.
You can set the option to LabVIEW versions back to 2017 (“17.0”). Selecting “Editor version” will save files in the format matching the editor, which matches LabVIEW’s former behavior (i.e., without this new feature).
You can also set a Save Version on Libraries. When editing a VI, the Library setting (if configured) will be honored before the Project setting. The default save version setting for libraries is “Default” rather than “Editor version”, which means it will inherit the save version from the project setting (when editing within a project).
When editing a VI that isn’t saving in the current editor version, there will be a new “Save version” element on the toolbar that shows what save version has been specified.
However, LabVIEW will not save to that version if it is not safe to do so without losing information. If a VI is using unsupported features, it will instead save to the oldest version that supported everything in the VI. For example, if a VI uses Sets, it will save in at least version LabVIEW 2019 (“19.0”) even when set to save to an older version. This ensures that saving will not lose VI contents the way that Save-for-Previous can.
If a VI cannot save to the designated version, the toolbar “Save version” item will show in red text with a warning glyph. You can hover over the item to see which compatible version will be used instead.
You can click on the element to open the Error List Window, which will contain a new section called “Save Version Compatibility Issues.” As with errors, you can double-click on an item to locate the code and make edits to resolve the issue.
Section 2. File-Based Version Specification
We expect you to edit VIs within a project or library to use this feature. However, as an advanced feature, you can also set a save version on an entire directory by creating a file called “.lvversion” in the directory. The file should contain a single line specifying the save version as text, such as “21.0”, and it will affect all VIs loaded from that directory or any contained subdirectories. If a VI is also being edited within a project which specifies the save version, the oldest of the two versions will be used. If the save version is defined by an owning library, that version will supersede either project or file-specified save versions.
Section 3. Caveats and Limitations
Application Builder
LabVIEW-built applications, shared libraries, and PPLs will still be saved in the editor version. For Source Distributions, the save version specified in the project will be used only if the source distribution is configured to save VIs as source-only (“separate compiled code from all source files” in the Additional Exclusions category). The feature does not support saving embedded compiled code in VIs compatible with older versions without recompilation.
LabVIEW Real-Time Module
Note that your RT target will still need to match your editor for deployment, even if you are authoring VIs in an older version file format.
LabVIEW FPGA Module
VIs on FPGA targets or that use FPGA nodes will always save to the current editor version, even if the project is set to save to an earlier version.
Section 4. Known Issues
- Fuse Design System controls do not warn about or prevent saving to 17.0, a version that didn’t support this control style. This will be fixed in the release.
- Projects that use FPGA will default to using the last saved version as the Project Save Version, but we intend in the release to have them default to “Use editor version.”
- PPL contents will erroneously show up in the Error List window in the Save Version Compatibility section. These should be skipped as they will never be saved. This will be fixed in the release.
- In the release, older projects loaded without a project version explicitly set will keep the same version they were originally saved in only if the project itself is set to use "Separate compiled code from new project items," but this project source-only check is not in the Beta.
- Saving untitled items that have never been saved before saves them in the editor version. You should be able to work around this by saving the control or VI again. This will be fixed in the release.
I noticed that the feature does not consider if some nodes can be inlined in older versions of LabVIEW.
I believe this is also true for the former Save for Previous feature.
As example I have a VI that uses the Transaction Begin Undo, if the VI is in 2024 and saving back to 2020 I can inline it. However, when opening the VI in LV2020, it is is broken because apparently this node can't be inlined in older versions.
https://labviewwiki.org/wiki/VI_class/Transaction.Begin_Undo_method
I recall correctly a couple of other methods suffers the same problem, mostly VI Server methods.
Hope we can get that fixed in newer releases.
@Darren escreveu:
I can't reproduce the behavior you're describing. The Transaction.Begin Undo method looks like it can be present on the diagram of an inlined VI all the way back to at least LabVIEW 2019 (I didn't test earlier versions).
You are totally right, this one does not seem to be a problem. I am 100% sure that I had this problem and eventually fixed by not inlining it. Now I can't remember exactly which project it was and the function.
I am constantly working with 2024Q3 and for building VIPs in 2020SP1. So I will likely stumble upon this issue again, and I will make sure to report it here.
Sorry for the confusion.
