The battery keeps the clock and retentive SRAM, not the chart: a 3-minute interval writes 480 samples per trend per day, and a 10 KB buffer holds about 5,120 samples. Log the same tags to an industrial-grade SD card so overnight history survives any power cut.
A trend that goes blank after a power cut is not a broken panel; it is a working buffer doing what it was configured to do. The battery behind it keeps the clock and retentive memory, not an archive, and a 3-minute chart writes 480 samples a day into a buffer measured in kilobytes. The fix that keeps overnight history is to log the same values to removable storage, sized so capacity never becomes the limit. This article gives the numbers: what the battery protects, how fast the chart fills, what happens at the sample limit, the storage math for a night of 20 trends, and the restart test that proves the archive before you need it.
Why does the trend go blank after a power cycle?
The chart is drawn from a small working buffer that starts fresh at power-up: the battery keeps the calendar and retentive SRAM, and on these classic panels the trend buffer is only 10 KB per trend object.
The trend object draws from a buffer sized in kilobytes. At power-up the editor starts a new buffer, and unless the project explicitly retains trend data, the old samples leave the chart. The battery did its job; it preserved the clock and the retentive tags. It was never asked to keep the chart.
What you see points to a specific cause:
- Chart blank after a power cut, everything else normal: the trend buffer restarted or was never retained.
- Chart blank right after a project download: the editor reinitialized the trend object.
- Graph ends partway through the shift: overwrite-oldest is enabled and the limit passed.
- Clock and date reset after the outage: the battery or its holder; check the panel diagnostics.
- The whole project gone, not just the chart: a different fault with its own checklist, covered in the article on an HMI panel that loses its project after a power cycle.
What is the panel battery actually for?
It holds the clock and the battery-backed SRAM through a power cut: calendar, retentive tags and whatever the project marks retentive, and vendor guides put a fresh lithium coin cell at about 5 years of service.
Total battery-backed SRAM runs from 512 KB to 8 MB across panel models, and the trend buffers share it with retentive tags and the calendar. A dying cell shows up first as a clock that resets and retentive values that come back wrong, so check battery status in the diagnostics whenever you see either. Change the cell with the panel powered up where the vendor allows it, so SRAM stays alive through the swap, then correct the clock and re-test retention.
Cold weakens coin cells and makes retention failures more likely in an unheated corner of the plant; the article on an HMI project lost after a cold soak walks the same memory path. A battery upgrade changes service life, never chart capacity.
How many samples does a 3-minute trend collect?
A 3-minute interval fills 480 samples per trend per day, because 60 minutes divided by 3 gives 20 samples an hour and 20 times 24 hours is 480; 20 trends at that interval write 9,600 samples a day.
Sample count is one sum and memory is another: the interval sets samples per day, and the storage the editor assigns per sample sets the days the buffer covers. Read that storage figure from the trend configuration, because an integer sample and a timestamped real value differ by several bytes. Choose the interval deliberately at both ends; the article on why an HMI trend graph will not update every half second works the same trade from the fast side, and the same logic sets the slow floor too.
What happens when the trend reaches its sample limit?
One of three configured behaviors: collection stops, the oldest points roll off, or a scheduled reset clears the chart, and your editor's trend settings name which one the panel will do.
Open the trend object and read three things: the point limit, the behavior at the limit, and any scheduled reset in the project. A reset that fires at 6 a.m. discards the night exactly when the manager wants it, so archive before any reset runs; the habit is the same one behind saving a PLC counter's previous value before a reset. Where you control the design, set overwrite-oldest so the live graph keeps collecting and drops the oldest points; the pattern is the same one used to log PLC alarms to a circular event buffer with separate pointers.
Worked example: how much trend history does a night shift need?
A 16-hour unattended night at a 3-minute interval needs 320 samples per trend, 6,400 across 20 trends, and that nightly record is the number the archive must hold.
The buffer side first. Say the trend object is the classic kind with a 10 KB buffer, 10,240 bytes. A 16-bit integer sample takes 2 bytes, so one object holds 10,240 / 2 = 5,120 samples, which at 480 samples a day is 10.7 days of history for a single chart, if the project actually retains it. Twenty charts ask for 20 × 10 KB = 200 KB of buffers, which still fits inside the smallest 512 KB SRAM panels. The buffers fit; the retention policy is what the project has to promise.
The archive is a different sum. Twenty trends over a 16-hour night produce 6,400 records. A year of nights is 6,400 × 365 = 2,336,000 records, and at 100 bytes per timestamped record that is about 234 MB. A 1 GB industrial card holds about 4.3 years of nights and a 32 GB card about 137 years, so capacity never becomes the limit; write endurance and file housekeeping do.
How do you move the history off the panel?
Log the same tag to removable storage at the same 3-minute interval: panel vendors document logging to an industrial-grade SD card or a USB drive and recommend the industrial card grade for that job.
Configure the logger on the trended tag, timestamp every record, and name files by date so a new file never covers the previous night. Keep the archive off internal flash: vendors route history to a card or USB drive because steady logging wears internal flash and shortens the panel's life. The small retentive checkpoints some panels write to flash run on a 2-second backup cycle and hold kilobytes of tags; a day of samples is a job for a different medium. Many editors also provide an upload task that copies the log to a USB drive on demand. Use it for controlled pulls, and stop logging and close the log files before removing the media, which is the documented way to avoid a half-written file.
If the PLC side can log too, do it: logging PLC variables straight to a database survives a panel fault entirely and gives the manager a queryable record.
Can the trend reload the archived file after a restart?
Plan for the manager to open the log file, not for the chart to redraw itself, and treat a reload feature as something to confirm once in your editor's documentation with a known file.
The deliverable the morning after an outage is the CSV or database query with timestamps, readable in a spreadsheet. Whether your editor can import a saved log back into a trend object or display an archive in a history view is a documented feature of your model; prove it once in daylight by loading a known file and reading the times back, and write the result into the shift instructions.
A separate wall board is a different job: shop-floor screens show the room the current values as a status or notice board, but no display logs your tags. The archive lives on the card or in the database either way.
How do you prove the archive survives a power cut?
Prove it in a maintenance window: record a known sequence, archive it, cut panel power for 30 seconds, restore, and count the timestamped records from before the cut.
- Write distinct values to the tag every 3 minutes for one hour, so each trend should hold 20 samples.
- Trigger the archive, then open the file from another computer first: right record count, legible timestamps.
- Cut panel power for 30 seconds in an approved window. Never pull power on a panel that controls a running process without the process owner's sign-off.
- Restore power, confirm the clock, then count the archive: 20 records per trend, all with times from before the cut.
- Repeat with all 20 trends and confirm the panel keeps logging and stays responsive while it writes.
If a record is missing or its timestamp is blank, the fault is in file naming or the logger's stop-start behavior, and the test finds it before the night does.
Which fix fits which panel?
Log to removable media whenever overnight history must survive a power cut, keep the battery for the clock and retentive tags, and reserve battery replacement for a diagnostics report of a low cell.
Recommendation: Log the trended tags to removable media on any panel whose overnight history must survive a power cut. Keep the 3-minute interval on the live chart, set the trend to overwrite its oldest points so collection keeps going, and size an industrial-grade card at 1 GB or larger, which at 6,400 records a night is years of margin. Archive before any scheduled chart reset, or delete the reset. Replace the battery only on a diagnostics report of a low cell, because a fresh cell protects the clock and retentive tags and adds no history. Confirm the reload or history-view feature once, from a known file, before you rely on it.
Questions
Does a new battery bring the old trend back?
No. Once the buffer is cleared it is cleared; the cell only preserves what SRAM holds while it is healthy. After a replacement the clock and retentive tags come back and the chart starts collecting from zero. History you need after an outage has to come from the external log, which is why the archive goes on before the next power cut, not after.
What fields should one logged record carry?
A timestamp with the date, the tag value, and a quality or status flag if your logger offers one. One record per line in CSV keeps the file readable in a spreadsheet and makes the sizing math in this article hold: 100 bytes per record is a fair planning figure, and file names that carry the date keep a new file from covering the previous night.
Should the logger live in the panel or in the PLC?
Either, as long as the destination is outside both devices. Panel-side logging to a card keeps the file next to the machine and needs no network. PLC-side logging to a database or a network share survives a panel fault completely, so a dead panel cannot take the history with it. Run both where the budget allows: the card is the local copy, the database the permanent record.
Do alarm histories have the same limit?
Yes. Alarm buffers are small too, and a buffer that fills quietly can hide the oldest events. Design the alarm log as a ring with separate read and write pointers so a full buffer drops the oldest alarm and keeps recording, and archive the alarm file on the same schedule as the trend log so one maintenance routine covers both.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.