Day Light Savings Time (DST) for Compact Logix 5069-L319ER version 33

[Chris Elston 79]

Did anyone else have any problems with your Compact Logix not switching Day Light Savings this past weekend?

Just curious... The HMIs switched over no problems. I might need to map in the HMI clock maybe.

 

[Joe E. 259]

Interesting...I'm not sure if I have that problem or not, but my test bench 1769-L33ER (v34.11) is 2.5 hours fast right now. It's been a while since I checked the CPU time, so it may have been drifting for a very long time.

[Ken Roach 194]

I think that the DST check box affects only the UTC offset in the time that you are poking into the controller with the [Change Date and Time] button.    It does not enable automatic Spring-forward/ Fall-Back changes of the controller's WallClockTIme at the appropriate US dates and times.

Or, checking or unchecking the checkbox it is like changing the hour in the Date and Time field and clicking that same button; it makes the change in the controller only if you're online.

As far as I know, none of the A-B controller families that have clocks will automatically advance or reverse for Daylight Saving.   You would have to change the WallClockTime object by 60,000,000 microseconds in your program at the appropriate early Sunday morning.

Today I've been working with a bunch of different timestamps from machines in France and Washington, and frankly I'm so tired of wondering what the offsets are supposed to be that I'm ready to use Zulu time for everything.
 

[Chris Elston 79]

@Ken Roach wow...I have been shambled for a few years. Ever since they added DST to the firmware. Ha! This was just the first time I noticed that the clock did not change. I did not know that setting DST in the PLC did not update it automatically. Good to know! The Panel View HMI of course updated assuming because it's Windows CE now. Maybe I'll map over the clock from the HMI into the PLC might be easiest so they are in sync with each other this way. But thanks for the response. I learned something today as well.

[pturmel 160]

4 hours ago, Ken Roach said:

You would have to change the WallClockTime object by 60,000,000 microseconds in your program at the appropriate early Sunday morning.

No, don't ever do this.  Logix underlying clock (and all clock sync operations) run on Zulu time.  The checkbox in the controller properties just tweaks the local time offset.  Since not all timezones obey DST, with many crazy rules, the controller simply doesn't handle it.  Use an SSV to set/clear that checkbox programmatically if you need it.  The WallClock currentValue is always zulu, and should always be used for timestamping.

[Ken Roach 194]

Quote

>The WallClock currentValue is always Zulu, and should always be used for timestamping.

Yup.   Stick with Universal Coordinated Time (aka Zulu Time or Greenwich Mean Time) for the controller clock and any timestamps you record.   Apply local offsets for reports or time displays.

It's worth reviewing that the WallClockTime's 64 bit CurrentValue is UCT/Zulu.   The WallClock Time 7-DINT object is also in UCT/Zulu... it's the LocalWallClockTime that's in local time format.

I'm not totally sure what the CST object gives... is that always the time since boot ?

I have recently been working on a project where I'm using both the PanelView 5000's built-in FTA&E alarm history log and a Raspberry Pi running Node-Red and a pylogix script.   At first I was very annoyed to learn that the PanelView 5000 expresses all of the exported timestamps in UCT/Zulu, but then realized that means they're going to align with the Wall Clock Time CurrentValue timestamps I am capturing and uploading in bulk.   

Correlating the actual time that one of the events I'm analyzing occurred is straghtforward.   I only have to convert the first and last timestamps into Local Time for my report.

Meanwhile, across the factory, is a system that has ten Stratix 5700's doing NAT, and I'm trying hard to make the switch be the time master for the controllers (which also have 8x Kinetix each) and have the switches in turn get their time from a Windows 2012 Server instance that has NTP Server enabled.   So far no dice; the switches apparently get their device time properly, but the 1756-EN3T and the 1756-L72S are trucking along pretending it's 1969.

Edited 25 March by Ken Roach

[pturmel 160]

12 hours ago, Ken Roach said:

always the time since boot ?

CST is Rockwell's precision time from before PTP.  When synchronizing, it is the master clock's time since boot (ish).

12 hours ago, Ken Roach said:

Windows 2012 Server instance that has NTP Server enabled

Rockwell has wisely chosen PTP (IEEE 1588) for its time synchronization.  Much more precise, and auto-configurable in LAN environments.  Put a Time Machines TM2000B on your network, set it to PTP Multicast, and turn on time synchronization in all of the Rockwell products.  (Make sure the ControlLogix processors have time sync connections to their chassis ethernet cards instead of default connections.)

Every controller will quickly be within single digit microseconds of the atomic clock that drives the GPS cloud.  The TM2000B also is an NTP server, so your less modern IT devices can synchronize, too.

(I have no connection to Time Machines, other than as a very happy customer.)