Keep a daily data snapshot on an HMI screen

Why does the timestamp keep updating on the screen?

Because the message is tied to a live tag: while the visibility bit stays on, the panel keeps reading the clock tag, so the displayed time advances with the controller clock instead of freezing at your 10:00 capture.

Visibility answers one question, whether the object appears. It never latches the value behind it. Turn the bit off and back on, and the object returns showing the current tag value, at the moment you re-enabled it, stored nowhere. A lookup text object works the same way: it translates the register it is reading now, so a lookup driven by a live clock register updates as the register moves. Bitmaps behave the same when several share one screen, which showing several bitmaps with visibility tags covers. None of these objects store data. The storage belongs one layer down, in the controller, and the panel reads the result.

Where should the snapshot data live?

In holding registers in the controller, set aside for the snapshot alone: one write per day from the capture rung, and the panel reads them like any other tag.

The panel is a viewer, so give it stored data. Two rules keep the record honest. First, snapshot registers are separate from the live registers the process writes; if a counter register changes every scan, copy it at 10:00 into a different register. Second, copy the values and the timestamp as one operation, so the screen can never mix a temperature from one capture with a time from the next. Keep the timestamp in its own registers beside the value registers, and label the fields on the page.

What do you need before building it?

Four things: a controller with a running real-time clock, a panel that reads controller tags, at least 10 spare registers for the copy, and one spare bit for the daily flag.

• The clock, set and checked. A clock running 20 min fast moves every capture 20 min early; correct it before you commission the schedule.
• The clock values reachable from logic. Most controllers expose them as status or data-table addresses; when the driver lists no clock tags, reading PLC clock values without listed RTC tags shows where the fields usually live.
• Spare registers: six for the timestamp, one per integer value, two per floating-point value. The example below takes 10 registers in all.
• A screen page with numeric objects for the values and the timestamp fields.
• Retentive storage, or a log-file route, when the record must survive a power cycle.

How do you copy the clock and the values once at 10:00?

Compare the controller clock with 10:00, run the copy through a one-shot instruction so it executes for one scan, and hold it off with a daily flag that clears when the date changes.

1. Write down the six clock addresses, year, month, day, hour, minute, second, exactly as the controller documentation prints them. A guessed layout swaps month and day silently.
2. Choose the snapshot registers and the flag bit, and keep them out of every other rung.
3. Build the compare rung: true when the hour field equals 10 and the minute field equals 0. The condition stays true for a whole minute, 60,000 ms, which at a 10 ms scan time is 60,000 ms ÷ 10 ms per scan = 6,000 scans.
4. Put a one-shot instruction in that rung. A one-shot (ONS in many instruction sets) passes the rung for one scan per false-to-true transition, so the copy executes exactly once.
5. Set the daily flag after the copy, and gate the compare with a normally closed contact of that flag, so the rest of the window cannot retrigger.
6. Copy the values and the clock fields together, in the same group of rungs, as one capture.
7. Clear the flag when the day field no longer equals the stored day. Tomorrow's 10:00 can capture again.
8. Point the screen objects at the snapshot registers. Keep any live clock on another part of the page and label it; showing a digital clock from PLC RTC values covers that object.

What happens if the controller stops before 10:00?

The capture is missed: a minute match only fires if the controller is scanning inside that minute, so add a catch-up rung that runs once when the clock has passed 10:00 and the daily flag is still clear.

The catch-up rung drives the same copy behind a different condition: time of day past 10:00:00, flag clear. The one-shot and the flag give exactly one copy, at 10:00 or at 10:47 after a restart. The timestamp then reads 10:47 with seconds, and that is the honest record: it states when the values were taken. Stamping a late copy 10:00:00 would misdate the data. If the process is down the whole day, the flag stays clear and the catch-up fires on the restart scan: one copy, timestamped at restart.

Does the snapshot survive a power loss?

Only when the storage behind the snapshot registers is retentive: check how your controller treats those addresses across a power cycle, because working memory can come back zeroed after a restart.

Two paths make the record durable. Configure the snapshot registers as retained, battery-backed or configured-retentive, whichever the controller supports. Or write the record to a file on removable memory, which storing PLC data on the panel for later retrieval covers; on the logging side, triggered snapshot logging configuration walks the same idea with a file destination. Then test it: cycle controller power with the machine in a safe state and read the screen. Retained registers show yesterday's record; zeroed registers tell you the storage choice was wrong. Never run that test mid-cycle with actuators live.

What does an example capture look like?

A packaging line with three values, a case counter, a dryer temperature and a downtime total, copied with the clock at 10:00 into 10 registers, and the screen holds those numbers for the next 24 h.

At the capture moment the case counter reads 1,842, an integer in one register. The dryer temperature reads 68.4 °C, a floating-point value in two registers. The downtime total reads 37 min, one integer register. The clock fields read year 25, month 6, day 14, hour 10, minute 0, second 3: the scan that satisfied the compare landed 3 s into the minute, and the one-shot still made one copy.

Storage math: 1 + 2 + 1 = 4 value registers, plus 6 clock registers, 10 registers in all. The screen line reads "Collected 14-06 10:00:03: 1,842 cases, 68.4 °C, 37 min down". The next capture comes 1,440 min later, 24 h x 60 min/h, and until then every read of those registers returns the same values whatever the live tags do.

How do you check the screen after the first capture?

Watch the snapshot registers before 10:00, confirm exactly one write at the capture, then leave the page open and confirm the values and timestamp hold while the live clock keeps advancing.

• Before 10:00: the registers hold the previous record and the flag bit is 0.
• In the capture minute: the registers change once and the flag goes to 1. Two changes mean the flag gating is wrong; no change means the compare fields are mapped wrong.
• During the day: the live clock object advances and the snapshot line holds. A moving snapshot value means another rung writes your registers; move the storage.
• At midnight: the date change clears the flag once.
• At the next 10:00: the new record replaces the old in one write.

Recommendation: build the snapshot in the controller: one one-shot copy at 10:00 of the values and the clock fields into dedicated registers, a daily flag cleared on date change, and a catch-up rung for a missed 10:00, with the panel reading only the copies. Choose retentive registers, or a log file, when the record must survive a power cycle; plain working registers are enough when the screen only needs today's record.

Questions