LabVIEW 2022 Beta - New Features

[Christina_R]

I apologize for the delay in starting discussions around new features!

We're working on posts that will go into more details, but here's an overview:

1. Decoupling drivers from LabVIEW releases.
   • Since we don't have driver support with this Beta, this functionality isn't ready to test, but it will be an important change for LabVIEW going forward, because it means you won't necessarily need to install new drivers when you upgrade to a new version of LabVIEW.
2. Debugging MATLAB(R) scripts called from LabVIEW.
3. Configuring the version of MATLAB called by LabVIEW (when you have more than one installed).
4. Migrating Mathscript code to MATLAB in preparation for the discontinuation of Mathscript.
5. LabVIEW gRPC support, which isn't installed with this Beta but is available at https://github.com/ni/grpc-labview
6. A tool for viewing the "NI store" NIPM packages used by a LabVIEW project. Unfortunately, this tool didn't make it into the Beta, but I will share the design to get your feedback.

In addition, we are hoping to offer a preview of the Target structure in the next release. This structure integrates RT code on a host VI diagram. We're not ready for general testing of this feature, but I will be asking for volunteers to test and provide feedback. 

I had hoped to get Beta testing of the "Rearrange Z-order" methods, but I'm afraid we're going to have to back that feature out, because there are cases (with deferred event handling) where the Z-order change causes a crash, and it's going to be a significant effort to rework the feature.

Independent of any new features, though, I would greatly appreciate loading and running any applications that you can safely run with the Beta, to help us identify potential upgrade issues as early as possible.

Thanks for helping to make LabVIEW better!

[BertMcMahan]

Thanks for the info! Are there any documents on what gRPC is and how it can help? I haven't heard of it before.

[Christina_R]

---

@BertMcMahan wrote:

Thanks for the info! Are there any documents on what gRPC is and how it can help? I haven't heard of it before.

---

I recommend these presentations from the 2021 GLA summit: 

https://www.youtube.com/watch?v=0DPVrS23RRg&t=2s

https://www.youtube.com/watch?v=0FN9W9tzKaA

You can also find general info about gRPC at https://grpc.io

[ImreSzebelledi]

We would be very interested testing this Target structure. It sounds to me that we can create code in a VI (running on windows host) which is somehow deployed and run on an RT target (IC or Crio for example) and communicates somehow back and forth to the host VI. Or did I missed the point completely? We are constantly struggling with using our codebase both on a windows pc and on a target as well so this is something which could be of immense help to us.

[Intaris]

---

@ImreSzebelledi wrote:

We would be very interested testing this Target structure. It sounds to me that we can create code in a VI (running on windows host) which is somehow deployed and run on an RT target (IC or Crio for example) and communicates somehow back and forth to the host VI. Or did I missed the point completely? We are constantly struggling with using our codebase both on a windows pc and on a target as well so this is something which could be of immense help to us.

---

I'm having trouble envisaging the proper use-case here.

Is this an attempt to mitigate some of the target-locking issues (inability to edit) encountered when files are in use on multiple targets?

[Mads]

A target structure like that would have been cool yes. Especially if it allowed us to transparently distribute the computation, not just to one, but multiple targets. Having it in a structure sounds a bit static though...It depends on how you are allowed to configure it. Being able to distribute the processing dynamically to any available target would be even better. We can always dream 😀

I dreamt of something like that here:
https://forums.ni.com/t5/LabVIEW-Idea-Exchange/For-loop-parallelism-across-multiple-remote-targets/i...

[ImreSzebelledi]

We solve that issue by having separate projects for every target we use. Of course you can only have one project open at a time but we can live with that (this locking is still a mistery to me). What is a major pain though is that labview recompiles the source code each time we switch context. I cannot understand why can't the compile object cache store compiled code for multiple context (target). 

[Hooovahh]

---

@ImreSzebelledi wrote:

We solve that issue by having separate projects for every target we use. Of course you can only have one project open at a time but we can live with that (this locking is still a mistery to me). What is a major pain though is that labview recompiles the source code each time we switch context. I cannot understand why can't the compile object cache store compiled code for multiple context (target). 

---

We have the same process.  Once our project gets too large, switching contexts, and syncing becomes difficult to manage.  So we just have one project for each target too.

[ImreSzebelledi]

Of course this results in a quite cumbersome debugging process when you would like to debug both on windows and rt at the same time, so I would like to check anything out which can remotely help us. That being said, we don't even know what this feature really is but I am exited. 🙂

[Bas.v.E]

Can you explain a bit more about the "decoupling drivers from LabVIEW" feature? What does this mean and which drivers are we talking about?

Does this mean I can use the cRIO2018 drivers while programming in LV2022?

Do you also know a release date?