CPU time synchronization (NTP)- time synchronization is lost

Hello, I have a similar problem trying to use Windows as NPT Server and PLC as NPT Client. I was able to set a NPT server and to synchronize them, but for some reason the date and time is desynchronizing.
I do not have a router in my case between then.
I tried different scenarios but none of them worked yet. The synchronization is working but I am checking after some days, it’s desynchronized by days…

If you have any idea how should i configure the synchronization, will be helpful.

Thank you!

Hi @DragosMarin,

right now I haven’t any idea what could be causing this behavior.

It’s very unusual that the clock is desynchonized by days after some days, so even for example if the NTP server is not accessible but the RTC was synched before, there should not be such a big time difference (the normal time jitter on a RTC is about “some seconds per day”).

To get a better idea how to diagnose, could you please provide some more information about:

  • can you please check if the battery of your PLC is ok (see here)?
    • The battery state can be checked for example with Automation Studio “Online → Info”
  • is the PLC and/or the NTP server switched off from time to time, or are the systems powered on 24/7?
    • Is the NTP server (192.168.138.2) always accessible, especially while the PLC does a startup for example after a power fail, or is the NTP server also powered off when the PLC is switched off?
  • are there any entries in the system logger regarding “date / time set”, “RTC”, or “sys clk step adjustment”?
  • Which version of Automation Runtime do you use?

Best regards!
Alex

1 Like

Hi,

The accuracy of NTP time synchronization depends strongly on the accuracy of the time server being used.
For parameter & setting details, please check help.
https://help.br-automation.com/#/en/4/projectmanagement%2Fsystemconfiguration%2Fsg4%2Fcpu%2Fprojectorganisation_systemconfiguration_sg4_cpu_ntp.html

1 Like

Hello Dragos,

The configuration screenshot you posted looks like a Hypervisor system. Is the Windows NTP server you are referring to the GPOS of that Hypervisor?

If so, then you should not be using NTP to synchronize between AR and Windows. See AS Help link below.

If you are connecting to another Windows NTP server, then maybe the time synchronization between AR and the GPOS on the Hypervisor system are interfering with each other.

See the time synchronization entry in the Hypervisor FAQ in the B&R Online Help (br-automation.com).

2 Likes

Hello Austin,

Yes, I am synchronizing to another Windows NTP server then the Hypervisor.

Having this topic in mind, Probably, the time is automatically synchronizing with the GPOS time. (That is the only explanation i have for the 2 days difference). I cannot verify that until I will be on site…
If this is the case, do you have any idea how should I stop the synchronization between GPOS and AR?

Hello Alexander and thank you!

Austin noticed well that in my system i am using Hypervisor but I need to synchronize with another Windows NPT server.
It will not be a big surprise that the “2 days delay time” to be the time of the GPOS… I cannot test it yet because i do not have remote connection to that GPOS.
If this is the case, and the AR is automatically synchronizing with the Hypervisor GPOS, can i stop that?

Thank you!

I think they are actually using the same hw clock. So if the NTP on the GPOS is active or you set the time there, it will also change in the AR. That is the reason why you should only use NTP on one of both systems afaik.

See also the RealTimeIsUniversal windows registry setting in
(B&R Online Help)

What should be considered when synchronizing the time between Automation Runtime and the GPOS?

1 Like

Hi Dragos,

as the colleguages already mentioned, the sync between GPOS and AR cannot be disabled because both operating systems are using the same Real Time Clock hardware.
So using NTP in both operating systems can / will interfer each other by setting the RTC within different timeslots → so you have to decide one of the systems to act as NTP client, and disable the NTP client inside the other OS.
Additionally, like described in the FAQ help link, it’s mandatory for Automation Runtime to have the UTC time inside the RTC, so you have to setup in your GPOS using UTC also.

I can imagine that one of those, or the combination of the 2 factors lead to the behavior on your system, because looking inside your logger (thanks for posting the screenshot!) shows that the clock is changed by AR very frequently → of course setting the clock is exactly what NTP should do, but it happens very more often that I’ve seen it on other systems.

I hope the information from the colleguages and me are helpful and will solve the issue.
Best regards!
Alex