Fix an HMI clock that rolls back months

Why does an HMI clock roll back by months?

When a panel's date jumps back about two months during a running shift, and a power cycle only restores it until the next jump, the documented field pattern puts the fault in the panel's own clock handling. The firmware update is your first corrective action.

The documented cases come from one plant running six panels: two 12-inch screens talking to the PLC network over Ethernet and serial, and four 7-inch screens on serial to local PLCs. Every screen displayed the panel's internal clock/calendar, not a PLC value. The master 12-inch jumped about two months during a production shift with no outage; the remote 12-inch, on a different program, jumped the same day. All four 7-inch panels jumped within a 20-minute window, about two months after their last software and firmware updates. The panel maker replied that it had never duplicated the fault, but had corrected clock-synchronization issues in the then-current release. The plant updated every panel, and the next report, 114 days later, was clean.

That is a field result, not proof of the root cause. A matching symptom on a different device running a different embedded operating system is a coincidence to note, not a cause to chase.

What does each rollback pattern point to?

Each pattern points somewhere different: a mid-shift jump on one panel points at the panel's own clock handling, several panels jumping inside one 20-minute window points at a shared or ordered event, and time lost after 1 to 2 weeks powered off points at a retention reset.

• One panel jumps mid-shift and the power log shows no outage. The panel was powered the whole time in the documented case. This points at the panel's clock handling. Check the firmware level, the project load date and the clock source.
• Several panels jump inside one 20-minute window. Four screens on different programs and separate serial links changed within 20 minutes of each other. Four independent clock failures inside 20 minutes is not a pattern to wait out, and the maker observed panels changing in the order they had been updated, so record the update order with each event.
• Time comes back after a power cycle or a project restore, then jumps again. One panel repeated this every couple of months, each time showing the date its program was installed. The recovery is temporary; the corrective action is the firmware update, and the repeat is your evidence the fault recurred.
• The displayed date equals the project load date. Panels reverting to their install date appear repeatedly in the documented reports. Log the load date with every event; a date landing on it means the panel restored a stored timestamp.
• The clock is wrong at first power-up after a long shutdown, once. That is a retention reset, and the figures in the next section say how long off it takes.

Is it the retention reset or the recurring fault?

If the date was wrong right after the panel sat powered off for 1 to 2 weeks, you are dealing with a retention reset; one maker documents time loss after 6 weeks off, and the fix is to reset the clock and move on.

Two documented figures set the boundary. One maker's time-synchronization documentation states that system time may be lost when a device stays off for more than 6 weeks. A report of time and date disrupted after 1 to 2 weeks powered off sits inside that window. A wrong date at first power-up after a shutdown means: reset the clock from the panel's settings menu or its sync source, verify it holds through the shift, close the ticket.

The recurring fault looks different. The jump happens with the panel powered, mid-shift, sometimes on several panels minutes apart, and it returns after a power-cycle recovery that had put the right time back. Treat the power cycle as a way to finish the shift: record the wrong date and time first, then book the firmware update.

Which checks do you record before updating anything?

Before you touch firmware, record five values for every affected panel: the model and screen size, the firmware level, the project load date, the displayed date and time, and whether the displayed clock comes from the panel's internal clock/calendar or from a PLC value.

Keep one record per panel. The four small panels in the documented plant failed as a group, and the maker observed rollbacks following update order within small groups, so per-panel rows are what make that sequence visible.

Confirm the clock source in the project before you touch anything else. When the project displays the panel's internal clock/calendar, the displayed date comes from the panel, and the Ethernet and serial traffic to the PLCs is not where that value originates. The same screen can draw its date from either place; One HMI reads the PLC clock and one writes it: two setups shows the two configurations. Hold off on changing the clock source as a diagnostic shortcut: it hides whether the firmware action worked.

Then check the maker's release information for the exact panel model for clock, calendar or time-synchronization corrections in the current release. The documented plant moved its affected line from release 1.30 to 1.31, where the maker listed clock-synchronization corrections. Save a project copy and note the panel's existing settings before you start, so a failed update never leaves the panel without its application.

How do you run a firmware update on an HMI?

Pull the firmware package the panel maker publishes for the exact model, save a project copy first, and run the documented update sequence without interrupting power or communications; the target is the current release, which in the documented case carried clock-synchronization corrections.

1. Confirm the panel model and its current firmware level. Get the firmware only from the panel maker or its authorized distributor, matched to that exact model.
2. Read the release notes for clock, calendar or time-synchronization corrections. The documented plant moved from release 1.30 to 1.31. More recently, a field report of an HMI time-synchronization problem that stopped after a firmware update ends the same way.
3. Save the project and record the panel's existing settings.
4. Run the documented update procedure, and do not interrupt power or communications during the transfer unless the procedure itself says to.
5. After the update, confirm the panel starts, the intended project is loaded, and the date and time are correct. Record the new firmware level and the update date.
6. Where several panels are affected, update and record each one separately. The documented plant did all six across one visit on 15 August.

Worked example: what do you do when four panels roll back in 20 minutes?

Six panels, two 12-inch and four 7-inch: on 5 May the 12-inch master shows 2 March, a 64-day rollback equal to the 64 days since its project load, and the four 7-inch panels follow inside 20 minutes, so you update all six and hold a 90-day log.

Set the scene: two 12-inch panels on Ethernet and serial, four 7-inch panels on serial, all displaying the internal clock/calendar. The master 12-inch was programmed on 2 March. On 5 May an operator reports the master shows 2 March.

Rollback amount: 2 March to 5 May is 31 days to 2 April, plus 30 days to 2 May, plus 3 days, so 31 + 30 + 3 = 64 days back.

Elapsed since the project load: 5 May minus 2 March is the same 64 days. The displayed date equals the load date, the pattern documented on panels that revert to their install date. The amount is not fixed: an earlier jump on the same line went back 50 days, from 13 July to 24 May, so log the amount at every event.

Then all four 7-inch panels roll back inside a 20-minute window, about two months after their own updates. Four separate clock failures inside 20 minutes, on different programs and separate serial links, is not a pattern to ride out; the maker had watched panels change in update order, so the response is one recorded firmware update per panel, in a recorded sequence.

Result: all six panels updated on 15 August; the next check on 7 December was clean, and 15 August to 7 December is 16 + 30 + 31 + 30 + 7 = 114 days with no recurrence. Set the pass mark at 90 days.

How do you verify the firmware fix held?

The firmware fix is verified on the calendar: one correct reading right after the update, then a per-panel log kept for 90 days, because the documented rollbacks recurred about two months apart and your log has to outlast that interval.

Log one row per panel at every check: the reading date and time, the panel's displayed date and time, the firmware level, the project load date, the clock source, and any power, update or download event since the last row. Read each panel during weekly rounds or at each maintenance visit. Do not collapse the line into one entry; the documented fault moved through panels in update order, and only per-panel rows show that.

The documented pass mark: updated 15 August, called fixed at 114 days clean. Hold your line to 90 days before you close the ticket. If a jump reappears, record the amount, the panel and its place in the update order. That record is what a maker needs to act on, because the fault was rare enough that the maker never duplicated it in house.

If the line also runs standalone notice boards beside the machines, put them in the same log; that is the ground shop-floor screens and andon-style boards covers, and an offline board showing the wrong date misleads the same operators.

When should you move the displayed clock to the PLC?

If a rollback appears again after the update, stop displaying the panel's internal clock/calendar: drive the displayed time from the PLC and hold the PLC clocks to one master, which takes the panel clock out of the path and keeps the panels agreeing with each other.

Make the swap deliberately, after the firmware attempt; changing the clock source mid-diagnosis hides whether the update fixed the panel.

Two builds cover it. Set an HMI clock from the PLC and read trend axes in time shows the panel taking its displayed time from the controller, which also puts trend axes on real timestamps. Synchronize multiple PLC clocks from one master keeps the controllers themselves from drifting apart, so every screen on the line shows the same time.

With PLC time driving the display, a panel clock rollback stops being a line event: one screen shows a stale local clock until it is serviced, and the production record keeps its timestamps.

Recommendation: treat the firmware update as the first corrective action whenever an HMI's internal clock/calendar rolls back by about two months and a power cycle only restores the time temporarily. Record the five values per panel, save the project, update every affected panel to the maker's current approved release, and hold a 90-day per-panel clock log before calling the fault fixed. If a jump reappears inside those 90 days, move the displayed clock to PLC time and hold the PLC clocks to one master.

Questions