HMI freezes when opening a screen: check project memory

What makes the screen freeze when it opens

The design software totals the screens, objects, text and bitmap files in the project and prints the result as Project Size. Trend history is different. Each stored point is a value and a timestamp the panel writes while it runs, and every point takes memory. That runtime memory sits outside the Project Size calculation, so a project can report as fitting while its trends are set to consume several megabytes more than the panel has left.

Opening a trend-heavy screen is when the bill arrives. The runtime allocates memory for the screen and its trend data, finds the store already spoken for, and stalls. A power cycle clears the allocation and the panel comes back, but the project's demand is unchanged, so the same screen freezes again the next time it is pressed. The same accounting explains a panel that slows over weeks of accumulating history and then locks: see what happens when trend history fills panel memory.

If you are building the memory budget from the start, put the trend bytes in it yourself; the Project Size report will not add them for you. That is the first step in sizing an HMI project against panel and PLC memory limits.

One rule before any of this: if the frozen screen is where operators read alarm counts or shutdown status, keep a person watching the line until the re-test in this page passes. A panel that hides alarm state is a safety problem.

Symptoms and what each points to

Work down this list; the first three rows are the memory case this page fixes.

• One screen, always the same one, freezes as it opens. That screen's demand is the suspect: a trend with a large Total Stored Points count, or heavy bitmaps.
• A power cycle brings the panel back, and the same screen freezes again. Memory exhaustion. The reset clears the allocation; the demand stays.
• The freeze began after a trend was added, images were imported, or a software or firmware update went in. The project crossed the limit. Treat the version change as a clue; check the memory sum either way.
• An error screen appears before the lockup. Photograph it or write down the exact text; a memory message confirms the diagnosis.
• A memory-full message tied to one screen's log buffer, without a freeze. Same budget, different sink: see how to fix HMI log buffer memory full errors on one screen.
• Blank or frozen from power-up, on every screen. Different fault: check power first.
• Freezes on all screens and lands when large coils or contactors switch. Look at the supply: a shared DC supply with solenoid coils can freeze an HMI.
• Slow everywhere before it locks. Read the CPU utilization figure in the panel's diagnostics; a runtime pinned near its limit behaves much like an out-of-memory panel.

Checks before you edit the project

1. Power cycle to restore service, and time how long the panel stays up.
2. Write down which screen freezes and at what moment, and capture the exact error text.
3. Read Project Size from the project report, and read the panel's user memory from its specification or diagnostics.
4. List every trend object with its Total Stored Points and sample interval, and count the bitmap images with their pixel sizes.
5. Save a backup copy of the project and record the software and firmware versions installed. Edit the copy, never the only file.

Cut Total Stored Points on the trend

Open the trend object's settings and read Total Stored Points, the number of samples that trend keeps. Every point takes memory, so this setting is the biggest lever you have.

Set the count from the process need, then check it against the memory: points needed = retention time ÷ sample interval. A screen that must show the last 8 hours at one sample every 10 s needs 8 × 3600 ÷ 10 = 2,880 points. Holding 30 days at the same interval needs 30 × 86,400 ÷ 10 = 259,200 points.

For the memory side: trend bytes = Total Stored Points × bytes per point. Work from 8 bytes per point for a 32-bit value with its timestamp; at 4 bytes per point the memory halves and at 16 bytes it doubles. The design software's data-type table has the exact figure.

Cut the largest trend first, rebuild, download and test before touching anything else, so you know which change bought the headroom.

Example: sizing the cut so the screen opens

The memory figures below are example values; take your own from the panel and the project report, and run the same arithmetic.

The panel has 64 MB of user memory. Project Size reads 61 MB, so 3 MB is free. The project carries two trends:

• Trend A, line pressure: Total Stored Points 50,000 × 8 bytes per point = 400,000 bytes = 0.4 MB.
• Trend B, oven temperature: Total Stored Points 500,000 × 8 bytes = 4,000,000 bytes = 4 MB.

Together the trends ask for 4.4 MB against 3 MB free, 1.4 MB over. The screen that opens both trends stalls every time.

Budget what is left for Trend B: 3 MB - 0.4 MB = 2.6 MB = 2,600,000 bytes. The largest count that fits is 2,600,000 ÷ 8 = 325,000 points. Set Trend B to 300,000 points, which is 300,000 × 8 = 2,400,000 bytes = 2.4 MB, and the two trends total 2.8 MB, leaving 0.2 MB of headroom.

At one point every 10 s, Trend B held 500,000 × 10 s = 5,000,000 s, about 58 days of history; at 300,000 points it holds about 35 days. If the line needs 58 days on the panel, the panel cannot hold it: keep the cap and move the deep history off the panel, as in archive trend history externally. If 35 days covers the process, the cut is the whole fix.

Trim the bitmaps next

Memory for an image scales with its pixels, not its file size. A 1024 × 768 image at 24-bit color decodes to 1024 × 768 × 3 bytes = 2,359,296 bytes, about 2.4 MB, even if the file on disk is a few hundred kilobytes. Twelve such photographs commit about 28 MB of runtime memory.

Remove the images no screen uses, and swap photographic backgrounds for flat graphics where operators only need labels and status colors. Download one change at a time so you can see which cut opened the gap.

Test the panel before the line runs

1. Download the revised project and open the screen that froze ten times back to back. It should open each time, with no error screen and no hang.
2. Open the other heavy screens too: the bitmap-heavy displays and any screen with several trends, because the memory is shared.
3. Let the trends run through a shift, then confirm they still record and that the retained depth matches what the process needs.
4. Write the revision and the setting changes into the project notes, so the next engineer sees why the counts are what they are.
5. If the same screen still freezes after the trend and bitmap cuts, restore the backup, capture the exact error text with the software and firmware versions, and send the project to the panel vendor's technical support with a note of what you already changed. Support can size the file against that panel model.

The decision

Recommendation: When one screen freezes the moment it opens and the project carries trends, treat it as memory: read Project Size, total the trend bytes as Total Stored Points × bytes per point, cut the largest trend until trend memory plus Project Size sits below the panel's user memory, and confirm it with ten consecutive opens. Keep the power cycle as the service restore only. If the frozen screen carries alarm counts or shutdown status, keep a manual watch on the line until the re-test passes.

A notice board or andon-style display that runs on its own, offline and outside the HMI project, is a separate job. That is what we build shop-floor signage displays for: the HMI keeps its project small, and the floor keeps its messages.

Questions