Why an HMI button response delay runs several seconds

Separate the touch, the write and the redraw

A pushbutton on an HMI is four operations, each on its own clock. The panel registers the touch, writes the command to the PLC, collects updated data, and redraws the object. A delay in any stage looks identical to the operator, so time the stages separately before changing anything. The write stage and the PLC scan interact in ways that matter for momentary buttons; HMI button writes vs the PLC input scan: what changes works that side out. This fault lives in the redraw, and the evidence is the sequence: the value moves first, the graphic follows seconds later.

Watch the PLC value on the controller, in the programming software or on an indicator wired to it. The panel's numeric display and its graphics are both redraws, so either can lag the controller, and the graphic can lag the numeric display.

Symptoms and what each one points to

• PLC value changes first, graphic moves 3 to 12 s later. The redraw stage is late, so work on panel project load.
• The same tag animates within 3 s on the main screen and about 9 s on a popup. The popup's contents are the load.
• Disabling one popup drops response under 1 s. That popup holds the largest share of the delay, so strip it in groups and retime after each group.
• Response roughly halves, from 6 s to 3 s, with the PLC in program mode. The running program shares in the delay, and the remaining seconds belong to the popup. Program mode also halts the machine logic, so it is a measurement step.
• Deleting PLC logic down to the END statement changes nothing. The controller side is clean, so stop editing PLC code for this symptom.
• A trend line stays flat while you adjust, then catches up seconds later. The graph is history arriving late, so judge the adjustment on the pump gauge or the live PLC value.
• A momentary button stays on, or a switch keeps toggling after release. Two authorities are writing one bit, which is a separate fault with its own fix below.
• Some graphics come up as black boxes on one screen. Note the screen and the objects, treat them with the popup strip-down, and log them as a separate fault if they survive it.

Time the three stages

1. Record the panel with a phone camera while a colleague or the operator presses the button. At 30 frames per second each frame is about 33 ms, far finer than the seconds you are chasing.
2. Mark three times for one press: the touch, the PLC value change, and the graphic move. Read the PLC value in the programming software or on an indicator wired to the controller. Repeat five presses and keep the worst.
3. Read the PLC scan time from the controller diagnostics. The order of magnitude is what matters: a 3 s delay against a 20 ms-class scan is about 150 completed scans.
4. Copy the suspect switch onto the main screen, keep the same tag, and press both. A gap between the two copies sits in the screen, never in the tag or the link.
5. Work in a saved copy of the project, disable the suspect popup, load the copy, and retime. Read an HMI project from the panel before editing shows how to keep a return path.
6. Put the PLC in program mode once, retime, and put it back in run. Expect a partial improvement only, and treat it as evidence about where the load sits.
7. Load a minimal project with one button. If the delay survives that, the panel hardware or its supply is next, and check the HMI programming cable power pin first is the pattern to follow before ordering anything.

Worked example: a 3 s button on a pump test rig

Inputs, with units and where each comes from:

• PLC scan time: 16 ms typical, 15 ms minimum, 22 ms maximum, read from the controller diagnostics on the rig.
• Button delay: 3 s typical, 12 s worst case, timed on the panel between touch and graphic.
• Screen comparison: the switch animated within 3 s on the main screen; the popup copy moved about 6 s later still, so about 9 s from touch to graphic.
• Link test: a direct crossover cable between panel and PLC changed the timing by 0 s.
• Popup disabled: response under 1 s, same button, same tag.

Rule in words: a display-side delay shows up as a PLC value that lands within one scan while the graphic moves many scans later. Convert the delay into scan cycles by dividing delay by scan time. The share owned by one screen is the gap between response with that screen open and with it disabled.

Arithmetic:

• 3000 ms ÷ 16 ms ≈ 188 scans for the typical 3 s delay; 12,000 ms ÷ 16 ms = 750 scans for the 12 s worst case.
• Against the 22 ms slowest scan, 12,000 ms ÷ 22 ms ≈ 545 scans. Even at the slowest scan, the controller ran hundreds of cycles inside the delay.
• Screen comparison: 9 s - 3 s = 6 s of the 9 s with the popup open, and 6 ÷ 9 ≈ 67 percent.
• Disable test: (3000 ms - 1000 ms) ÷ 3000 ms ≈ 67 percent. Two methods give the same share.

Result: the controller completed roughly 190 to 750 full scans between the touch and the redraw. The value reached the panel; the drawing did not. One popup accounted for about two thirds of the delay.

Decision: when the PLC value lands within one or two scans, here 32 to 44 ms, and the graphic moves more than 1 s later, the delay is display-side, so work on the panel project and leave the cabling and scan settings alone. When the PLC value itself moves seconds after the touch, the link and the controller path are the suspects instead.

Cut the popup down until response returns

Strip the popup in a test copy and hold everything else constant: same button, same tag, same press pattern.

1. Remove the popup's objects in groups: first the trends and graphs, then the animations, then anything that redraws without a user action. Retime after each group.
2. The group that restores the speed of the main-screen copy owns the delay. Rebuild that group lighter, or move it to a screen the operator opens deliberately and closes after use.
3. Restart the panel when slowness, hangs or crashes spread across screens. Panel vendors name low memory on the HMI device as a possible cause of slow, hung or unresponsive operation, and the remedy they prescribe is a restart. A restart changes nothing in the project, so a delay that returns after one points straight back at project content.

Give the switch one authority

The toggling switch used the screen's internal memory for instant graphics. An event copied that state to PLC bit C213, and two more events copied C213 back into the screen switch. That is two authorities for one command: the panel writes the PLC, the PLC writes the panel, and each can start the other. With refresh running seconds late, the two states chase each other, which matches the on-off cycling after release.

Choose one owner:

• Let the panel switch write one PLC bit, one direction, with no write-back event.
• Put the PLC's own status bit in a separate object, so the operator sees the command from the switch and the accepted state from the PLC.
• If you keep panel-internal memory for fast feedback, confirm in the project that no event copies PLC status back into the same switch.
• Test one press, one release and one fast opposite press while watching both bits. Neither state may change without a new operator action.

A momentary button that sticks on can hold a pump or solenoid energized after the operator lets go. The hardware stop and the interlocks remain the machine's real stop; the screen is a command surface and an indicator, and it never takes the safety role. For how long a momentary write can hold its bit across scans, how many PLC scans an HMI momentary button bit stays on works the timing out.

Treat the trend as history while the delay lasts

The pressure trend that drew a straight line while the operator turned the screw, then caught up seconds later, is the redraw debt seen in a graph. While the panel owes seconds of drawing, the trend is history, and adjusting a pump against it overshoots the limit. Have the operator watch the pump gauge or the live PLC value, and bring the trend back into service once the button responds with the graphic.

Two limits set what a trend can deliver. A scan class's frequency sets how often data is scanned, and its offset sets how long after that the scan runs, which is documented in the scan-class literature for industrial data interfaces. And a configured rate cannot outrun the hardware feeding it: one scan-rate example sets tags to 200 ms against equipment that acquires every 300 ms, so the display never sees the missing 100 ms. Set the panel's update interval at or above the slowest tag's acquisition time, or the trend will smooth and stall no matter how light the project is. Once the panel is healthy, fit a multi-hour temperature trend on an HMI without scrolling and why an HMI trend graph will not update every half second cover the span and interval settings.

The fix in order

Recommendation: Time the touch, the PLC value and the graphic before changing anything. When the value lands within one or two scan cycles and the graphic moves more than 1 s later, leave the cabling and the PLC program alone, work in a saved copy, disable the suspect popup, and retime. Strip the popup's contents in groups until response matches the main screen again, restart the panel once if the slowness spreads across screens, and rebuild every switch with one command direction plus a separate PLC status object. Until the trend keeps pace with the gauge, run the screw adjustment on the gauge or the live PLC value.

The decision for each case in one line. PLC first, graphic seconds later: panel project. Graphic and PLC late together: link and controller. Delay still present with a one-button project after a restart: panel hardware, and that is when you call the panel vendor with your timing sheet in hand.

Questions