Fix a slow HMI panel: touch, entry and screen update delays

Why does an HMI panel feel slow to touch and slow to update?

Because three different delays produce that feeling, and each has its own fix: the panel's touch response, the poll time between panel and PLC, and the way a screen-change word travels from the PLC; classify the symptom before you change any setting. Write down which action fails and time it with a stopwatch, because the numbers decide which check comes first.

• A key press needs an unusually long hold before the machine reacts. The touch path: panel touch handling or the PLC scan. Note whether the panel itself reacts before the machine does.
• Digits drop when numeric entry is typed at normal speed. Treat it as the touch path first and retest after the poll and build fixes below; if one digit position still drops, record which one.
• A PLC-commanded screen change lands only sometimes. The read path: the poll interval or a dropped exchange. The worked example below sizes the wait.
• Everything slowed down after a settings change. Port and protocol stopped matching; see the matched-pair check.
• The panel registers presses nobody made. A different fault with its own checks: see HMI ghost touch at high temperature: check before replacing.

What poll time should I set between the panel and the PLC?

Set the poll time to the lowest value the panel accepts: the manual for the panel in this fault lists a 1 second default, a setting of 0 produced much faster updates, and the poll interval, not the baud rate, decides how long a changed word waits. The poll time is the deliberate gap the panel leaves between data requests; it exists so one panel cannot flood the PLC with requests. Open the panel manager, the setup area for communications with the PLC, and find it on the PLC connection.

Write the current value down, set the lowest accepted value (0 on the panel in this fault), then retest the three actions from the list above before touching anything else. Each panel on the port adds its own exchange load, so when several panels share one PLC, lengthen the poll until updates stay fast for all of them; the budget behind that is in connecting many operator panels to one PLC without slow updates. If your software can watch the exchange, an alarm on time since the last good poll turns a stalled poll into a visible event (polling driver alarms that track time since the last good poll).

Worked example: how much delay does a 1 s poll add to a screen change?

Up to one full second for the read alone: the PLC writes 2 into the screen-change register V3000, the panel asks for that register once per poll, so with a 1,000 ms poll the average wait is 500 ms and the worst case is 1,000 ms. The assumptions are inputs you can read off your own system: poll time 1,000 ms; one exchange of 20 bytes at 19,200 bit/s with the standard 10 bits per byte; PLC scan time 10 ms.

• Exchange time: 20 bytes × 10 bits ÷ 19,200 bit/s = 200 bits ÷ 19,200 bit/s ≈ 10.4 ms.
• Worst case at the 1 s default: 1,000 ms waiting for the next poll + 10.4 ms exchange + 10 ms scan ≈ 1,020 ms from PLC write to screen change.
• Average case: 500 ms + 10.4 ms + 10 ms ≈ 520 ms.
• With poll time 0: 10.4 ms + 10 ms ≈ 20 ms, about 50 times faster worst case (1,020 ÷ 20 ≈ 51).
• Why more baud never helped here: 10.4 ms of traffic every 1,000 ms keeps the port about 1% busy (10.4 ÷ 1,000), so the link spent 99% of each interval idle at any speed.

Decision for these inputs: the 1 s poll sets a one second ceiling on every PLC-commanded word, and cutting the poll to 0 drops the ceiling to about 20 ms. The wait scales linearly with your own poll value: a 250 ms poll averages 125 ms and peaks at 250 ms.

Do the port and protocol have to match when I compare settings?

Yes: both ends must run the same protocol on the same physical port, because a port change with the old protocol still selected only retests the old protocol; in the documented case the working pairing was Port 2 with DirectNet in place of K-sequence. The vendor duplicated the fault on the native K-sequence pairing and prescribed that combination. One installation changed the port but left K-sequence selected, saw no improvement, and counted the protocol as failed when it had never been tested.

When the pairing was correct, the results split: DirectNet improved touch response but refreshed screens more slowly than K-sequence, so the two protocols trade one delay for another. A second installation, on a different PLC model in the same family, saw no difference between the two protocols at any tested speed. Treat the swap as a test with three possible outcomes: time touch response and screen refresh separately after each matched change and keep the pairing that wins on the action that matters. If neither pairing improves your unit, the delay sits in poll time, scan or firmware, and the port settings go back to the matched configuration you started from.

How long must a momentary bit stay on for the PLC to see it?

Longer than one PLC scan, because the logic samples panel-written bits once per scan: at a 10 ms scan the bit must survive at least 10 ms, and 20 to 30 ms, two to three scans, is the practical margin for a bit that lands just after a sample. Press the test key once while watching the bit live in the PLC, then read the scan-time diagnostic from the PLC while the test runs. Three results tell the three causes apart:

• One clean transition per press, scan 10 ms or less. The PLC side is healthy and the felt delay is upstream, in poll time or touch handling. Do not add one-shots or timers here; pulses stacked on top of an upstream delay bury the real fault and make the program harder to diagnose.
• The bit disappears before the next scan. Lengthen the hold time. Where the key object offers a hold or pulse duration, set it to at least two scans; at 10 ms that is 20 ms.
• The diagnostic reads 50 ms or more. An older controller's scan is itself part of the press delay, and the panel's hold time must clear it with margin.

One press should produce one transition and one machine action.

Why does a panel button change screens instantly but the PLC word does not?

A screen-change button runs inside the panel, so its only delay is the panel's own processing; a PLC-commanded change waits for the panel's next read of the register, up to one full poll interval, which is why the button was instant while the word hesitated. In the documented fault, a screen written as K2 into V3000 failed to land every time, while the panel's own screen-change object changed screens with no hesitation. Run the same isolation test on your unit, then decide by job:

• Navigation only, the operator moves between screens. Use the panel's own screen-change object and leave the PLC out of it; this removed the hesitation completely in the reported case.
• The PLC must pick the screen, by recipe, fault or mode. Keep the word, keep the poll fast, and count reliability: cycle the PLC-written change ten times and count how many land. Nine or ten out of ten after the poll fix is a working path; fewer points at dropped exchanges on the serial link, which fix dropped PLC-triggered messages on a serial HMI panel walks through.
• The word changes but the screen ignores it. Confirm the panel's screen-change register address matches the one your logic writes, because a mismatched address looks exactly like a word the panel never sees.

When does a software update fix slow touch response?

When the delay lives in the panel's touch handling instead of in any setting: in the documented case the vendor's panel software build 1.11.6.51 corrected slow touch response, and no poll or protocol change reproduces that fix on an older build. Ask the panel vendor which current build carries the correction for your model, install it, and repeat the three tests. The numeric-entry symptom shares the touch path: type a 6 digit value at normal speed and check that every digit arrives in order. If digits still drop after the update, record which position drops and report it with both projects; that detail separates a touch fault from an entry-object fault faster than any description of slowness. A fault that survives a matched pairing, a fast poll, a verified scan and a current build needs the vendor's duplication, and the projects are what they ask for.

What order should I test the fixes in?

Classify, then pair, then poll, then scan, then build: one change at a time, the same three tests after each change, and you keep whichever poll value holds touch response, entry accuracy and screen changes together at the same time.

1. Time each action with a stopwatch and write the numbers down: key press to machine reaction, a fast numeric entry, a PLC-commanded screen change. The worst number is the one you fix first.
2. Match the pair: confirm both ends run the same protocol on the intended port before comparing anything else.
3. Set the poll time to the lowest accepted value and retest all three actions.
4. Read the PLC scan diagnostic, press each key once, and confirm one clean transition per press; set hold time to two scans where the key object offers it.
5. Move navigation-only screen changes to the panel's own screen-change object.
6. Install the current panel software build that carries the slow-touch correction.

Retest the same three actions after every step. Before you trust a repaired press that starts motion, test the writes the way operator panel PLC link setup: test writes before motion describes.

Recommendation: Set the poll time to the lowest value the panel accepts before touching any PLC logic; on the panel in this fault that value was 0 and updates sped up immediately. Keep port and protocol matched for every comparison, hold momentary bits for at least two scans, and give navigation-only screen changes to the panel's own screen-change object. If the PLC must choose the screen, the combination to keep is a 0 to low poll time, the matched protocol pair and the current build, retested with ten PLC screen changes per configuration.

Questions