Logix Clock Synch Tool

James42005

Member
Join Date
Dec 2018
Location
Waterloo, IA
Posts
35
Its that silly time of year again I am tasked with making sure all important PLC clocks get updated for Daylight Savings Time. For the most part its no big deal with the Clock Update Tool, However...

We have 10 machines (2 PLC's each) that are 17690L33ERM v24.11 and .13 respectively. For along time we have been updating these manually because they are coordinated motion machines. This isnt a big deal just time consuming and annoying. So, i thought why not just add these controllers to the tool, do not put them on a schedule. Just manually since it when the lines are down or whatever... Well, when I point the update tool to these particular controllers the OK button is greyed out. Wont let me add it. I thought this was maybe because of the motion control, but i have other controllers running same firmware with motion and have no problems. What gives.



In the meantime i wrote some logic to handle this for me. We already had messages and some produced/consumed tags setup from our "Master" controller and between the 2 PLCs on each machine. It works by getting the DST adjustment value from the master(which is time synched from the Clock Tool). Based on that value (= to, or not = to 60) I write data to the controllers to apply or not apply DST adjustment. Obviously its conditional in each controller that the e-stop is pushed in order run the SSV. Doesnt synch time just apply DST adjust. Luckily these controllers stay quite accurate otherwise.

Hopefully this is slightly clearer than mud.

So Question 1: Anyone know why some controllers cant be time synched from the tool?

Question 2: What actually happens if you change the PLC clock time during motion?!?!
 
As someone bit by daylight savings in the past, the answer is always:
Controller should always use UTC.
Convert to and from a local time only when you want to interact with an operator (who can't subtract 8 hrs from a date in their head)
 
I am not 100% but I recently struggled messaging to the same Compact Logix. The communication path is different for certain Compact logix processors. This may be the issue?
 
James42005 said:
...Question 1: Anyone know why some controllers cant be time synched from the tool?...

Logix 5000 Clock Update Tool Version 2.4.2 added support for the CompactLogix 5370 L1 and L3 controllers. However, there was an anomaly where the tool would write GMT +00:00 to the controller's wall clock, knocking it out of sync.

Version 2.5.2 corrected this anomaly, but in typical Rockwell fashion, introduced another. The hardware XML file, installed with this version of the tool, does not have, among others, the 1769-L33ERM controller included. They provided us (via the Knowledgebase) an updated XML file to swap in to add the necessary controller support.

So, you are likely either using an earlier version of the tool where the CompactLogix 5370 L3 controllers are not yet supported, or a later version where the XML file is incomplete for its expected list of supported devices.

Version 3.0.0 (v3.00.00) of the tool corrected this XML anomaly though, and also added support for the Compact GuardLogix 5370, CompactLogix 5380 and ControlLogix 5580 controllers.

See the following technotes for reference (new Support layout is "fun", thanks Rockwell)...

ID: IN5505 | Access Levels: Everyone
What’s new for the Logix5000 Clock Update Tool

ID: QA24325 | Access Levels: TechConnect
Configure Clock Update Tool version 2.5.2 for a 1769-L33ERM Controller

If you would like to upgrade the tool then see here...

ID: IN6753 | Access Levels: Everyone
Download Studio 5000 Tools

James42005 said:
...Question 2: What actually happens if you change the PLC clock time during motion?

If your motion application is utilizing CIP Sync (CompactLogix 5370 L3xyzM support CIP Sync) and the controller is set as the Grandmaster Clock (typical in single controller applications) or is updated from another Grandmaster source (typical in a multi-controller application), then an "untimely" update from the Logix5000 Clock Update Tool could interrupt and compromise the accuracy of the time critical synchronisation.

A CIP Sync device, or network of devices, requiring real-time, deterministic data or motion commands, should first achieve a steady and acceptable Latency (average round-trip time). Once this is achieved, a Clock Jitter Tolerance may be applied to monitor the amount of time in which this Latency is exceeded. If a CIP Sync device exceeds its Clock Jitter Tolerance, then it will produce a Clock Jitter Alarm or a Clock Sync Fault, or similar. A typical device default Jitter Tolerance may be say 10 milliseconds, but 100 milliseconds is often a better value to set, depending upon network performance.

When the "non CIP Sync" Clock Update Tool is used to send an update to a CIP Sync enabled device(s), it will send 3 consecutive packets at a time. These packets may interfere with the expected timing of the CIP Sync Precision Time Protocol (PTP) packets, increasing jitter beyond a device's tolerance.

Also note, even if the tool successfully updates a CIP Sync application without causing faults, CIP Sync (CIP + IEEE 1588 Standard) updates time to within 100 nanoseconds accuracy, whereas the Clock Update Tool (and Clock Sync Service Tool) may at best update time to within 200 milliseconds accuracy. This much of a discrepancy, applied to a live motion application by one of these tools, could be critical in timing between axis movements, causing dangerous and/or destructive movement.

While it is best advised to avoid using these "non CIP Sync" tools altogether for time synchronisation in CIP Motion applications; doing so manually, while all motion is safely prohibited (as you are doing to adjust DST) may be inconsequential, but should be assessed on a case by case basis.

James42005 said:
...Doesnt synch time just apply DST adjust...

If by "synch" you mean CIP Sync...

CIP Sync uses the controller System Time. System Time is derived from the PTP timestamp in nanoseconds since the PTP Epoch (beginning) minus the current UTC offset value (fixed Leap seconds). It does not use Daylight Savings Time or Local Time Zones.

Daylight Savings Time and Time Zone offsets are applied to the System Time for display purposes, but are not synchronized across devices using the CIP Sync protocol. Therefore, DST adjustments do not affect CIP Sync.

If by "synch" you mean the Clock Update Tool...

The Clock Update Tool first checks if the "Automatically adjust clock for Daylight Saving Time" option is enabled or disabled in the tool.

If it is enabled in the tool, the Clock Update Tool sets the DST bit in the controller, if the computer time has DST enabled.

If it is disabled in the tool, the Clock Update Tool resets the DST bit in the controller, if the computer time has DST disabled.

Note: The Clock Sync Service Tool does not adjust for DST or Local Time Zones.

James42005 said:
...In the meantime i wrote some logic to handle this for me...

For automatic DST adjustments, best practice is to programmatically read (GSV) and monitoring the controller WALLCLOCK object/attributes and then write (SSV) a "DSTAdjustment" value and then write (SSV) to "ApplyDST", as you appear to be doing.

Rockwell say that because DST is not globally used, either Country-wise or Regionally, or not used the same in each of the aforementioned; their CIP Sync devices, intended for global marketplaces, do not support automatic DST adjustments. Still, I do not see how it would hurt to provide a built-in means to user configure automatic DST adjustments for devices?

It's kind of like a car manufacturer coming out and saying we don't provide steering wheels because we don't know which side of the road the vehicle will be driven on.

Regards,
George
 
Last edited:
As someone bit by daylight savings in the past, the answer is always:
Controller should always use UTC.
Convert to and from a local time only when you want to interact with an operator (who can't subtract 8 hrs from a date in their head)
+1

I have a hard time to convince everyone in our little corner of the universe to do this.
 

Similar Topics

Good afternoon all, hope everyone is doing well. I have a Compact Logix PLC that has an RTC module installed on it. About every year, it loses the...
Replies
9
Views
2,857
Does anyone know the history of the A-B 10kHz free-running clock? It seems to only exist in the MicroLogix 1xxx line: S:4 is the 16-bit clock...
Replies
3
Views
1,749
Hi all I thought I had this working but upon doing a checkup a few months after the machine was commissioned, I found that adjusting the RTC via...
Replies
4
Views
1,823
Good morning all, I am using RS Logix 20.04 to connect to my compact logix ___ that has a RTC (real time clock) on it. I can set the time and...
Replies
6
Views
2,801
Hello there, I'm working on adding a historian, of sorts, to a PLC project where I'd like the data that is being stored to be reset on a certain...
Replies
15
Views
4,116
Back
Top Bottom