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.
Enjoy the benefits of membership! Insider news, rewards, & more: Patreon.com/automation
If you enjoyed my article, you may like my courses at TheAutomationSchool.com
Have a question on this topic? Click here to scroll down to the comment link
Have a news tip? Share it with us here
Latest posts by Shawn Tierney (see all)
Click HERE to scroll down to view or leave comments
I'm creating a GSV WallClockTime in 1769-L33ER CompactLogix 5370 Controller running Studio 5000 24v to track downtime on the production line, do I need to create this offline and then download?
I created it online however it doesn't seem to be working.
Please enlighten me
David LiebalGood afternoon Dave,
Hope all is well.
I'm out of town at the moment so I can't test it here, but I didn't think you needed to be offline to add a GSV instruction?
It's all good... I found the issue
Hope all is well!
Shawn Tierney, The Automation Blog