Time Server Issues

[PLCwannabe]

I recently updated a couple plcs to 2.10 os, both using time sync mode as a client, but the time server plc is still 2.9 os. Both of the 2.10 systems have had their plc time go haywire a couple times, it seems that the utc offset is set to some random value, causing the time to be out by multiple hours. See attachmennts. Is this a known  issue with 2.10 or just something random that is happening here? None of the 2.9 OSS have had this issue, I have at least 10 plcs on this same network. I don't want to upgrade the time server plc to 2.10, because all the other 2.9 systems are relying on this plc for their time.

[BobO]

I recently updated a couple plcs to 2.10 os, both using time sync mode as a client, but the time server plc is still 2.9 os. Both of the 2.10 systems have had their plc time go haywire a couple times, it seems that the utc offset is set to some random value, causing the time to be out by multiple hours. See attachmennts. Is this a known  issue with 2.10 or just something random that is happening here? None of the 2.9 OSS have had this issue, I have at least 10 plcs on this same network. I don't want to upgrade the time server plc to 2.10, because all the other 2.9 systems are relying on this plc for their time.

We added DST support...a user request. It should be compatible with all combinations of old and new, but it sounds like something might not be working as intended. We'll look into it.

[PLCwannabe]

Has anybody looked into this issue yet? I'm getting random crazy time changes in BRXs running 2.10 os, even with  the time server function disabled.This issue is causing havoc with scheduled events. In this case I had reset the time, before i thought to take a screenshot, but the event logger pretty much shows what happened.

[BobO]

Sorry, yes it's fixed. There was a bug in the code that was supposed to keep the time zone compatible with the old announcements.

However I don't know of any way for it to fail without a time server. Do you have another PLC set to be the alternate?

[PLCwannabe]

 Not sure how an alternate plc is setup. I assumed if the time server is disabled, that the time will never change.

[BobO]

Not sure how an alternate plc is setup. I assumed if the time server is disabled, that the time will never change.

You can define each PLC to be a server, alternate, client, or disabled. Alternates are clients as long as the server is announcing. When the server fails to announce, the alternate starts announcing.

[PLCwannabe]

But if the time server function is disabled, none of the other settings should apply, right? Which os version has the fix?

[BobO]

But if the time server function is disabled, none of the other settings should apply, right? Which os version has the fix?

If a PLC has it disabled, nothing should apply. If time is getting set in a PLC that has it disabled, that is a problem. It'll be in the next release (2.11) coming out shortly.

[eman5oh]

I'm experiencing an issue with the time server function and wanted to ask whether the bug mentioned in this thread could be the cause, or if it might be unrelated.

We have a master PLC configured as the time server, along with a alternate backup, and approximately 15 client devices. On the clients, the system clock appears correct when viewed through the system information. However, the time and date reported by the $Now function do not match the system clock.

This discrepancy is causing problems with log files on our HMIs, which rely on V memory where we map the time and date. As a result, the timestamps are inaccurate. Is the bug mentioned in this thread the cause or is something else to blame?

-Thanks

[BobO]

Something else going on there. The bug was a 1/256 chance that the time zone would get set incorrectly. It was only present when the server/alt was running version 2.9 or less, and the slave is running 2.10. As long as everyone is on the same version there is no issue.

[eman5oh]

Something else going on there. The bug was a 1/256 chance that the time zone would get set incorrectly. It was only present when the server/alt was running version 2.9 or less, and the slave is running 2.10. As long as everyone is on the same version there is no issue.

Any idea why the system clock would disagree with the $Now. date and time values?

[eman5oh]

After some digging it seems $TimeZone was set to a wacky value on the client. I am not sure how that got changed. Does it not get set with the time sync function?

[eman5oh]

After some digging it seems $TimeZone was set to a wacky value on the client. I am not sure how that got changed. Does it not get set with the time sync function?

A bit more info, I have checked the PLC set at the time server, it has the correct time that is synced via the Net time instruction and is configured as the server. I had set the $Time zone to the proper value on a client but it reverted back a short time later. I suspect we may have a misconfigured unit on the network, what happens when you have two plc's set as server?

Thanks.

[BobO]

A bit more info, I have checked the PLC set at the time server, it has the correct time that is synced via the Net time instruction and is configured as the server. I had set the $Time zone to the proper value on a client but it reverted back a short time later. I suspect we may have a misconfigured unit on the network, what happens when you have two plc's set as server?

Thanks.

They just broadcast the time sync packet, so yes, you would have two different values with two different servers. Doesn't hurt anything, just confusing. Just change the extra server(s) to alternates. Alternates only publish in the absence of a server, and then revert to alternate when the server comes back.

[eman5oh]

We have checked all DoMore PLCs on the network, which include a mix of Terminator and BRX models, and did not find any mis-configured as a time server. All were either set to "Client" or "Disabled." The PLCs that are syncing time have the correct UTC time but are showing the wrong time zone.

We are in Eastern Standard Time, so the $TimeZone value should be -300, but it is being set to 65236. This value seems suspicious-possibly a misinterpreted 16-bit signed integer (e.g., -300 interpreted as an unsigned value), or something else entirely. Regardless, it's an unusual offset.

In addition to the PLCs, we also have bus couplers, Stride remote I/O, HMIs, and I/O extenders on the network. Could any of these devices interfere with time synchronization?

Do you have any guidance on how to scan the network to identify the source of the incorrect time sync packets, perhaps using a tool like nmap or something similar? Any other suggestions for diagnosing this issue would also be appreciated.

-Thanks