How does Save Version play with RT Targets?

[wiebe@CARYA]

In the same LV21 32 bit project, I try to get the .lvversion file working.

I'm not sure if it does work. A new VI still gets version LV24, so I guess it isn't working.

Should this version from the .lvversion file show anywhere?

After a right click on a single library to save it, it takes quite a while, and then all VIs in memory are saved. In version LV24...

[Craig_S.]

---

@Jim_Kring wrote:

...
- My.vi is in a library (LVLIB). I opened the library's properties and it shows a Save version of "Default"
- I tried opening a different VI that is NOT in an LVLIB and the Save Version feature respected the `.lvversion` file.

---

I can confirm that the .lvversion file does not work to control the save version of LV Libraries in the 24Q1 preview of this feature; the version must be defined in the .lvlib itself.  Using .lvversion files for libraries will be supported in the 24Q3 release, but only if the library does not specify the version explicitly, as that definition is considered authoritative.  (For projects, both the project-specified save version and .lvversion file are considered, and the earliest of the two versions is used, subject to compatibility with features in use.)

[Craig_S.]

---

@jyoung8711 wrote:

If you then try and do a "Save All" for the project, LabVIEW gives you additional pop-ups to save these template files that you really don't care about or need (at least as far as I know).

I've never seen these VIs show up anywhere else, and you don't see this behavior if you're are just working in a LV2024 project.

This is definitely a bug.  Thanks for reporting; we'll look into it.

[Jim_Kring]

---

@Craig_S. wrote:

---

@jyoung8711 wrote:

If you then try and do a "Save All" for the project, LabVIEW gives you additional pop-ups to save these template files that you really don't care about or need (at least as far as I know).

I've never seen these VIs show up anywhere else, and you don't see this behavior if you're are just working in a LV2024 project.

This is definitely a bug.  Thanks for reporting; we'll look into it.

---

Sure thing, Craig and great work on this AWESOME!!! feature. This is going to be a game-changer for LabVIEW development.

Also, I've noticed that if I open an older project in LabVIEW 2024 for setting the Save Version, as soon as I choose a new Save Version from the drop-down menu of the Project Settings, LabVIEW starts loading VIs into memory and I see the Loading dialog and it will even ask me to locate missing VIs.  This behavior feels odd to me, because I haven't actually confirmed a change -- I've just toggled a drop-down setting.  I realize that it might be doing async checks/loading in the background, yet this is the point where I've noticed things take a very long time (I think it's recompiling the project VIs behind the scenes) and hangs up sometimes (where the process gets stuck because it can't find a missing VI or something).

Looking forward to helping iron these issues out! 🙂

[wiebe@CARYA]

---

@Jim_Kring wrote:

---

@Craig_S. wrote:

---

@jyoung8711 wrote:

If you then try and do a "Save All" for the project, LabVIEW gives you additional pop-ups to save these template files that you really don't care about or need (at least as far as I know).

I've never seen these VIs show up anywhere else, and you don't see this behavior if you're are just working in a LV2024 project.

This is definitely a bug.  Thanks for reporting; we'll look into it.

---

Sure thing, Craig and great work on this AWESOME!!! feature. This is going to be a game-changer for LabVIEW development.

Also, I've noticed that if I open an older project in LabVIEW 2024 for setting the Save Version, as soon as I choose a new Save Version from the drop-down menu of the Project Settings, LabVIEW starts loading VIs into memory and I see the Loading dialog and it will even ask me to locate missing VIs.  This behavior feels odd to me, because I haven't actually confirmed a change -- I've just toggled a drop-down setting.  I realize that it might be doing async checks/loading in the background, yet this is the point where I've noticed things take a very long time (I think it's recompiling the project VIs behind the scenes) and hangs up sometimes (where the process gets stuck because it can't find a missing VI or something).

Looking forward to helping iron these issues out! 🙂

---

That might be the same hang I experienced. Maybe caused by 32 bit compiled resources on a 64 bit, either ppls and\or VIs with separate compiled code off? Of course, the bitness and\or ppls and\or sep.com.code might be all red harings,

[Jim_Kring]

---

@Jim_Kring wrote:

---

Also, I've noticed that if I open an older project in LabVIEW 2024 for setting the Save Version, as soon as I choose a new Save Version from the drop-down menu of the Project Settings, LabVIEW starts loading VIs into memory and I see the Loading dialog and it will even ask me to locate missing VIs.  This behavior feels odd to me, because I haven't actually confirmed a change -- I've just toggled a drop-down setting.  I realize that it might be doing async checks/loading in the background, yet this is the point where I've noticed things take a very long time (I think it's recompiling the project VIs behind the scenes) and hangs up sometimes (where the process gets stuck because it can't find a missing VI or something).

---

Note: I can't seem to reproduce this 👆issue, so I must have miss-perceived what happened -- I think that the loading happens when I press the OK button (and is not tied to events on the drop-down selector), so please disregard my "bug report" above.

[Jim_Kring]

For example, I have an RT+FPGA project that's currently using LabVIEW 2023 Q3 64-bit.

Can I work in LabVIEW 2024 Q1 64-bit with a project using Save Version of 2023?

If my cRIO has LVRT 2023 on it, will my project deploy VIs compiled for LV2023 -- will it "just work"?

[crossrulz]

---

@Jim_Kring wrote:

For example, I have an RT+FPGA project that's currently using LabVIEW 2023 Q3 64-bit.

Can I work in LabVIEW 2024 Q1 64-bit with a project using Save Version of 2023?

If my cRIO has LVRT 2023 on it, will my project deploy VIs compiled for LV2023 -- will it "just work"?

---

My understanding is that you can just develop the code in the previous version.  Any builds will need to be done in the desired version.  So if you want your cRIO in 2023, you will need to do the build in LabVIEW 2023.  Now the deploy could be a gray area.  Without knowing how things work behind the scenes, I think it would cause issues.

[Jim_Kring]

---

@crossrulz wrote:

---

@Jim_Kring wrote:

For example, I have an RT+FPGA project that's currently using LabVIEW 2023 Q3 64-bit.

Can I work in LabVIEW 2024 Q1 64-bit with a project using Save Version of 2023?

If my cRIO has LVRT 2023 on it, will my project deploy VIs compiled for LV2023 -- will it "just work"?

---

My understanding is that you can just develop the code in the previous version.  Any builds will need to be done in the desired version.  So if you want your cRIO in 2023, you will need to do the build in LabVIEW 2023.  Now the deploy could be a gray area.  Without knowing how things work behind the scenes, I think it would cause issues.

---

Yes, NI should have some AEs test this out to see what breaks 🙂

[AlexElb]

I'm also very excited to test this new feature.

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

edit:

I've noticed that VIs, which are in memory and cannot be saved to the Project Save Version pop up in the error list - which is awesome!

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.