Hi,
The first thing I'd like to say is that it's a shame that the time can't be set effectively on the Linux RT target, and that the only way to do this is to use NI MAX or the "Set time" function from the System Configuration, which is slow, memory-consuming and easily produces errors of up to 3 seconds. In the video from 2019 (https://www.ni.com/en/shop/compactrio/compactrio-timing-and-synchronization.html) I learned that "some functions are not ready for Linux RT targets, but this will be fixed very soon". Today is the fall of 2024.
Time synchronisation is generally poorly documented and pretty much does not work, even if everything is done according to the manuals. There are actually a number of manuals on the same subject (how to set up time synchronisation on the Linux RT cRIOs), but none of them are complete, they are missing important information, they contradict each other in some places (especially suggested configs), or they are just plain wrong. I've spent a lot of time on this this week and still can't get it to work. Maybe it is just me.
Anyway, my findings are below (cRIO 9053 and a struggle to synchronise the time with the PC).
Disposition:
- Compact RIO NI 9053, Linux RT 2024 Q3 (latest as of today).
- Connected to a Windows PC via USB-network cable (console port), i.e. PC is 172.22.11.1 and cRIO is 172.22.11.2.
- All the required firewall ports are open for anyone (confirmed with the NTP client on other computer).
What I tried/found:
- Followed the same manual as you have used, https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YIF2CAO&l=fi-FI There are funny thing about it, is that it is suggests that the cRIO has access to the Internet, which is not always true or easy to achieve, but whatever. While this manual tells, that "To use NTP with TSN-enabled targets, such as the cRIO-904x and 905x, the Linux OS time needs to be desynchronized with the network time." and even provides the how-to instruction (https://www.ni.com/en/support/documentation/supplemental/21/use-ntp-for-timestamping-measurements.ht...), this instruction does not explain, should this be done only when I want to use 802.1AS, or it is valid for 1588 as well? (hint: none of the four combinations do not work).
- Important part, "How do I configure my host computer as NTP Time Server" (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YIeDCAW&l=fi-FI) tells us, that the Windows time server is no-no. Well, it would be great to see the mention about that in all the other manuals, including the first one. And, anyways, while I was able to at least connect to the Windows time server in #1, the recommended setup of the Meinberg NTP is not working at all.
- Older manual https://forums.ni.com/t5/Example-Code/Installing-and-Configuring-NTP-on-NI-Linux-Real-Time-Devices/t... does not work either.
- This is more related to the synchronization of the multiple cRIOs (or equivalent) between each other, but still. The manual "Monitor and Configure Time Synchronization on Embedded Devices" (https://www.ni.com/en/support/documentation/supplemental/17/monitor-and-configure-time-synchronizati...) tells that the time references must be selected to drive the time of the device. There is a related manual on that, but it is only valid for the NI-Sync version 18.0 or earlier. What the users of the newer versions should be doing - big mystery.
- Additionally, the example "Monitor and Configure Time References" shows that in 1588 mode the clock state is always "Faulty" (regardless Master/Slave configuration) and in the 802.1AS mode the clock state is always "Disabled", not AS capable and not selected. I can't find any explanations anywhere, how to read and understand these values.
- Interestingly, that with the theoretically incompatible Windows time server I was able to set a proper connection to NTP and get the quite accurate offset between the PC and cRIO (as far as I was able to check, better than 50 ms). The problem is, that even if the offset is known, cRIO for some reason does not correct it's own internal clock time. In the ntpd.log I see something like, but that's it:
19 Sep 10:43:53 ntpd[1635]: Listen and drop on 0 v6wildcard [::]:123
19 Sep 10:43:53 ntpd[1635]: Listen and drop on 1 v4wildcard 0.0.0.0:123
19 Sep 10:43:53 ntpd[1635]: Listen normally on 2 lo 127.0.0.1:123
19 Sep 10:43:53 ntpd[1635]: Listen normally on 3 lo [::1]:123
19 Sep 10:43:53 ntpd[1635]: Listen normally on 4 usb0 [fe80::280:2fff:fe36:94df%3]:123
19 Sep 10:43:53 ntpd[1635]: Listening on routing socket on fd #21 for interface updates
19 Sep 10:43:53 ntpd[1635]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
19 Sep 10:43:53 ntpd[1635]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
19 Sep 10:43:57 ntpd[1635]: Listen normally on 5 usb0 172.22.11.2:123
- Also I was able to synchronize with the local NTP on the Linux machine on the same network, but the outcome the same as I can see with Windows time: the offset calculated correctly, but local time is not corrected.
- Oh yes, and this document https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019XmjSAE&l=fi-FI says that "TSN-enabled targets (such as cRIO-904x targets) are not currently compatible with any type of synchronization besides IEEE-1588 (PTP) and 802.1AS synchronization." For me currently it reads like "TSN-enabled targets (such as cRIO-904x targets) are not currently compatible with any type of synchronization".
After all, the promised sync quality of 1 ms or even 1 us at the moment looks like a bad "up to" advertisment (https://www.ni.com/en/shop/compactrio/choosing-a-compactrio-synchronization-technology.html), because right now I see a nearly 2 seconds offset.
I would really appreciate if someone can provide the working step-by-step instruction for the TSN-enabled Linux RT target, connected via [USB-]network to the Windows PC.
P.S. Sorry for rant.
