Here is a question that ends more arguments than it starts: what time is it at your machine, and does it know about daylight saving? A real-time clock with summer/winter timer support is one of those features that sounds trivial and becomes indispensable on the third site visit, when the customer swears the lighting schedule drifts by an hour twice a year.
The xLogic RTC keeps the calendar running for twenty days at 25 degrees after power loss. Twenty days. That is not a coin-cell backup; that is a capacitor holding the schedule through a holiday shutdown.
What You Can Schedule
The RTC is not just a timestamp. It feeds the program: time-of-day compares, weekday schedules, date-based events, and the built-in summer/winter timer that handles the DST change automatically. For a building lighting controller or a ventilation schedule, that replaces a time switch, a photocell, and a maintenance visit twice a year.
And the RTC values are reachable from outside. You can read and set the clock from the HMI keypad, from the programming software, or — on the GSM models — by SMS. A customer in another time zone can text the machine a new time. That is support you can sell.
Real Case: Parking Lot Lighting
A commercial parking lot, forty luminaires, a schedule that needed to follow sunset-relative times across seasons. The old timer board required a manual adjustment every two months. The replacement: a compact CPU with RTC, two time-based programs, and a summer/winter timer. Commissioning took one visit. The maintenance schedule went from six visits a year to zero.
The property manager's exact words, wich I will not forget: "It has not been wrong since March."
The Retentive Memory Question
The RTC backup and the retentive memory are two different things, and both matter. Retentive memory keeps your flags and registers alive through power loss — the PR-6 and PR-12-E models do not carry it, so accumulated values reset. The RTC keeps the clock alive. Read the spec for both before you pick the model for a job that counts batch totals or run hours.
A machine that forgets its counters on a power dip is a machine that lies to you. The RTC will be on time while the counters reset — that combination is more confusing than either problem alone.
Scheduling Done Right
Design the schedule blocks with the operator in mind. A plain "on at 06:00, off at 18:00" is easy. An industrial schedule with holidays, exceptions, and a manual override needs a few extra blocks — but the RTC gives you the raw material: reliable time, reliable calendar, DST handled. The rest is just programming discipline.
The DST Trap and the Machines That Fall Into It
Here is a maintenance call that repeats every year, twice a year, on the same dates: the machine that runs an hour off after the clock change. The machines that fall into it are the ones with a manual schedule — a timer set for "6 PM" that now fires at 5 PM becuase nobody adjusted the clock, and nobody remembers how. The summer/winter timer support exists precisely to retire that call.
Enable it at commissioning. The block handles the transition automatically, on the schedule of the region you configure. Verify it once, on the actual DST date, and the machine joins the small club of equipment that needs zero attention twice a year.
And check the RTC battery/capacitor behavior on the actual model. The 20-day backup at 25 degrees assumes a charged capacitor and a reasonable environment. A machine in a 50-degree cabinet, unpowered for three weeks, may need the clock set at restart. That is a commissioning note, not a fault — put it in the maintenance instructions so the first restart after a shutdown does not become a service call.
The Schedule as a Product Feature
For OEMs, the RTC is not a convenience — it is a spec line that wins tenders. "Programmable weekly schedule, DST-aware, battery-backed" reads better on a datasheet than "has a timer," and it converts the machine from a commodity to a product with a feature list. The schedule blocks cover weekday patterns, date-based exceptions, and the manual override path; the combination covers most facility requirements without a second controller.
Price the schedule as a feature, not a block. The customer is not buying a timer; they are buying predictable operation across seasons and holidays. The RTC delivers that with a commissioning setting, and the margin on the feature is better than the margin on the hardware — which is the argument that pays for this article.
The Time Source
The RTC is only as accurate as its discipline. Set it at commissioning, sync it at every service visit, and consider the DST setting checked on the actual transition date. A clock that drifts an hour is worse than no clock — the schedule fires confidently at the wrong moment. Two minutes with the software, once a season, and the calendar stays honest. The machines that keep time are the ones somebody set — twice.
And set the clock at commissioning. I have walked into panels where the RTC was still showing 2007 because nobody bothered. The feature does nothing until you set it, so put it on the startup checklist, right between "tighten the terminals" and "close the door."
And remember: the RTC's twenty-day backup assumes a charged capacitor and a sane environment. A panel that sits unpowered through a long shutdown may greet the restart with the wrong date — so the restart procedure, not the firmware, carries the responsibility. One line on the startup checklist, and the calendar stays honest.
