Fix an HMI bitmap that slows PLC data updates

What each symptom points to

• Slow values and lights only on the screen that carries the drawing. Rendering load. The panel is spending its refresh time on the graphic; the hide-the-bitmap test below settles it in minutes.
• Every screen is slow, drawing or no drawing. The link or the poll period, not the bitmap. Check the packet counters first, then the poll setting.
• The poll period is set to 0 ms. The panel is firing requests as fast as it can, and a heavy screen makes that worse. Test a small fixed period: 1 to 2 ms.
• The poll period is 100 ms or more. Every value on that screen refreshes only as often as the period allows, 10 updates per second at best at 100 ms. Test a faster period in the 5 to 10 ms range.
• Lost packets or climbing retry counts in the link diagnostics. The network path. Fix that before touching the project again.

Hide the bitmap in a project copy

Run this test on a copy of the project, on a screen the operator is not relying on; an edit on the live screen can hide a real alarm while you watch.

1. Record a baseline. Pick one thermocouple value and one indicator light, and time how long each takes to change on the affected screen. A 30-second video of the screen works as the record.
2. Save a copy of the project and open the copy.
3. Hide or delete the drawing on that screen. Leave every value field, indicator light, PLC address and communications setting exactly as it is.
4. Load the copy to the panel and repeat the 30-second observation under the same conditions. Repeat once more if the drag comes and goes.
5. If response recovers with the drawing gone, the rendering of that graphic is the load; continue with the transparency check. If nothing changes, put the drawing back and move to the poll period and the link.

Do not clear the bitmap as a suspect just because the file is small. Pixel dimensions, file format and transparency weigh more than kilobytes, which is why the tests below take each apart separately.

Turn off transparency you do not need

Transparency is the most expensive thing a bitmap can carry. Panel vendors say as much in their own support pages: a runtime responds slowly when it has to process large bitmaps with transparency, transparent graphics have been documented turning black after a firmware upgrade until the transparency option is switched per graphic, and transparent elements have been documented losing their transparency at random until a refresh is forced.

In a project copy:

1. Find the transparency setting on the graphic object, or in the project's graphics resources; your project software's manual names the exact spot.
2. Turn it off, load the copy, and retest against the baseline.
3. If the drawing must blend into the screen, export a copy whose background colour matches the screen background and drop the transparency entirely. The screen looks the same and the panel has no blending to do.

Older project formats carry extra traps with BMP and GIF transparency; bitmap transparency limitations and workarounds for BMP and GIF files covers the common ones. When the drawing has to update live instead of sitting still, a documented caching setting can change the behaviour completely: NumCachedImages 0 for live bitmap updates.

Worked example: a 75 kB drawing on an 8-inch panel at a 100 ms poll period

Inputs, and where each comes from:

• Poll period as configured: 100 ms, read from the project's communication settings; the kind of high value worth testing downward.
• Drawing: about 75 kB, drawn on the screen background, transparency off (from the installation that showed this fault).
• Panel: an 8-inch touch panel talking to the PLC over an Ethernet card (from the same installation).
• Test values: 5 ms and 10 ms; 1 to 2 ms only where the period was 0.

The rule in words: a poll period of P ms asks the PLC for fresh values once every P ms, so the screen gets 1000 ÷ P update chances per second, whatever is drawn on it.

Arithmetic:

• 1000 ÷ 100 = 10 updates per second at the 100 ms setting.
• 1000 ÷ 10 = 100 updates per second at the 10 ms test value.
• 1000 ÷ 5 = 200 updates per second at the 5 ms test value.
• 200 ÷ 10 = 20, so going from 100 ms down to the 5 ms test value puts 20 times the transactions on the link.

Result: at 100 ms, every value and light is at most 10 updates per second fresh, and an indicator light that steps faster than that cannot be seen to step at all. At the faster test values the same screen gets 100 to 200 updates per second, enough to keep lights and numbers current as long as the link carries the load.

Decision: if the configured period sits above 20 ms, which is under 50 updates per second (1000 ÷ 20 = 50), and the screen drags, move it to the 5 to 10 ms range and retest. Once you sit there with zero lost packets, polling has headroom and a still-slow screen points at the drawing; go back to the transparency check. Keep the period at or above 1 ms: at 1 ms the panel would fire 1000 requests per second, and that can swamp a small PLC's link.

Set the poll period and watch the link

The poll period sits in the project's communication settings. The panel's configuration software carries the link diagnostics beside it.

1. Record the configured period and the diagnostics counters: errors, retries, disconnects.
2. Change only the period. From 0 ms, test 1 to 2 ms; from 100 ms, test the faster values from the example. If the software rejects a value, use the smallest it accepts.
3. Retest against the baseline, then read the counters again. New errors at the faster period mean the link or the PLC is at its limit; restore the original value.
4. The period is not the whole story. Every extra panel on the link multiplies the transaction count, which connecting many operator panels to one PLC works through, and the poll structure matters too when one panel reads two PLCs: one HMI reading two PLCs.

A device that stops answering the link altogether is a different fault: HMI no communications when one PLC model fails walks through that case.

Make the change hold

Apply to the production project only the one change that restored response, with the original project saved untouched. Verify during normal operation with the drawing on screen, and read the packet counters once more after a full shift. Write down the before and after: poll period, project version, panel model and screen size, bitmap file size and format, transparency state, packet counts.

If no single change isolates the drag, send the project and that record to the panel vendor's support desk; that beats more blind edits on a machine in production. If the drawing cannot stay without the delay, run the simplified screen temporarily and have the project reviewed.

Do not keep shortening the poll period to mask a rendering load: 1 ms is a test value. Once the cause is fixed, step the period back up to the slowest value that keeps the screen current, usually somewhere in the 5 to 10 ms band on a link this small.

If the conclusion is a new panel for the operator, the HMI stays the HMI. Our panel-mount Android displays are built for a separate status or notice board next to the machine, not as a replacement for the panel running it.

Recommendation: test in this order, one change at a time: hide the bitmap in a project copy; if response recovers, turn off transparency you do not need and match the drawing's background colour to the screen background; if the bitmap is not the cause or transparency is already off, set the poll period to the faster range from the worked example (1 to 2 ms from 0) and watch the link for lost packets. Keep whichever single change restores response for a full shift and return every other setting to its original value.

Questions