HMI trend Total Stored Samples: fit the panel's memory

Why a small file fills the panel at download

The file size on disk and the size the panel reports at download are two different measurements. The download figure is the one the limit applies to, and it grows with runtime allocations, trend history above all. Match what you see against this list:

• The download stops with a memory-limit message while the file on disk is small. In the reported case, 976 KB on disk against a 10 MB download cap. Points to allocations charged at download.
• The download figure is many times the disk figure. The case grew about tenfold on download. Points to per-sample allocation, and trend history is the usual driver.
• One trend accounts for hundreds of kilobytes. About 750 KB per trend in the case. Points to that trend's Total Stored Samples count.
• The SRAM diagnostic reads almost empty. The case showed 3 KB used of 256 KB. The SRAM page tracks a 256 KB pool and the download limit was a 10 MB project budget, so read the download message for project-size questions.
• A trend is set to 65535 samples. People set the maximum believing it feeds data logging. It sets cursor depth only, and at 65535 it costs about six and a half times what a 10,000-sample trend costs (the example below works that scale out).

History can also bite at runtime, after the download has succeeded. If the panel freezes while trend history fills its memory, the panel-memory freeze article covers that separate failure.

What Total Stored Samples sets, and what it leaves alone

The setting is the number of samples the panel keeps behind the trend cursor. The trend object draws a fixed number of points per screen, 99 on the reported panel. Your panel's programming manual documents the trend object's settings and log types in its objects chapter, so check your own points-per-screen number and use it in every calculation below. Paging back walks the stored samples screen by screen, so a trend holding 10,000 samples at 99 points per screen takes about 101 page-backs to reach the oldest point. Almost nobody makes that trip.

Two nearby settings do different jobs:

• The trend's sampling interval spaces the points the trend draws. Interval multiplied by stored samples is the time the cursor can reach back.
• Data logging collects temperatures, flows, levels, pressures and alarms as records and writes each one to an external destination, CF1, C2 or USB in the reported setup. Your panel family's help system documents that job in its logging and trends section. Trimming the cursor history leaves the logging configuration and its records in place.

And when the real requirement is weeks of history for engineering review, that belongs in the PLC or a logger; the historical trend graphs and PLC memory article covers that split.

Checks to run before you cut anything

1. Record the exact download message and the project size it reports. That number is the budget.
2. Record the panel's memory pages as a baseline: SRAM and built-in flash. The case's flash page read 9,870 KB used of 49,312 KB.
3. List every trend object with its Total Stored Samples value and its sampling interval.
4. Ask the operators how many screens back they actually page while troubleshooting. Their answer sets the target.
5. Measure your panel's bytes per sample: download once, remove a known number of samples from one trend, download again, and divide the change in reported size by the samples removed.

The fix: size each trend to the real look-back

1. Convert the operator answer to a sample count: look-back time divided by the sampling interval, rounded up to the next hundred for headroom. If the answer came in screens, multiply screens by points per screen.
2. Set Total Stored Samples to that count on each trend. Work through the largest counts first; each one freed returns the most budget.
3. Leave the data logging configuration untouched: same destination, same interval. If records run to the CF card, keep them there; the CF card data logging article covers picking the safe slot.
4. Rebuild and download. The limit message should clear. Re-read the memory pages and compare against the baseline.
5. Open each trimmed trend, page back to the oldest kept point, and confirm the window matches what operators asked for. If the trend stops moving after you page back, the scroll-back article lists the checks.
6. If the message survives the trim, compare the before-and-after download sizes; the remaining allocation shows up as the difference. Repeat per trend, largest first, then work through other project resources with the panel's diagnostics.

Example: the panel that filled a 10 MB limit with trend history

Inputs, and where each comes from:

• Download limit: 10 MB, read as 10,240 KB at 1,024 KB per MB (the case's reported limit).
• Project file on disk: 976 KB (the case).
• Download cost per trend: about 750 KB (the case).
• Points per screen: 99 (the case's trend object).
• Configured history: one trend at 10,000 Total Stored Samples (the case's working example).
• Illustrative resize inputs: operators page back about three screens, and the trend samples every 5 s. These two are this example's assumptions; take yours from your operators and your trend configuration.

Rule in words: samples to keep = look-back divided by sampling interval, and the download cost falls in proportion to the sample count. The case's numbers set that scale: 750 KB ÷ 10,000 samples ≈ 75 bytes per sample.

Arithmetic:

1. Growth at download: 10,240 KB − 976 KB = 9,264 KB. Against 750 KB per trend: 9,264 ÷ 750 ≈ 12, so the growth is about twelve trends' worth of sample allocation, and the 976 KB of screens is a rounding error beside it.
2. Page depth as configured: 10,000 ÷ 99 ≈ 101 page-backs to reach the oldest sample. The three screens operators actually use come to 3 × 99 = 297 points, so set 300.
3. Coverage check: 300 samples × 5 s = 1,500 s = 25 minutes of look-back. If a shift needs more, 600 samples × 5 s = 50 minutes.
4. New cost per trend: 300 × 75 bytes = 22,500 bytes ≈ 22.5 KB, down from 750 KB. Twelve trends: 12 × 22.5 KB = 270 KB, down from 12 × 750 KB = 9,000 KB.
5. Freed budget: 9,000 − 270 = 8,730 KB, about 8.5 MB of the 10,240 KB limit. The deployed project lands near 976 + 270 = 1,246 KB, about 12% of the budget.

Result: the download clears with roughly 9,000 KB free, so screens can be added again. Decision: any trend whose operators stop within three screens gets about 300 samples; any trend that must reach back further gets sized from its own look-back and interval; anything longer, a week of process records for instance, moves to data logging on the external destination, outside the download budget.

Recommendation

Recommendation: Size every trend's Total Stored Samples to the look-back its operators actually page through, computed as look-back time divided by sampling interval, or screens back multiplied by points per screen. Treat about 300 samples as the starting point for a trend nobody mines deeply, and set no trend to 65535. Keep Total Stored Samples out of every logging decision: long records belong in data logging to the panel's external destination, which stays outside the download budget. Confirm with one download; in the reported case each trimmed trend freed about 730 KB, from 750 KB at 10,000 samples to 22.5 KB at 300.

Questions