When Frame objects vanish, stalls lengthen and the panel locks, count trend history first. Each Total Stored Points sample takes panel memory the Project Size readout never counts. Strip every trend to restore production, then re-add one trend per download with a one-shift soak test, and keep history longer than one shift in a PLC, historian or data logger.
An HMI panel that stops drawing Frame objects, stalls for a second or two, and finally locks on an error message usually has a full memory, and trend history is where the memory went. The trap is the Project Size readout: it looks comfortable because the estimate never counts stored trend points. This page gives the failure signature, a recovery that restores production the same shift, the arithmetic that sizes a trend honestly, and a re-add procedure that finds the highest trend load the panel holds. Everything here assumes a conventional panel HMI drawing trends from controller tags; the same memory logic applies to data-log buffers.
Which symptoms point at trend memory instead of a dead panel?
Vanishing Frame objects, stalls that lengthen the longer the panel runs, then a hard lock or a white screen on a project whose Project Size readout looks comfortable is the signature of trend history exhausting runtime memory, not a panel defect waiting to be swapped out.
Match your panel against this table before you change anything, and photograph the exact error message first, whatever it says: the wording and any code are what the vendor matches against known faults, and a retyped copy can lose the part that matters.
| Symptom | What it points to | Quick test |
|---|---|---|
| Frame-type elements skip drawing on some screen visits | Early memory pressure | Note whether it correlates with time since power-up and with trend-screen visits |
| Stalls in touch response that grow longer over a shift | Same pressure, later stage | Time a screen change now and again 4 hours into the shift |
| Total freeze with an error message | Runtime memory exhausted | Photograph the message and read firmware and boot loader from the system information screen |
| Crash to a plain white screen | Same fault after part of the trend load was removed | Removing one trend screen is not the test; strip all of them |
| Identical project freezes on one panel, runs clean on its twin | Different visit history and accumulated trend data | Run both through the same screen rotation for the same uptime |
Why does the Project Size readout stay small while the panel runs out of memory?
The Project Size figure counts screens, objects and configuration only; every stored trend point is charged to runtime memory instead, so a trend's Total Stored Points setting raises real memory demand without moving that number at all.
Trend history lives in runtime memory, charged while the panel runs. The observed failure tracks the shrinkage: Frame-type elements vanish on some screen visits first, response stalls grow next, and at the end the panel locks or drops to a white screen. Raising Total Stored Points, or adding another trend screen, raises the demand silently, because the download screen still reports the same comfortable estimate. If your panel's documentation publishes a memory calculation for history data, run it on your project; if it publishes none, size by the soak test in the rebuild steps below.
The Project Size figure is one budget among several; sizing an HMI project against panel and PLC memory limits walks the full check across panel and controller limits. Trend history is not the only store that grows silently either: data-log buffers fill the same way on one screen, and fix HMI log buffer memory full errors on one screen covers that fault.
How do you get the machine running again before the next shift?
Strip every trend object and trend screen from the project, download it, and power-cycle the panel: if drawing and touch response come back for a full shift, trend history was the cause and you have a safe configuration to run while you rebuild.
- Back up the project file. While the panel is up, read the firmware and boot loader versions from its system information screen and write them down.
- Delete every trend object on every screen. Removing only the newest trend screen left panels in this fault crashing to a white screen, so strip all of them for this test.
- Download the stripped project and cycle power to the panel.
- Run the panel through its complete normal screen rotation for one full shift. Frame-type elements must draw on every visit and stalls must stay gone.
- If the panel still freezes with no trend in the project, trend history was not the driver; go to the record section below and escalate with the vendor.
A panel that runs clean without trending confirms the diagnosis, and the stripped project is also your safe configuration to run while you rebuild.
Worked example: how much panel memory do three trend screens actually take?
Three trend screens at 16,384 stored points and 3 pens each hold 576 KB of history at 4 bytes per value, memory the Project Size readout never shows, and cutting each trend to the operator's 15-minute view takes it down to 36 KB.
Scenario: a packaging line panel has three trend screens. Each trend is set to Total Stored Points = 16,384 and draws 3 pens, and every pen logs a 32-bit value, so each stored point for each pen is 4 bytes.
Per trend: 16,384 points × 3 pens × 4 bytes = 196,608 bytes, which is 196,608 ÷ 1,024 = 192 KB.
All three trend screens: 3 × 192 KB = 576 KB of history the panel must hold, none of it visible in the Project Size readout.
Operators on this line watch the last 15 minutes of each trend at a 1-second update. The axis depth they need is 15 min × 60 s/min = 900 points, so Total Stored Points = 1,024 covers the view with headroom.
Recut per trend: 1,024 × 3 × 4 = 12,288 bytes = 12 KB, and 3 × 12 KB = 36 KB for all three screens. The cut frees 576 − 36 = 540 KB, a 94% reduction, and operators see exactly the window they used.
Two rules fall out of the arithmetic. Demand scales linearly with the point count: half the points holds half the bytes. A panel logging 16-bit values halves every byte figure above, and the method is unchanged. History longer than the operator window belongs in the PLC, a historian or a data logger sized for the job. The 1-second update is also a drawing load; where the panel cannot redraw that fast, why an HMI trend graph will not update every half second covers the interval limit, and fit a multi-hour temperature trend on an HMI without scrolling shows how a longer time span shares the same point budget.
How do you add trend screens back without the freeze returning?
Re-add one trend screen per download, and after each one run the panel through its complete screen rotation for a full shift; the moment vanishing Frame objects or stalls return, stop and keep the last configuration that passed.
- List every trend object with its screen, pen count and Total Stored Points value, then set each one to the operator's viewing window using the example arithmetic.
- Delete trends that duplicate one another and trends on screens operators rarely open; every point on an unread screen is memory spent for nobody.
- Re-add one trend screen per download, and soak each with repeat visits to every screen, including the new trend screen.
- When Frame-type elements vanish or stalls return, stop and fall back to the last configuration that passed a full shift.
If the trend or its log writes history to a removable memory card, try the panel's internal storage or a USB drive as the destination instead: on one panel family the card path itself stalled the panel, and moving the log was the vendor's published workaround.
Recommendation: size every trend to the operator's viewing window, re-add trends one per download with a one-shift soak test after each, and route history longer than one shift to the PLC, a historian or a data logger instead of panel memory.
Why does only one of two identical panels freeze?
Runtime memory depends on which screens operators opened and how much trend history accumulated since power-up, so two panels with identical projects can fail differently, and a replacement panel will freeze the same way once its history fills.
The clean twin is not proof the failing unit is defective. Treat the panel swap as a dead end: a replacement loaded with the same project and the same trend budget freezes the same way once its history fills. Firmware is the other dead end for this signature, because a newer build does not shrink the trend history budget; update on a convenient day and read the release notes, but make the repair in the project.
What should you record before calling the panel vendor?
Send the photographed error message, the firmware and boot loader versions from the panel's system information screen, the project file, and the trend list with pen count and Total Stored Points for every trend, plus what the twin panel did.
| Record | Why support needs it |
|---|---|
| Photographed error message | Wording and codes match known faults |
| Firmware and boot loader from the system information screen | Rules builds in or out before anyone ships code |
| Project file | Support can compute the real demand, history included |
| Trend list: screen, pens, Total Stored Points per trend | This list is the runtime memory budget |
| Twin panel behaviour and uptime at failure | Separates a project fault from a hardware defect |
If the panel is an embedded device you can reach over the network or a service port, its logs at the moment of the freeze say more than any bench run; capture logs on an embedded Linux device that freezes shows how to collect them before a power cycle clears the scene.
Send the package with a one-line timeline: when Frame-type elements first vanished, when stalls started, and what the trend-stripped test changed.
Questions
Will trend history wear out the panel's memory card before the freeze?
Not at panel write rates. Card service life is its TBW rating divided by average daily write volume: a card rated 64 TBW taking a 100 MB/day data log lasts 64,000,000 ÷ 100 = 640,000 days, about 1,750 years. Wear is not the limit that freezes your panel; runtime memory exhaustion and storage stalls are. TBW is the total bytes writable figure printed on the card datasheet.
Is it safe to keep running until the next maintenance window?
Yes, on the stripped project, not on the failing one. Vanishing Frame objects are the early stage of the same memory pressure that ends in a hard lock, and a locked panel stops the line with it. Download the trend-stripped project from the recovery steps and run production on it; operators keep live values on every screen and lose only the history, which belongs outside the panel anyway.
What if the panel still freezes with every trend removed?
Then something else is consuming runtime memory: data-log buffers, alarm or audit history queues, or an object that never releases its allocation. Remove the history producers one group at a time, logs first and alarm history next, soaking one shift per removal. If the panel still locks with no history producer left, escalate to the vendor with the project file, the photographed message and the version record.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.