A momentary HMI button turns its PLC bit on when the press message lands and off when the release message lands, so the bit spans the whole touch plus up to one communication cycle and is on for at least one full scan. Treat the panel bit as a request: fire a one-shot instruction from it inside the PLC and use the one-shot's own one-scan bit downstream.
Press a momentary button on an HMI touch panel and its bit turns on in the controller when the panel's next message lands, not when a scan begins. It turns off when the release message lands. The bit stays on for the whole touch plus communication time, and the floor is one full scan of the logic however short the tap. That timing settles how the logic must be built: the panel's bit is a request, not a pulse. Fire a one-shot instruction from it inside the controller and use the one-shot's own bit everywhere else. This page walks through the timing, the failure the raw bit causes, and a worked press.
The answer: the bit follows the touch, not the scan
A momentary button writes its bit to 1 while the operator touches it and back to 0 after release. Both writes travel the panel's communication link, so each lands within one update cycle of the finger event, and neither lines up with the scan. Plan on the bit being on for the whole touch, and count on at least one full scan as the floor.
That number, one scan, is what separates a screen command from a wired input. A wired input is sampled by the scan; a screen command arrives as a message. The on and off mean the same thing; the timing is different.
While the finger stays down, the panel holds the command on at its own update rate. Some panel projects also set a button to repeat its write while held, which is a setting of the panel, not of the controller; Make an HMI button repeat a setpoint on press and hold covers that case.
What one scan means for a screen command
The controller reads inputs, runs the logic from top to bottom, writes outputs, and starts the next pass. That pass is the scan. A screen write lands when the controller services the link, which sits outside that rhythm, so the pass that first reads the bit may already be partly run. The safe figure is the floor: at least one full scan, and in practice the whole touch.
Small controllers running short programs commonly scan in single-digit milliseconds up to a few tens; the worked example below uses 10 ms. The panel's update period is set in the panel project and is usually much slower than the scan; the example uses 100 ms.
Because the command waits on a message, a screen button is the wrong device for anything that must stop motion quickly. Stops and safety functions stay on hardwired inputs and safety hardware; screen buttons carry the commands where a scan or two of delay changes nothing.
Message timing on serial links has its own failure modes, and Fix dropped PLC-triggered messages on a serial HMI panel covers the write side of that problem.
Why resetting the panel bit in logic fails
The tempting move is to clear the panel's bit at the top of the program so the rest of the logic sees a short pulse. Two things break.
The clear does not stick. The panel owns that address while the finger is down, and the next update writes the 1 back. Logic after the clear sees the bit on again for every remaining scan of the hold.
Borrowing the address as the one-shot's own bit corrupts the edge detection. A one-shot instruction sets its output TRUE for one cycle of the PLC scan, and its edge memory lives in that output bit. Let a panel write the same address on its own schedule and the edge detector chases false transitions.
Two rules fall out: a one-shot triggered by the panel's bit will not clear the panel's bit, and the panel's address must never be the one-shot's output address.
The pattern: a request bit and a pulse bit
Give the design two addresses. The button keeps its own request bit, exactly as the panel project defines it. In the controller, a one-shot rung takes the request bit as its input and writes a separate pulse bit of its own. Downstream logic reads only the pulse bit.
The pulse bit is TRUE for one scan cycle, so one press yields exactly one true scan however long the hold. Place the one-shot rung above the rungs that use the pulse bit, so those rungs read the pulse in the same scan it is set; a rung placed before the one-shot sees nothing on that scan.
This request-and-pulse split is the working pattern for buttons on shop-floor screens and andon-style boards. Two related traps sit next to it. Edge logic re-fires on every new rising edge, and a release that bounces makes one, which Why an HMI touch button bounces after release covers. And a one-scan pulse is invisible to a screen that polls slower than the scan, its own trap: Why an R_TRIG pulse never shows on the HMI screen.
Mnemonics differ by controller: PD on some, ONS on others. The abbreviation alone does not fix the duration or reset rules, so read the instruction help for the controller in front of you before relying on it.
Recommendation: give every momentary screen button its own request bit, fire a one-shot from it near the top of the program, and write all downstream logic against the one-shot's pulse bit. Use the raw request bit only where you want the action to last as long as the touch, and never for a stop function.
Example: a 300 ms press against a 100 ms update and a 10 ms scan
The inputs, and where each comes from:
- Hold time 300 ms: an ordinary deliberate press. Example input, chosen for this case.
- Panel update cycle 100 ms: example input. The real value is the update period set in the panel project.
- PLC scan 10 ms: example input and the planning figure from the timing section above.
- The floor of one full scan is the practice rule the result is checked against.
The rule in words: the request bit turns on when the press message lands and off when the release message lands, and each message lands within one update cycle of its finger event.
The arithmetic:
- The touch runs from 0 ms to 300 ms.
- The press message lands between 0 ms and 100 ms.
- The release message lands between 300 ms and 400 ms.
- Shortest on-time: 300 ms - 100 ms = 200 ms. Longest: 400 ms - 0 ms = 400 ms.
- Scans on at a 10 ms scan: 200 ms / 10 ms = 20 scans, and 400 ms / 10 ms = 40 scans.
Result: the request bit is TRUE for 20 to 40 consecutive scans, against a floor of 1.
Decision: any rung that acts while the request bit is on acts once per scan, so a tally fed by the raw bit adds 20 to 40 counts for this single press. The same tally fed by the pulse bit adds exactly 1. Since the raw bit always spans at least one scan at any hold length, every once-per-press action gets the pulse bit, whatever the press length.
Prove it before you trust it
Watch both bits with the controller online and run one hold and one tap.
- Press and hold for 2 s, then release. The request bit is TRUE through the hold, about 200 scans at a 10 ms scan, and clears after release. The pulse bit is TRUE for exactly one scan at the leading edge.
- Tap shorter than one update cycle. The pulse still fires once, off the rising edge of the request bit. If fast taps skip the pulse, re-read the button's action setting in the panel project before touching the logic.
- One bench test separates momentary from set behavior. With the button held down, open the panel-to-controller link on a bench panel: a set-style bit latches and stays TRUE, while a momentary command clears. Never open the link to a screen a running machine or an operator depends on; do it on a bench or a non-production screen, with the machine isolated and under the site's change procedure.
If the bit stays on after release with no finger near the panel, the button's action setting is the first suspect: a toggle or set action stays on by design, and only a momentary action clears with the touch.
Questions
Does the bit stay on longer if the operator holds the button?
Yes. The bit clears only when the release message lands, so the on-time grows with the hold. A 3 s hold against a 100 ms update cycle and a 10 ms scan keeps the request bit true for roughly 290 to 310 scans, about ten times the 300 ms example press. The one-shot pattern caps the action at one scan however long the hold.
Two screens write the same bit. What does the second operator see?
Panels both write and read back the addresses in the controller, so a press on one screen shows the button as pressed on the other screen while the bit is on. If two operators must press independently, give each button its own request bit and OR the request bits into one one-shot rung.
Does a maintained or toggle button change any of this?
A toggle writes its new state once per tap and the bit stays there until the next tap, so the raw bit is already a state and needs no one-shot. The message timing still applies: the new state reaches the logic within one update cycle of the tap, so a toggle command also waits out one update period.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.