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

[Craig_S.]

---

@AlexElb wrote:

...

I've set the LV project version to 2017. Without opening all VIs, they didn't seem to get converted. So I did a mass compile on the repository and got this message about System Exec.vi

Failed to save.
    Error: 1536
    Path : C:\Program Files\National Instruments\LabVIEW 2024\vi.lib\Platform\system.llb\System Exec.vi
    Flags : 1052672
    Target Version: 17008000

---

So, it looks like this is an existing issue with Mass Compile in that we attempt to load and save even dependencies in vi.lib.   The reason this doesn't cause problems normally is because the VIs are already saved in the current version.  In this case, that System Exec VI is password protected and can't be saved to the selected target version, so it shows up as an error.

Thanks for reporting the issue; we'll look into how to address it.

---

But, how to check that for all VIs in a project without opening all VIs? Seems like a mass compile is the only way, to find all VIs in the project which cannot be saved in that version.

Sure, the main use case is to work on projects which are already maintained in an older version, in which case, this isn't a problem.

---

I'll record this as a feature request as it seems like a good idea.  Note: it is not actually an error to attempt to save a VI to an earlier version than first supported the feature set it uses; instead, the VI automatically saves to the earliest compatible version instead, so that work isn't lost; in this case, Mass Compile would not report any error.  However, a Mass Compile could explicitly log all VIs which could not save in the intended version so such issues are easier to find without loading all the VIs in a large project. 

[Oli_Wachno]

Bit of a late guest here....

just started to play with this feature --

My structure is lvproj -> lvlib -> vi

- all VIs have the "Separate compiled code from source file” checkmark set.

- Project is set to 2019 

- lvlib as well 

When opening the VIs in 2024Q1 (prePatch), Save Format is shown as

Opening lvlib file or lvproj with a text editor, they state the version as 19...

Opening the lvlib with LV2019 works, but all of the contained VIs can't be opened, since they still seem to be in 2024 though stating otherwise in 2024Q1.

What could I be doing wrong here?

Cheers

Oli

[AlexElb]

If you create and save a VI with LV24, add it to a lvproj with save version set toLV18 and only save the project, the VI will NOT get converted to LV18. No bug from my point of view.

If you open that VI with the save version set toLV18 in the context of that new project, you need to save it once more.

So if you want to backsave an already existing project, you should still use the "save for previous version" feature from the file menu. Or - to make use of the new save version feature - open the new project with that version set and do a mass compile on your source folder.

[AlexElb]

Hey there,

I'm running into a problem when calling a dll. I would guess its related to 64 bitness, but both LV installations (on different VMs) are x64. Steps to reproduce:

1. withing LV24 (64bit), create a lvproj with save version LV18
2. create a VI and drop vi.lib\Analysis\1siggen.llb\Sine Wave.vi
3. save and open with LV 18 (64bit)
4. the VI is broken, the path to the DLL seems to be a NI specific build path, manually relinking to C:\Program Files\National Instruments\LabVIEW 2018\resource\lvanlys.dll doesn't work

Can someone confirm this issue?

Edit: The issue doesn't seem related to the new LV24 feature. The VI which calls the .dll is broken on LV18x64, but opens fine on LV18x32.

[Jim_Kring]

I wanted to re-share a link to this tool I created a while back. It shows a list of all VIs beneath a folder and their Save Version. It also allows you to select (a set of) individual VIs and explicitly Save for Previous **in place**.

I think we need some kind of tool/view like this, as a companion to the Save Version feature to show the state of project files on disk.

https://github.com/jimkring/a-version-explorer-for-labview

[Jim_Kring]

@Craig_S. I've run into Error 1536 in the following situation.

I have a project saved in LV2020.  I have a `.lvversion` file in my project root containing a value of `20.0`

I am testing my build process in LV2024Q1.

My build process opens references to all VIs in memory an then invokes the Save Instrument method on the VIs -- kind of like a home-built mass compile.  Some of the VIs in memory are password protected and when attempting to call Save Instrument on these pw protected VIs, I get the following error:

Error 1536

Possible reason(s):

LabVIEW: (Hex 0x600) To save a password-protected VI for a previous LabVIEW version, you must enter the password.

This might be considered "expected behavior" but it's the first time that this code-base has encountered it, so I figured I would log it here for consideration and discussion as to what people should expect and how to handle the situation.

[Craig_S.]

---

@Jim_Kring wrote:

Error 1536

Possible reason(s):

LabVIEW: (Hex 0x600) To save a password-protected VI for a previous LabVIEW version, you must enter the password.

This might be considered "expected behavior" but it's the first time that this code-base has encountered it, so I figured I would log it here for consideration and discussion as to what people should expect and how to handle the situation.

---

Are the password-protected VIs from <vi.lib> or your own password-protected VIs?

[wiebe@CARYA]

---

@Craig_S. wrote:

---

@Jim_Kring wrote:

Error 1536

Possible reason(s):

LabVIEW: (Hex 0x600) To save a password-protected VI for a previous LabVIEW version, you must enter the password.

This might be considered "expected behavior" but it's the first time that this code-base has encountered it, so I figured I would log it here for consideration and discussion as to what people should expect and how to handle the situation.

---

Are the password-protected VIs from <vi.lib> or your own password-protected VIs?

---

Also, is separate compiled code on? That is required, but I'd overlook that for PW protected VIs.

[Christina_R]

---

@AlexElb wrote:

The issue doesn't seem related to the new LV24 feature. The VI which calls the .dll is broken on LV18x64, but opens fine on LV18x32.

---

It sounds like this was an issue with 64-bit LabVIEW 2018. Since it's not related to the Beta feature, I suggest posting your question in the regular LabVIEW forum. (Note, though, that LabVIEW 2018 is no longer in Mainstream Support.)

[Jim_Kring]

Hi Craig,   Yes, I’m thinking it was a VI under LVAddons but I can’t reproduce it at the moment. It’s most likely the bug you referenced (that’s been fixed for 24Q3). I’ll keep an eye on it and let you know if it pops up again with any useful new info.

thanks!