HMI historical chart slows when scrolling back: find the cause

Symptoms and what each one points to

• One chart hangs, only past a few hours of history, so badly the application has to be closed by force. The requested span is loading the chart. Run the range test in the next section.
• Every chart is slow, even over an hour, and it started after a logging change. The logging rate or the store is carrying the load. When logging itself bogs an application down, an image cycle that stalls while data logging runs in a loop shows the same pattern from the logging side.
• The trend stops moving altogether after you scroll back. That is a different failure from a slow chart; why an HMI trend stops moving after scrolling back covers it.
• The newest points arrive tens of seconds late on a chart fed from a data store. Retrieval delay or a clock mismatch between the machines does that; the FAQ below gives the two checks.
• History stops exactly where the last logging session began. The store is likely split into session files, and the chart may not reach across the boundary; the documentation for your version says whether it can.

Test a short range against the span that hangs

1. Open the same chart over the most recent hour. Note how long it takes to draw and how scrolling feels.
2. Widen the view in steps: 1 hour, one shift, 1 day, 1 week, then the span that hangs. Note the step where the draw time jumps.
3. Repeat on a second chart with a different logged variable at a similar span.
4. Read the result. A jump only at long spans puts the cause in the requested span. A slow 1-hour view puts it in the logging configuration or the store, and the test has just saved you from a wrong deletion.

Where the samples come from matters too. Some historical trends draw from memory held in the controller, and the reachable span is bounded there; historical trend graphs that need controller memory history explains that split. When you do need a long span on screen, fitting a multi-hour temperature trend without scrolling shows how the sample interval sets the span a panel can carry.

Example: a chart that logs every 5 s and hangs on 30 days of history

The inputs, with their sources:

• Logging interval: 5 s per sample. Example value. Read the real one from the logging configuration for the variable on that chart.
• Span that hangs: 30 days of scroll-back. The range the operator asked for on the panel.
• Test span: 1 hour. Chosen by you, short enough to draw instantly on a healthy system.

The rule in words: a trend draws one point per logged sample in view, so the work scales with the samples in view, which is the span divided by the interval.

The arithmetic:

• 30 days x 24 h/day = 720 h, and 720 h x 3600 s/h = 2,592,000 s.
• 2,592,000 s / 5 s per sample = 518,400 samples in the hanging view.
• 1 h x 3600 s/h = 3600 s, and 3600 s / 5 s per sample = 720 samples in the test view.
• 518,400 / 720 = 720, so the hanging view asks the panel to handle 720 times the samples of the view that draws fine.

Result: if 720 samples draw instantly and 518,400 samples freeze the application, the requested span is the load, and the file size on disk was never the thing to fix.

Decision: cap the chart's default span at the longest range operators actually use. At 5 s logging, a 24-hour default is 86,400 s / 5 s per sample = 17,280 samples, in the same class as the 720-sample test view. If a 30-day picture is genuinely needed, log that variable at 60 s for the long term: 2,592,000 s / 60 s per sample = 43,200 samples, 12 times fewer than at 5 s. While you are in the logging configuration, check the keep-days setting: a store keeping 365 days while charts show 14 holds 365 / 14, about 26 times the span anyone views, and a 30-day cap keeps 30 / 365, about 8 percent of a year's data.

Identify the store from the logging configuration

Know which file is the store before you read anything into its size. Take the storage location and format from the logging configuration and the documentation for your installed version, then use the file properties view to record size and modified time for the identified files. Record the same figures again 24 h later. Growth tells you logging is still writing, and the daily growth in MB is your logging rate on disk.

On a panel, where the store lives decides whether it survives: data logging to a CF card and picking the safe slot covers that choice. Check the retention behavior too, because many systems already run an oldest-file rollover when the log drive fills; a store that rolls over is capping itself, and a manual deletion would add nothing.

Never delete, rename or move a data file you have not identified from the logging configuration, and never while the application is running. Removing an active file can disrupt logging and erase the only copy of the process history.

Back up and export the history first

Run the documented backup procedure for your installed version before any setting change or cleanup. Then export what you must keep:

1. Export a small range first; 1 hour is enough. Most packages that keep history have a documented export to CSV, run from the chart, the logging client or a scheduled export task.
2. Open the export in a spreadsheet and check it: timestamps increase, one row per sample, values match the chart.
3. Export the ranges you must keep, label each file with the variable and the range, and store the files with the backup.

If the application offers no documented export route, stop at the backup and take the evidence to the vendor's support: installed version, storage path, file sizes and the steps that reproduce the hang. What a panel itself can hold for later retrieval varies; what an HMI panel can store for later retrieval sets out that boundary.

The fix for each confirmed cause

Only long ranges hang. Cut the chart's default span to what operators use, cap retention to that span plus margin, and, where a long picture is genuinely needed, log the variable at a slower interval for the long term, as the example shows. To keep a long span visible without the scroll-back load, showing the full test duration on a live trend chart covers the display side. Where the trend control offers a reduced-points or plot-on-change display option, your version's documentation names it; such an option trims the drawn points and leaves the stored data untouched.

Even a 1-hour view hangs. The load is the logging rate or the store. Compare the configured logging rate with what the variable needs, correct a retention setting that keeps far more than anyone views, and change one documented setting at a time, re-running the same 1-hour test after each change. If no documented setting matches the diagnosis, stop and hand the evidence to support; do not delete the store to start over.

Recommendation: Run the 1-hour test before anything else. If a 1-hour view draws instantly and the hang returns only past 30 days, cut the chart's default span to 24 hours, cap retention at 30 days, and export to CSV whatever must be kept. Touch no data file until the backup and a verified export exist, and never delete one while the application is running.

Check the chart after the change

Re-run the exact test that reproduced the hang: same chart, same span. A 30-day view carried at 60 s logging now holds 43,200 samples and should draw within seconds. Scroll to the oldest kept day and confirm the values and timestamps appear. Confirm logging still writes: the store's newest file advances and the newest point lands on the chart. Keep the backup and the verified exports for as long as you would have kept the original store.

Questions