How to enable SystemLink health tags for Linux RT 2020?

[JKSH]

For older versions of RT software (say, 18.5) we had to explicitly install SystemLink Client onto the target via NI MAX in order to make it SystemLink-compatible. After that, the target would automatically publish health tags (like Health.Memory.Free and Health.CPU.0.UsePercentage) to the SystemLink Server.

Newer versions of the Linux RT System Image seems to have SystemLink compatibility built into the base image. However, after I installed "Linux RT System Image for Q2 2020" and added my CompactRIO to the SystemLink Server, it doesn't publish any health tags.

How do I get the health tags back?

[JKSH]

Contrast with a system which had SystemLink Client 18.5 installed:

[JoshuaP · Accepted solution]

In 20.0 we changed from publishing health tags from AMQP to HTTP to cut down on the number of ports the clients were using for connecting to the server and make it easier to have more granular permissions.

My guess, is that there is something in the NI Web Server Configuration utility that is preventing the clients from connecting over HTTP.  I would recommend checking the preferred hostname on the Remote tab.  It defaults to the hostname of the server, but you may need to change it to match the name the target is using when connecting to the server for example a fully qualified domain name or a DNS alias.

Also, if you are using an SSL certificate make sure it includes the preferred hostname and the name the clients are using when connecting to the server.

[JKSH]

Thanks Joshua, I'll have a closer look at the server settings

Fewer ports per device sounds positive. Does this use HTTP Keep-Alive connections?

Currently, all our custom SystemLink-related code is using AMQP. We picked AMQP because early benchmarks showed that tag writes over AMQP had higher throughput and lower CPU usage than HTTP. Is this still the case?

[JoshuaP]

In 2020 we made a lot of changes to the tag service, so you may want to test the bench marks again to see if the gap has closed.

To keep the HTTP connection alive I think you do need to ensure you are reading or writing tags at least once every 10 minutes to keep the port open.  Otherwise it may be better to close the connection and only open the tag when you are ready to read/write.

[JKSH]

---

@JoshuaP wrote:

My guess, is that there is something in the NI Web Server Configuration utility that is preventing the clients from connecting over HTTP.  I would recommend checking the preferred hostname on the Remote tab.  It defaults to the hostname of the server, but you may need to change it to match the name the target is using when connecting to the server for example a fully qualified domain name or a DNS alias.

---

Hi Joshua,

I haven't gotten round to investigating the settings that you suggested yet. However, a similar issue has cropped up on a cRIO with SystemLink 18.5 that was shipped to a customer for evaluation.

They have an evaluation server (2020 R2) on-site. They were able to add the cRIO (SystemLink 18.5) to their server, and are able to perform jobs like manage feeds. However, the health tags aren't coming through.

Prior to shipping, we gave the cRIO a static IP address (specified by the customer) and double-checked that the tags come through to our server (which is on the same subnet as the cRIO).

Since this cRIO is running 18.5, I presume it's publishing health tags via AMQP, not HTTP. Does the "preferred hostname" still matter in this case? Any suggestions on how to troubleshoot this (which log files to examine, for example)?

Thanks in advance.

[JoshuaP]

In that case, it is most likely using AMQP.  If they are using a static IP address, they will need to ensure it is specified in the RabbitMQ configuration to ensure it is on the TLS certificate.  I think we add the standard Windows IP addresses to the cert, but if it is an IT created static IP address that is being redirected to the server it won't be on it by default.

[JKSH]

An update:

The 18.5 client started working after the server was rebooted.

Rebooting didn't help the 20.0 client. Joshua, you were right about the HTTP configuration beign the culprit: It turns out that the server was not configured to be discoverable by its hostname over the LAN. I changed NI Web Server Configuration > Remote > Preferred host name to the server's IP address. After that, new clients that are added to the server can publish health tags without any problems.

For the existing clients though, I had to dive into the controller's config files and edit /etc/natinst/niskyline/HttpConfigurations/http_master.json to change the URI.

Questions:

1. How do I auto-update /etc/natinst/niskyline/HttpConfigurations/http_master.json when I change the server's settings?
2. It looks like the Tag service uses the "preferred hostname" while the Package Repository service always uses the IP address, even though both of these work over HTTP. Is this expected?

[JoshuaP]

The /etc/natinst/niskyline/HttpConfigurations/http_master.json file should automatically be updated anytime the client reconnects to the the server. In most cases, you can either reboot the server or reboot the client after changing the web server configuration to trigger everything to update.