Watch the PLC tag, not the button graphic. If the tag holds one value while the graphic cycles, the machine logic is cleared and the fault is on the panel: a window overlaid on the button stealing focus, or input and display timing in the task configuration. Clear the overlay first, then set one timing at a time.
A touch button that keeps animating after your finger leaves the glass, while the PLC variable behind it holds steady, is a panel-side fault. The observation you already have clears the program: the value is stable, so the machine logic is out of the loop. What cycles is the panel redrawing the button object, and four things produce that. An input task interval set too high or too low. A display update interval running too fast for the task. A PLC task that takes longer than its configured cycle. Or another screen or window drawn over the button, stealing its focus mid-press. Here is the check order, the numbers to set, and the decision for each outcome.
What each symptom points to
A button graphic tracks two things: the touch on the glass and the tag behind it. How PLC-driven HMI graphics represent equipment states covers the tag side of that pairing; the touch side is where this fault lives. Match what you see before you change a setting, because each row below leads to one fix.
- Tag flat, graphic cycles after release. Panel-side redraw. Work the overlay first, then the timings. The program needs nothing.
- Cycling on quick taps only, clean on a 2 s hold. The input task interval is too coarse. A quick tap can start and finish between two samples, so the release edge is caught late.
- Cycling on every press, with nothing overlapping the button. Display update interval too fast for the task, or the PLC task running past its configured cycle.
- Cycling starts the instant a pop-up, alarm banner or screen change appears. Focus loss to the overlaid window. Screens that raise alarms while an operator holds a control are the classic case.
- The tag repeats or toggles on a single press. The fault is in the write path: the button action, or another instruction writing the same tag. Calling a method from an HMI button with ST code covers that configuration, and the display settings are the wrong place to look.
Watch the tag, then clear the overlay
- Open the tag monitor in the programming environment and leave it on screen. Press the button once, hold about 2 s, release, and record the value before, during and after. One press, one release, no repeats: the program side is finished and you close the logic editor.
- Watch the screen during the press. Anything drawn over the button at that moment is a suspect: a pop-up, an alarm banner, a screen change. A button that also navigates screens is the classic case, because the new screen races the release; the checks in fixing HMI function key screen navigation cover that pattern.
- In a test copy of the screen, move the button clear of the window, or hold the window back until the release is done. Press again with the monitor open. If the cycling stops, fix the layering on the live screen and you are finished; skip the timing work.
If the overlay is a window you built, give it its own ground. The guidance under building an HMI pop-up screen window keeps a pop-up inside a defined area instead of over the control row. The same chain reaches PC runtimes: focus stealing from pop-ups in automation software describes windows that take input focus from the screen the operator is using, and a double-click focus fault on a pop-up screen is the same failure on a specific engineering platform.
Set the timings, one change per press test
Timing work comes after the layering check, and it is one setting per test. Two intervals matter, both in the task configuration.
The input task interval owns the press and release edges. Set it to the runtime's documented default; where you must choose, use the 10 to 20 ms band typical of HMI input tasks. A slow interval is the more common error: at 200 ms the task samples the touch five times a second, and a quick tap can start and finish between two samples.
The display update interval owns the redraw. 100 ms, ten redraws a second, is plenty for a button. Faster redraws cost task time and buy nothing an operator can see on a pressed graphic.
Make both changes with the machine in a safe state: lengthening an interval slows every reaction wired through that task, and a start command is exactly such a reaction. After each change, run the same press, hold, release, with the monitor open, and write down what the graphic did.
Check the task is meeting its cycle
The third cause crosses into the program: the task that serves the screen runs longer than its configured cycle, so the visualization waits on every exchange. Open the task monitor and read the measured cycle time against the configured interval. Measured above configured is an overrun. A task configured at 20 ms and measuring 60 ms is over by a factor of three, and no display setting clears that. Fix the logic that runs long, or lengthen the interval until the measured value sits under the configured one. To find which layer of the program owns the time, trace PLC execution order across task layers.
Example: a 400 ms press on a 20 ms input task
An operator panel on a packing line runs its input task at 20 ms and its display update at 100 ms. A sensor bit raises an alarm pop-up that opens over the start button. The operator holds the button for 400 ms.
- Input samples during the hold: 400 ms / 20 ms = 20 samples. Both edges, press and release, are caught cleanly.
- Redraws during the hold: 400 ms / 100 ms = 4 frames of the pressed graphic. The first unpressed frame follows within 100 ms of the release. One down, one up: correct behavior.
- The pop-up opens 200 ms into the hold, on top of the button. The button loses focus mid-press, and when the pop-up clears the object redraws its state. The operator sees two more down-up cycles with no finger on the glass. The tag monitor shows exactly two transitions the whole time, one for the press and one for the release.
- The fix is layout, not timing. The pop-up moves to a banner strip at the top of the screen, clear of the control row. Retest: 20 samples, 4 frames, one down-up, two tag transitions, finished.
The decision for each case
- Tag flat and a window over the button: move the window or the button. No timing change.
- Tag flat, nothing overlapping: input task to its documented default in the 10 to 20 ms band, then display update to 100 ms, one change per press test.
- Measured cycle above the configured interval: fix the overrun in the logic, or lengthen the interval until the measured value sits below it. Display settings will not clear an overrun.
- Tag repeating on one press: configure the button's write action first, then retest.
Recommendation: with the tag holding steady through the press, leave the PLC program alone and work the panel side. Clear anything that appears over the button while it is pressed; if the cycling continues, set the input task to its documented default and the display update to the 100 ms redraw rate, one setting per press test. A tag that starts repeating is a different fault, and it belongs in the button's action configuration.
Questions
Can a button animate when the PLC tag never changes?
Yes. The panel draws the pressed look from the button object itself, and the tag write is a separate configured action, so the graphic can cycle while the value holds. You can show the split in about a minute: force the tag from the programming environment and watch which objects move with it. A button that ignores the forced value takes its pressed look from touch, and that is the side at fault.
Is a cycling button a failing touch panel?
Put hardware last. A worn touch controller usually produces phantom presses with no finger near the glass, and the trouble follows screen position, so it shows on more than one object. Cycling locked to a single button, which needs a real press to start, is a software pattern. If your runtime has a touch test or calibration page, run it once for a hardware data point before you plan a panel swap.
Which interval do I change first, input or display?
Input, because every test after it depends on clean press and release edges. Set the input task to its documented default, in the 10 to 20 ms band on current runtimes, and rerun the press test. Then set the display update to 100 ms. If the graphic settles within one update period after that, what remains is redraw lag: a slightly late release frame, harmless on a button.
How do I keep this off the next screen I build?
Four rules. Never place a pop-up or banner over an active control. Keep alarm banners in a strip of the screen with no buttons under them. Set the input task interval once, at project start, in the 10 to 20 ms band, and leave it. Give each button one write per press. Screens built that way keep focus where the operator put it.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.