Why HMI trend log timestamps jump backward at the hour

What the damaged file looks like

Read the exported file, not the live graph. The signature is specific:

• A pair one hour apart, in reverse order. 07:59:59 followed by 07:00:00 is a backward step of 59 minutes 59 seconds. The hour field updated ahead of the minutes and seconds.
• A pair 59 seconds apart, in reverse order. 17:00:59 followed by 17:00:00 is the same failure with only the seconds field rolling between reads.
• A stray entry off the hour. 16:59:16 in a file that otherwise lands on exact hours.
• A midnight entry stamped 23:59:59 of the previous day. The date change is one more field transition the read can straddle.
• Clean entries everywhere else. On exact hours, values that track the PLC word sample for sample. The data path is healthy; only the timestamps are damaged.

Why the hour boundary breaks the read

A clock is not one number. It is separate fields, and the panel reads them one after another. When the hour changes between two reads, the panel assembles a time that never existed, and the interval logic reacts to it. Here is the sequence that reproduces the pair above, at the real transition from 06:59:59 to 07:00:00:

1. The hour register has already rolled to 07 while the minute and second registers still read 59:59. The panel assembles 07:59:59, a full hour ahead of the wall.
2. The 60-minute check subtracts the last entry, 06:00:00: 07:59:59 minus 06:00:00 is 1 hour 59 minutes 59 seconds, so the panel logs an entry stamped 07:59:59.
3. On the next read the fields agree: 07:00:00. That stamp sits 59 minutes 59 seconds before the one just written, but it is still a full 60 minutes after 06:00:00, so the interval fires again and writes 07:00:00.
4. The file now runs 07:59:59 into 07:00:00, both carrying the same logged value, because both were captured inside the same minute of process time.

No manufacturer publishes the read order inside a given panel, so treat this as the reconstruction the pattern supports: a panel clock following a PLC clock, an internal hourly interval, and doubled entries hugging every boundary. The symptom class itself is documented. The time synchronization documentation of at least one HMI platform warns that a panel unable to use the correct time can carry a timestamp from the past.

Checks before you touch the logic

• Count the entries against the hours. A day that should hold 24 hourly entries, with five doubled boundaries, holds 29.
• Compare each doubled pair's values with the PLC word. Both entries of a pair carry the same value when both fired inside the same process minute; the genuine hourly sample sits in its own entry beside them.
• Write down the pairing: trend triggered by the panel's own 60-minute interval while the panel clock follows the PLC. That pairing is the fault. Fix the trigger; keep the clock where it is.
• Bound the PLC clock's drift before an audit depends on it; bounding PLC clock drift before you trust its timestamps is a separate check with its own numbers.
• Never repair the file by setting the panel clock backward. At least one HMI vendor documents that a backward time setting requires a cold restart, so the shortcut can end in a production reboot.
• Check what synchronization actually does. An unchecked schedule box does not prove synchronization is off; tags can be set to synchronize on a change of value regardless of the schedule.

The fix: a PLC pulse 30 seconds past the hour

1. Leave the clock alone. The PLC stays the time source, so operators keep setting time and daylight saving where they do today.
2. First look for a native offset. Some trend log objects document an interval offset, specified in hundredths of a second, from the start of each logging period to the actual sample. Where that setting exists, an offset of 3,000 is the same 30 seconds, and you are done.
3. In the PLC, assert a discrete trigger bit when its own clock reads minute 0 and second 30, and clear it at second 45. Pulse width: 45 minus 30 is 15 seconds.
4. Point the trend's trigger at that discrete tag and turn the panel's internal 60-minute interval off. Two live triggers will double the file again.
5. Confirm one pulse per hour and that the bit returns low. The pulse only has to outlast the interval at which the panel polls the tag; at an illustrative 1-second tag refresh, the 15-second pulse spans 15 refreshes.
6. Run it across several hour boundaries, then read the exported file.

The offset is the whole fix. At :00:30 the clock fields have been settled for 30 seconds, so there is no mixed time to assemble. Expect one entry per hour stamped between :00:29 and :00:31. The second of spread comes from where the panel's tag poll lands inside the 15-second window; the clock is not drifting.

Scenario: an audit log that has to hold up

A snack plant logs one dryer temperature word every 60 minutes for a customer audit. The panel clock follows the PLC and the trend uses the panel's 60-minute interval. The exported file for one day holds 29 entries where one per hour gives 24. The boundaries into 07:00, 17:00, 18:00, 19:00 and 23:00 each doubled once, adding five entries. The 07:00 pair steps back 59 minutes 59 seconds, from 07:59:59 to 07:00:00; the other four pairs step back 59 seconds, from :00:59 to :00:00. Every doubled pair carries the same value, and the auditor's checker wants stamps that advance entry by entry.

The maintenance tech applies the pulse: assert at minute 0, second 30; clear at second 45. Width 15 seconds, offset 30 seconds past the boundary, internal interval off.

The next day's file holds 24 entries, every stamp between :00:29 and :00:31, each value matching the PLC word. The stamps advance monotonically, which is what the checker tests first. The old day stays in the record with the five extra entries marked as trigger artifacts and the pair timestamps listed.

The decision for each setup

Recommendation: when the panel's clock follows the PLC and the trend runs on an internal 60-minute interval, replace the interval with a PLC discrete pulse asserted at second 30 and cleared at second 45 of every hour, and keep the PLC as the time source.

• Native offset available. Use the documented interval offset in the trend log settings instead of building PLC logic; the 3,000-hundredths figure above applies unchanged.
• Operators must stay out of the panel's system menu. The pulse leaves clock ownership with the PLC, so time changes and daylight saving stay where they are handled today.
• The audit must survive a panel power cycle. Copy the log off the panel on a schedule; archiving HMI trend data externally covers the transfer and its limits.
• Doubles survive the trigger change. The panel is receiving time from somewhere else as well. Trace the trigger bit against the stamps for a few hours and review the synchronization cadence. If the verification window crosses midnight, the export itself rolls over at the date change; how HMI USB trend log files roll over at midnight covers that side.

Questions