Time Sync with GPS Which in different Network
Hi,
GPS Clock IP is 120.0.39.39 and 800xA Nodes ,Controllers are in 172.16.4.x. Router Configuration has been done and the default gateway is 172.16.4.40. The GPS Clock is pinging with Server/Client when default gateway is added.
Default Gateway added for Controller 172.16.4.1 (Checked the same in Controller Logs) and added SNTP IP as 120.0.39.39, but its still showing 'No Sync' in Clock Sync. Is there any other setting to be done?
OR can i Sync the GPS Clock with My server ASCS1(172.16.4.21) and make ASCS1 as my SNTP for the controllers, like the Controller should sync from the Servers not Vice versa.
GPS Clock IP is 120.0.39.39 and 800xA Nodes ,Controllers are in 172.16.4.x. Router Configuration has been done and the default gateway is 172.16.4.40. The GPS Clock is pinging with Server/Client when default gateway is added.
Default Gateway added for Controller 172.16.4.1 (Checked the same in Controller Logs) and added SNTP IP as 120.0.39.39, but its still showing 'No Sync' in Clock Sync. Is there any other setting to be done?
OR can i Sync the GPS Clock with My server ASCS1(172.16.4.21) and make ASCS1 as my SNTP for the controllers, like the Controller should sync from the Servers not Vice versa.
Answers
Hi,
i sync my server to our IT network through a gateway and all my operator stations get their time from that.
my controllers then get their time from the connectivity servers.
i have run it this way for about ten years.
only thing you need to keep an eye on is the time service on windows. If you don't reboot for a very long time the time service seems to get stuck once in a while. Simply restarting the service fixes that. But this doesn't happen very often.
One of our sister companies used gps for a long time and experienced issues every year at the end of February (leap year I guess). On 1st march every year the history logs don't work. That may just be the type of gps they used.
i sync my server to our IT network through a gateway and all my operator stations get their time from that.
my controllers then get their time from the connectivity servers.
i have run it this way for about ten years.
only thing you need to keep an eye on is the time service on windows. If you don't reboot for a very long time the time service seems to get stuck once in a while. Simply restarting the service fixes that. But this doesn't happen very often.
One of our sister companies used gps for a long time and experienced issues every year at the end of February (leap year I guess). On 1st march every year the history logs don't work. That may just be the type of gps they used.
It is preferred if the controller speak directly to the GPS instead of relaying the time via another computer.
What does the controller log show? The SNTP client output messages as it connect/drop connection with the SNTP source.
The source must have a valid time (Stratum > 0) - this can easily be seen if you monitor the SNTP traffic (udp port 123) as it passes between the controller and GPS.
What does the controller log show? The SNTP client output messages as it connect/drop connection with the SNTP source.
The source must have a valid time (Stratum > 0) - this can easily be seen if you monitor the SNTP traffic (udp port 123) as it passes between the controller and GPS.
Add new comment