Interesting Announcements from NI Connect?

[Reds]

Has anyone noted anything particularly noteworthy from NI Connect this week?

One thing I noticed is that NI is going to be decoupling NI driver versions from LabVIEW version numbers. I think this means that you will be able to use any version of LabVIEW with any version on hardware driver in the future. 

Anyone notice any other announcements of interest?

[crossrulz]

A new hardware platform called TestScale sounds interesting.  Unfortunately, NI's web site has no information on it yet.

[Rolf Kalbermatter]

16 hours ago, Reds said:

Has anyone noted anything particularly noteworthy from NI Connect this week?

One thing I noticed is that NI is going to be decoupling NI driver versions from LabVIEW version numbers. I think this means that you will be able to use any version of LabVIEW with any version on hardware driver in the future. 

That is a bit of an overreaching statement! It does not mean that you can call any version of driver with any version of LabVIEW. For one thing, most driver installers come with LabVIEW VIs and they have a minimum version in which they are compiled. No dice in trying to install those VIs into a LabVIEW version that is older than the VI format that is included in the installer. It does probably mean that an installer only comes with one version of VI libraries (the supported minimum version) and that it will invoke a mass compile after installation. And there is of course the option that some of those VIs use features that may get depreciated in a future LabVIEW version and eventually get disabled so that some driver VIs might not load without broken error in a far out version of LabVIEW.

I wondered about TestScale too. The available webpage on the NI site is however underwhelming to say the least. The text and picture shown would be worthy for a preliminary PowerPoint presentation during an early product design meeting but not for something that is supposed to get released anytime soon.

Edited May 25, 2022 by Rolf Kalbermatter

[hooovahh]

Spurred by Tim's post elsewhere, I did a Google search and found this page talking about TestScale.  Apparently Averna is familiar with it, so that would make me assume it is more than a preliminary PowerPoint.

[Rolf Kalbermatter]

Quote

Spurred by Tim's post elsewhere, I did a Google search and found this page talking about TestScale.  Apparently Averna is familiar with it, so that would make me assume it is more than a preliminary PowerPoint.

I know it is. But I'm not involved in that project. Still find that webpage on the NI site much less than overwhelming! 😀

[JB_1592]

3 hours ago, Rolf Kalbermatter said:

Still find that webpage on the NI site much less than overwhelming! 😀

 

I find most pages on NI.com to be pretty underwhelming these days. Mostly marketing buzzwords and very little substance.🤮

[Reds]

8 hours ago, Rolf Kalbermatter said:

It does probably mean that an installer only comes with one version of VI libraries (the supported minimum version) and that it will invoke a mass compile after installation. And there is of course the option that some of those VIs use features that may get depreciated in a future LabVIEW version and eventually get disabled so that some driver VIs might not load without broken error in a far out version of LabVIEW.

The issue I've found is not the LabVIEW vi's bundled with the driver installers. The *real* issue is the property nodes. Some drivers, like NI-RFSA, have tons of things that can only be set through a property node. You can recompile and move/copy vi's to your heart's content, you'll never get those property nodes to work in any version of LabVIEW that is not "supported". I'm certainly hoping that they find a way to allow property nodes from any version of NI-xxxx to work in any future version of LabVIEW. One can dream, right...

[X___]

From the link above:

Quote

The hardware connects to NI and third-party software such as TestStand, LabVIEW, and Python using the commonly used, fully featured, and reliable NI-DAQmx driver. 

LabVIEW is now third party software for NI?

Kind of consistent though with making it its own independent product line, the survival of which will be justified by number of annual licensed paid for...

[jacobson]

1 hour ago, X___ said:

LabVIEW is now third party software for NI?

Kind of consistent though with making it its own independent product line, the survival of which will be justified by number of annual licensed paid for...

Software is being modified by both NI and third-party so I think it would be safe to assume that LabVIEW is included under the umbrella of "NI software".

[Rolf Kalbermatter]

2 hours ago, Reds said:

The issue I've found is not the LabVIEW vi's bundled with the driver installers. The *real* issue is the property nodes. Some drivers, like NI-RFSA, have tons of things that can only be set through a property node. You can recompile and move/copy vi's to your heart's content, you'll never get those property nodes to work in any version of LabVIEW that is not "supported". I'm certainly hoping that they find a way to allow property nodes from any version of NI-xxxx to work in any future version of LabVIEW. One can dream, right...

Those properties and methods are part of the object manager interface. This is despite its name not the same as LabVIEW classes. It was introduced with NI VISA back in LabVIEW 4 or 5 and later improved for other software interfaces. The according files have the ending .rc and .rch and are located in the resources/objmgr directory in LabVIEW. They define the menu hierarchy in the property and method nodes and the connection between them and the actual shared library (DLL) implementation for that interface. The same object manager infrastructure is in fact also used for Active X, .Net and in some way the LabVIEW VI Server interface but these are not defined by external .rc files but directly in the c++ source code of LabVIEW.

If you want to change what methods and properties are available for a certain class you need to change these files too, but of course the properties and methods that are defined in those files need to connect to correct selectors in the according shared library, so adding new entries in the .rc file alone yourself makes little sense.  You also need to have the shared library version that implements them. On the other hand only changing the shared library doesn't add new properties and methods to the object manager resources. You also need to copy the according .rc and .rch files. But beware, those files can implement different versions of object manager resource formats and there is a chance that if you copy one meant for a much newer LabVIEW version, it will make an older LabVIEW version not recognize the file at all as the version is to new for it to know about it.

And the actual interface implementation for this interface is in most cases a separate shared library on top of the more generic driver library. The driver library implements the real business logic and the low level C interface that can be also used from other programming software. The higher level library is very much LabVIEW specific as it needs to directly provide LabVIEW native datatypes such as string handles to plug easily into the object manager interface. For the more esoteric features such as events it even must provide very specific functionality that connects the event to the LabVIEW user event mechanisme.

Edited May 25, 2022 by Rolf Kalbermatter

[JamesMc86]

My understanding of the decoupling is that I think there is a gRPC server that runs in the background which the decoupled API talks to.

So the decoupling is done through API versioning I guess. DAQmx 22 would be API v1 and as long as they don't have to increment the API number then the LabVIEW API will continue working. Unless there is also a discovery mechanism like the .rc files?

At some level the API will need to understand newer functions but I guess they are betting they will be few and far between for something as mature as DAQmx.

All a bit of a guess as I can't find any details from NI yet. Except this very familiar feeling article from last year! https://www.electronicspecifier.com/products/test-and-measurement/labview-2021-enhancements-unveiled-at-niconnect

[cordm]

Seems spot on. NI has a repository https://github.com/ni/grpc-device that contains a "gRPC server providing remote access to NI device driver APIs". At the moment only the more recent drivers are tested.

[crossrulz]

We got some more clarification on the "decoupling driver versions" on the public beta forum: https://forums.ni.com/t5/LabVIEW-2022-Public-Beta/LabVIEW-2022-Beta-New-Features/m-p/4234011#M49

 

In short, there will be a new common location that the driver will install the LabVIEW Support to and LabVIEW will look there.  They will depend on the "Separate From Compiled" to allow the VIs to be used by multiple versions of LabVIEW.

[Jordan Kuehn]

Enterprise version of SystemLink with containers sounds fantastic. Hopefully they will include it with the already expensive license cost. 

[JamesMc86]

Yeah I got a couple of things mixed up based on the whats new presentation now at https://www.youtube.com/watch?v=PcQd6YstpTo

 

The decoupling is different from the gRPC of drivers (NI Remoteability as it was called in the presentation).

The way I read the decoupling is that newer versions of LabVIEW will officially support older versions of drivers. i.e. 2023 DAQmx can be supported by LabVIEW 2024 as LabVIEW can generate the APIs it needs (and probably other use cases, but that seems like the significant one)

[hooovahh]

2 hours ago, JamesMc86 said:

The way I read the decoupling is that newer versions of LabVIEW will officially support older versions of drivers. i.e. 2023 DAQmx can be supported by LabVIEW 2024 as LabVIEW can generate the APIs it needs (and probably other use cases, but that seems like the significant one)

This is a neat feature, but I feel like it would have been more beneficial had it came out 10 years ago or so.  We've struggled with multiple versions of LabVIEW and drivers on a single OS, so now many developers will use VMs or Docker to sandbox a project to only have one version of LabVIEW, and the right version of the tools it uses.  I feel like we've all gravitated to this due to the issues that come up with trying to manager version interoperability.

I do still have a few versions of LabVIEW installed on my main machine.  But if I'm ever building a binary I make sure and do it in the right VM for the project, so an older project doesn't now suddenly rely on the newest version of some dependent tool. 

[Rolf Kalbermatter]

9 minutes ago, hooovahh said:

This is a neat feature, but I feel like it would have been more beneficial had it came out 10 years ago or so.  We've struggled with multiple versions of LabVIEW and drivers on a single OS, so now many developers will use VMs or Docker to sandbox a project to only have one version of LabVIEW, and the right version of the tools it uses.  I feel like we've all gravitated to this due to the issues that come up with trying to manager version interoperability.

I do still have a few versions of LabVIEW installed on my main machine.  But if I'm ever building a binary I make sure and do it in the right VM for the project, so an older project doesn't now suddenly rely on the newest version of some dependent tool. 

Definitely agree that it should have been done like that many moons ago already. But it was in a way maybe easier to do it like that as there was limited testing needed and maybe there was also a bit of an intention behind it as if you wanted to use new hardware you had to install the new driver and that made also a new IDE version necessary if the previous one was to old. So a bit of a hidden upgrade nudge. Now with the new NI structure where the different software departments are very much decoupled and independent from each other it proved to be an unmanageable modus operandi. It's not feasible anymore to have to pester DAQmx (and cRIO and System Control and, and, and) folks to release a new version of their software simply because there is a new LabVIEW version.

[crossrulz]

33 minutes ago, Rolf Kalbermatter said:

Definitely agree that it should have been done like that many moons ago already. But it was in a way maybe easier to do it like that as there was limited testing needed and maybe there was also a bit of an intention behind it as if you wanted to use new hardware you had to install the new driver and that made also a new IDE version necessary if the previous one was to old. So a bit of a hidden upgrade nudge. Now with the new NI structure where the different software departments are very much decoupled and independent from each other it proved to be an unmanageable modus operandi. It's not feasible anymore to have to pester DAQmx (and cRIO and System Control and, and, and) folks to release a new version of their software simply because there is a new LabVIEW version.

In my opinion, part of the issue was getting confidence in the "separate from compiled" feature.  I would have to dig into some history to figure out when NI started using it for vi.lib.  But shortly after that, it would make a lot of sense to push this in the drivers.  So if you really want to play the hindsight game here, it is something that should have been feasible around 5 years ago.  But NI was putting all of its marbles into NGX at that time.

Regardless, I am happy about this feature and I look forward to being able to avoid updating drivers purely for the "new LabVIEW version support" and no other changes.

[Rolf Kalbermatter]

55 minutes ago, crossrulz said:

In my opinion, part of the issue was getting confidence in the "separate from compiled" feature.  I would have to dig into some history to figure out when NI started using it for vi.lib.  But shortly after that, it would make a lot of sense to push this in the drivers.  So if you really want to play the hindsight game here, it is something that should have been feasible around 5 years ago.  But NI was putting all of its marbles into NGX at that time.

Regardless, I am happy about this feature and I look forward to being able to avoid updating drivers purely for the "new LabVIEW version support" and no other changes.

I think the separate compiled code is only a by-product. It could have been done even without the VIs having been set to use separate compiled code. In the worst case the VIs would have been compiled the first time you open a project that uses them. So what?

Inconvenient? I don't think so, at least not nearly as much as having to always chase the right drivers.

[hooovahh]

SystemLink Enterprise discussion moved to here.

[Dataflow_G]

There's a couple of videos on NI's youtube covering new hardware and software products. They're both heavy on marketing and light on details, but put things like TestScale into context.

Hardware: https://www.youtube.com/watch?v=-8VGCjzJjWk

Software: https://www.youtube.com/watch?v=hH8VFB9jtzM

Edit: That ShireyStudios youtube account also uploaded some new NI Connect videos in the past couple of days. Did they manage video recording of the event? Kinda surprised the vids aren't on NI's main account.

Edited June 14, 2022 by Dataflow_G

[crossrulz]

Mark Balla and Kevin Shirey managed to record a bunch of the sessions.  Links are available on LabVIEW Wiki. https://labviewwiki.org/wiki/NI_Connect_2022

The NI videos Dataflow_G links to is from the the opening keynote.

Edited June 14, 2022 by crossrulz

[Reds]

For those interested in an announcement I mentioned at the start of this thread: