NETTIME Help

[RBPLC]

My IT department gave me an IP address for an internal time server. I used the NETTIME command to synchronize time to a BRX PLC. The NETTIME indicates success but currently (as of today) returns a date of year:2019, day: 29, month:06. Obviously this isn't correct but I don't know enough to know if this is something I've messed up on the BRX side or if it's something on the time server side. I wasn't given a specific UDP port so I just used the default 123. Can anyone point me in a direction to troubleshoot or potential configuration issues on the BRX that I might be missing? Is the BRX potentially looking for a specific format of data and it's just being misinterpreted because I haven't specified it correctly?

Edit: Looking back through email, it looks like the internal time server that I was given might be NTP instead of SNTP. If this is the case (I'm confirming now), could this potentially be the issue with the incorrect date/time?

[RBPLC]

Talked with IT personnel this morning and it turns out that the server was broadcasting the wrong time. They've corrected the time on the server and now the NETTIME command is functioning and is syncing correctly with the NTP server. This however poses another question. Is there some way of using NETTIME to request information from a time server and then compare it to the time prior to running the NETTIME command and build in logic to compare the two and reject the NETTIME command should two times vary by more than X amount of time?

[BobO]

Talked with IT personnel this morning and it turns out that the server was broadcasting the wrong time. They've corrected the time on the server and now the NETTIME command is functioning and is syncing correctly with the NTP server. This however poses another question. Is there some way of using NETTIME to request information from a time server and then compare it to the time prior to running the NETTIME command and build in logic to compare the two and reject the NETTIME command should two times vary by more than X amount of time?

That sounds easy enough. Use a program block with stages. Store the current system time ($Now). Do the NETTIME. Compare new $Now to original value (DTDIFF). Use SETTIME to put the old value back if the compare fails.

[RBPLC]

Thanks BobO for the response. I guess the thing I was wondering is when the NETTIME updates the current system time. What you described implies NETTIME sets the time and you reset it based on the predefined time differential condition. I was wondering if there was a way to do the comparison prior to setting the system time in order to stop it from ever being updated. For my application I don't think it will matter if I set/reset the system time but there might be an instance when it would matter? I could be thinking about the scan/comparison cycle incorrectly.   

[BobO]

Thanks BobO for the response. I guess the thing I was wondering is when the NETTIME updates the current system time. What you described implies NETTIME sets the time and you reset it based on the predefined time differential condition. I was wondering if there was a way to do the comparison prior to setting the system time in order to stop it from ever being updated. For my application I don't think it will matter if I set/reset the system time but there might be an instance when it would matter? I could be thinking about the scan/comparison cycle incorrectly.

There is no way to do what you're wanting.

[franji1]

Talked with IT personnel this morning and it turns out that the server was broadcasting the wrong time. They've corrected the time on the server and now the NETTIME command is functioning and is syncing correctly with the NTP server. This however poses another question. Is there some way of using NETTIME to request information from a time server and then compare it to the time prior to running the NETTIME command and build in logic to compare the two and reject the NETTIME command should two times vary by more than X amount of time?

You are assuming that the PLC is "correct" and the Server is "in error".  This is almost NEVER the case (time servers are supposed to be reliable).  You are better off doing THAT on the Time Server to a "more official" Internet based Time Server (your IT guy should know how to do that).  That's how it's supposed to work anyway:

1. Official Internet Time Server
2. Local Time Server
3. Local Clients who do not have access to the Internet

If 2 is connected to 1, 3 should always be good.  If you are assuming the only problem is when 3 is good and 2 is bad, you are addressing the wrong problem.  You have issues between 1 and 2, not between 2 and 3.

But even my earlier statement is wrong in that if 1 and 2 have completely different times, it's because 2 is wrong, not because 2 is right and 1 is wrong.

Regardless, how did 2 "get wrong".  Is it not tiered like above?  If all 2 is in your installation is an isolated PC with a floating system clock (just like our PLCs), without access to an OFFICIAL NTP server, it's just a matter of time before 2 and 3 are both messed up (pun intended).  PC clocks float just like PLC clocks do.  That's why Time Servers exist.

[RBPLC]

Without getting into details, I don't have access to 1 so if I want any form of standardized time I can only rely on 2. IT guys also don't have access to 1. This approach assumes that this local time server is always correct (which obviously was not the case). IT said this was the first recorded issue they've ever seen of this happening. The best approach, as you said, would be (in my case) to ensure that 2 is always correct. IT is looking to see what they can do on their end, as this is the correct place to solve the problem. I recommended potentially blocking the UDP port which would prevent the erroneous time sync. In looking for a solution, I was just trying to think of redundancy on my end to deal with the potential issue in the event IT does not provide a solution on their end.
For reference, the source is GPS synced and does not rely on an internal PC clock.

If I start with a known good time and synced a couple times a day the RTC would be accurate enough to hold time for the comparator. My applications aren't timing critical and the RTC would prevent a drastic time difference from being accepted. Potentially the only issue might be DST.