From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

cRIO-9068 & NI-TimeSync

Solved!
Go to solution

I'm attempting to install NI-TimeSync on my cRIO-9068 without success. As shown in the attached screen shot, I've installed the NI-TimeSync software on my device but I see no time synchronization panel in the Time Settings tab as indicated in an NI white paper. What am I missing?

 

0 Kudos
Message 11 of 20
(1,617 Views)

Hi hshane,

 

At this point, we don't have configuration in NI MAX available for NI-TimeSync on Linux RT targets.

 

As long as  you have NI-TimeSync 14.5 installed to the 9068 (as I can see in your image), then synchronization via an available 1588 network will occur automatically (over the primary NIC). Details on how  you can further configure and monitor this synchronization is in this KB: http://digital.ni.com/public.nsf/allkb/3FBB102D0D65AE3486257D88007CCB20

0 Kudos
Message 12 of 20
(1,585 Views)

Since this thread is similar in topic to my platform, also a 9068, I'll just post in here:

 

I'm using this controller and its linux rtos to try and get some sort of time synchronized to the system. I will not be connecting it to other RIOs at this time, and the network has no internet connectivity. What I'm hoping is that I can somehow use the  IEEE 1588 / PTP functionality to sync up with my paired TPC 2230 touch panel (via ethernet) and get the system time that way. The TPC 2230 is Win 7 embedded but I am not sure if the 9068 will automatically recognize it as a grandmaster. Can the TPC 2230 even utilize IEEE 1588? I can't seem to find my answer in the white paper on this material, as my issue is more around device compatibility than it is on peer to peer network propagation speed / reliability. 

 

Thanks,

R

 

0 Kudos
Message 13 of 20
(1,504 Views)

I am also thinking that perhaps NTP is a better option, at this point. I don't need even 1000ms accuracy. I just need to be able to connect to a WE7 TPC to get time, whether it be a ntp daemon, ptp grandmaster, whatever.

0 Kudos
Message 14 of 20
(1,492 Views)

Hi dest2ko,

 

I think you’re right that NTP would probably be easier, and it typically provides synchronization on the order of tens of milliseconds. We have this KB that walks through the steps to set up a Windows machine as an NTP server. I’ve never tried it on Windows Embedded, but I would assume it would work. For your cRIO, you could use an open source NTP implementation. We have some community documentation here that walks through the setup. You’d just need to specify the server to sync to as your TPC.

 

If you do end up wanting to go with 1588, it should be possible, but you would need to set up your TPC as a 1588 clock. I know there are software options out there for setting up 1588 on Windows, but I’m not really familiar with them myself.

0 Kudos
Message 15 of 20
(1,483 Views)

I turns out the that the cRIO-9068 natively supports synchronization with a PTP master, though it wasn't immediately obvious. See my exchange with NI earlier in this thread. Getting NTP to work on the 9068 actually seemed like it was going to be a bit of a chore and so, since PTP is in some sense better than NTP, I decided to stick with PTP.

 

As for getting a PTP master on your network, if you're looking for a Windows-based solution, I've had good experience with Grayware Automation Products Domain Time II. (No I don't work for them!) Of course, there are open-source Linux solutions as well.

 

With the above combination, we are seeing host-to-host synchronization errors on the order of microseconds. Since I don't have a requirement for external synchronization I can't tell you how good we are with respect to UTC because I haven't measured it.

0 Kudos
Message 16 of 20
(1,470 Views)

Good to know there is a backup incase this doesn't work out. I uninstalled NI-TimeSync since literature suggests having an NTP daemon and TimeSync/IEEE5888 concurrently modifying timing registers is a big no-no.

 

Where I'm at right now: I've installed the Meinberg service on my laptop for testing, and am in the process of configuring my RIO for NTP service (in accordance with this page. Whenever I ssh in and try to execute the "opkg install ntp ntp-tickadj" command, it states "*opkg_install_cmd: Cannot install package ntp."

0 Kudos
Message 17 of 20
(1,462 Views)

It appears the repo path (http://feeds.angstrom-distribution.org/feeds/next/ipk/eglibc/armv7a/base/) in that community document is obsolete. Have you tried running "opkg update" as suggested by notes on that community post? If that doesn't fix it automatically, you'll have to poke around a bit more on the Angstrom Distribution website to find the right feed URL.

 

This is completely untested and a total shot in the dark (read: no warranty expressed or implied), but this one might work for you:

http://feeds.angstrom-distribution.org/feeds/v2015.12/ipk/glibc/armv7at2hf-vfp/base/

------
James Blair
NI R&D
0 Kudos
Message 18 of 20
(1,450 Views)

So if I'm using RT 15.0 module, should it just magically reference these, or should that article on Configuring NTP on Linux RTOS' have placed the "Configuring Third-Party Installation Sources On NI Linux Real-Time" section a little higher? And I suppose in any case, you're implying I still need to enable that repository. Still not finding anything. I'm scared to try the other link. 😉 In the glibc directory, there are a number of armv7 spinoff directories.

 

 

0 Kudos
Message 19 of 20
(1,433 Views)

The RT 15.0 module probably has a different default path than the one listed in the community document. But I wouldn't expect any of our default paths to pick up the ntp packages, so you'd still have to make an edit and point to a different repo to get those.

 

Does this repo look less scary?

https://downloads.gumstix.com/feeds/angstrom/ipk/eglibc/armv7a/base/

 


@dest2ko wrote:

I'm scared to try the other link. 


Keep in mind that none of this is Officially Supported (TM). If that makes you worry, maybe this approach isn't for you. (I'm not sure what your alternative would be -- maybe passing time data between systems using a shared variable?)

------
James Blair
NI R&D
0 Kudos
Message 20 of 20
(1,424 Views)