ControlLogix, CompactLogix – Why your Controller’s Real Time Clock (DateTime) may be a few hours off

By

-

July 2, 2013

A client recently called frustrated that the real time clock in his CompactLogix processor was always off by 4 hours. While I had heard this complaint in the past, since I hadn’t run into it myself I needed to do a little research to understand what this client was experiencing.

I found that prior to RSLogix 5000 version 16, using a GSV (“get system variable”) instruction to read the Controller’s WallClockTime object’s “DateTime” attribute was a popular way to get the actual time into Program or Controller tags. I also found that prior to v16 there had been no support for Time Zones (TZ) or Daylight Savings Time (DST.)

Note: You can listen to our companion podcast about why your Logix clock may be off a few hours HERE.

Then in RSLogix 5000 version 16 Rockwell added support for Time Zones (TZ) and Daylight Savings Time (DST,) both of which act as offsets from Coordinated Universal Time (UTC). When creating a new program, or importing an older program, the software defaults these new settings to zero which allows programmers to continue to use the “DateTime” attribute as they always had, without any consideration of the new TZ and DST settings.

However, many programmers began to enable the TZ and DST settings inadvertently when using the “Set Time” button in Controller Properties. In v16 and later this button not only sets the Controller’s clock to match the PC’s date and time, but also sets the Controller’s clock to match the PC’s TZ and DST settings.

Interesting enough, if you enable TZ and DST in my region, the result is a UTC offset of -5 for the Eastern Time Zone, and +1 for Daylight Savings Time, which combined gives you a UTC offset of -4, or exactly how much time my customer’s Controller was off.

The reason for this was that, with the Time Zone (TZ) and Daylight Savings Time (DST) settings in effect, the “DateTime” attribute no longer represented the current time, but instead represented UTC. So if you’re going to use the new TZ and DST settings, the “DateTime” attribute isn’t going to be of much use for representing local time.

Fortunately, when Rockwell introduced support for TZ and DST in v16 they also added a new WallClockTime object class attribute, “LocalDateTime.” This new attribute does take into account the controller’s TZ and DST settings, and provides an accurate representation of local time.

To demonstrate this, I created the program pictured in this article with uses GSV instructions to read both the WallClockTime’s “DateTime” attribute as well as it’s “LocalDateTime” attribute. Running the program with the Controller’s clock set to match my PC’s settings of a -5 Time Zone and DST on (as my client did) shows that the “DateTime” attribute will indeed be -4 hours from the “LocalDateTime.”

Have you run into the above issue? Do you have additional thoughts on this topic? If you do, please share them below using the “post a comment or question” link.

UPDATE: You can hear Shawn’s thoughts on “Why your ControlLogix time may be off a few hours” in Episode 6 of The Automation Podcast HERE.

Until next time, Peace ✌️

If you enjoy this episode please give it a Like, and consider Sharing as this is the best way for us to find new guests to come on the show.

Shawn M Tierney
Technology Enthusiast & Content Creator

Eliminate commercials and gain access to my weekly full length hands-on, news, and Q&A sessions by becoming a member at The Automation Blog or on YouTube. You'll also find all of my affordable PLC, HMI, and SCADA courses at TheAutomationSchool.com.

Providence Beer Demo

Let’s make some virtual beer!

“How do you create reports in RSView32” is a very common question, and it’s one that’s difficult to answer.