Automotive and Embedded Networks
XNet 21.5 No RT Support
So I found a bug with XNet. It looks like when it imports my DBC into the database it doesn't import all of the signals properly. I isolated the test case, and saw where the problem was happening. But I wasn't running the newest version of XNet. So before I opened a bug with NI I downloaded the latest 21.5 of XNet and tested it out. The issue went away and so my solution was just to use the newest version of NI-XNet.
However when I started deploying this to my test stands I realized my XNet version on my RT system didn't match my Windows version. But I didn't have an option to upgrade it in MAX. So I did a full uninstall and reinstall in Windows and it still wasn't an option. Then I found this table of version compatibility.
Not only does it show that Linux RT and Phar Lap support have been removed, but also Windows 10 is no longer supported, and Windows 11 support was not added. According to this table only Windows servers 2019, and 2016 are compatible with XNet 21.5. Is this a mistake? I'll be downloading XNet 21.0.1 and seeing if this fixes my DBC issue. NI I want to know what the planned compatibility is. Is RT support for XNet going to come back? What about Windows 10? Thanks.
EDIT: Actually after looking at 21.0.0, 21.0.1, and 21.5.0 I don't think any of these actually have RT support. 20.5.0 is about 400MB larger than these next 3 releases, and after installing each of them I don't see an option in MAX to install XNet on my ARM based embedded cDAQ running Linux RT. During the install I select LabVIEW Real-Time support, but in the C:\Program Files (x86)\National Instruments\RT Images\NI-XNET folder I don't see any Linux RT support.
After reaching out to NI multiple times in the last month or two and getting no response, I opened a support ticket. The result wasn't really what I wanted to hear but I wanted to update everyone here in case others saw the same issue.
NI RT controllers get updated through MAX. For all NI controllers up until recently, the method of updating was a custom NI solution. This involved a set of files and post install, or post remove scripts telling the controller what to do after copying some files. These are the files found in C:\Program Files (x86)\National Instruments\RT Images. NI recently has been releasing their RT software as OPKG packages, in addition to the older custom method. OPKG is an open source software installation tool used by various other Linux distros. Since doing this NI has offered two ways of installing RT software. The first method I described has been labeled the Custom Software, and newer method is using RT System Images. The two methods aren't compatible, and if you change from one method to the other, the controller must be formatted and all software reinstalled.
Well starting with version 21 of XNet, the only method of installation is through OPKG, and through the RT System Images. This means if you want to use XNet version 21, you must us the System Image, you cannot use the Custom Software, and can't use any 3rd party tools that install through the Custom Software option. This is not documented or made clear when installing RT or XNet software.
On the plus side the RT System Images means that you can install NI software, not on the host. This is because the controller can download the needed packages and install them from the internet. There is also an offline install option which involves installing all of the needed packages to the host, and then having the RT controller get the files from local feeds, instead of getting them from the internet. This explains why the installer for XNet 21 and later is smaller. Because it isn't including the tools for RT in it. The controller will download them as needed.
I recognize that this newer software install method is better in several ways. But having to format, and reinstall all of the NI software, either from the internet or local feeds, takes a while. In addition to that I use some 3rd party tools that don't exist as OPKG. I either need to come up with custom install options for them, or rewrite my software to not use them. If you have an existing program that uses a custom software install, and that software does not have an OPKG install option, then you either can't update XNet to 21, or you need to re-write parts of your application.
A minor secondary issue NI mentioned is that the compatibility chart on the previously linked page was incorrect and is going to be updated.
