Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: PLCwannabe on November 24, 2024, 11:14:46 PM
-
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.
-
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.
-
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.
-
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?
-
Not sure how an alternate plc is setup. I assumed if the time server is disabled, that the time will never change.
-
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.
-
But if the time server function is disabled, none of the other settings should apply, right? Which os version has the fix?
-
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.
-
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
-
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.
-
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?
-
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?
-
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.
-
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.
-
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
-
You are sticking the value into a V, which is unsigned...65236 is the WORD unsigned rendering of -300. Displaying as Vn:S will show the right value.
The time sync packet is a UDP broadcast frame going to our standard programming port 28784 (0x7070). The last three bytes of the time zone capable packet are (for -300) 0xB2 0xD4 0xFE. If you have a bunch of devices though, there might be a lot of traffic on that port.
-
Something I haven't seen mentioned:
Is there any indirect addressing in the PLC? If so, have you properly bounded it so that it can't get outside the proper area?
-
I do not have any indirect memory access or manipulation, at least that is intentional. I just ran a test by setting the time zone on the PLC designated as the server to -360 and the clients now updated to 65176. I am viewing the time zone information in data view window showing the value of $TimeZone with the data set to native. This is not the V memory that I have set as the destination for the time information. Any ideas of why this would be happening?
-
The client $Timezone says that?
-
Yes the client $TimeZone shows 65176 and the server shows -360 when viewed in data window set to native.
-
Mine doesn't do that, but I'm thinking that had already been fixed a while back. I'll check the code when I get back in the office.
-
Updating the OS from 2.10.1 -> 2.10.2 fixed the issue.
-
Updating the OS from 2.10.1 -> 2.10.2 fixed the issue.
Yeah, it was a sign extension problem and did get fixed for 2.10.2.