An HMI button sends a communications write to PLC memory, not a sample taken in the input scan. An input module that owns the same address overwrites the write; a write to a free internal bit holds steady through the logic scan because communications are serviced outside it.
A limit switch wired to an input card and a button drawn on an HMI panel do not reach the PLC the same way, and the difference decides which addresses your screen buttons may use. The switch is sampled into the input image at the start of the scan. The button issues a communications write that the CPU applies when it services communications. Share one address and the card wins every time; give the button its own internal bit and the value holds through the entire logic scan. This page sets out the scan order, the overwrite rule, the momentary timing, a worked example, and the addressing rule to carry into your next panel project.
Are HMI button inputs updated like hardwired PLC inputs?
No, an HMI button writes PLC memory through the communications service while a hardwired input is copied into the input image at the start of the scan, so the two can share one address and still behave in opposite ways.
The scan on a small controller runs in a fixed order: read the physical inputs into the input image, execute the logic, service communications and diagnostics, then update the outputs. That order is documented behaviour of programmable controllers, the IEC 61131 family covers the controllers and their programming, and each vendor's user manual prints its own servicing points. A hardwired input is handled in the first step: the module copies the field value into the image once per scan, and nothing else touches that address while logic runs. A panel button is handled in the third step: the CPU applies the panel's write when it reaches the communications window. Same bit, two write paths, two owners.
When does an HMI write reach the PLC logic?
The write is applied when the CPU services communications, a step that sits outside the logic scan in the documented order, so every rung of the next logic scan reads the same new value.
Three delays sit between the touch and the rung: the panel's tag update interval, the network, and the wait for the communications window. Panel software commonly polls on a fixed interval set near 100 ms, a local Ethernet write moves in about 1-2 ms, and the write waits at most one scan for the servicing point. Worst case with those inputs: 100 + 2 + 8 = 110 ms from touch to the first logic scan that sees it, about 56 ms on average (50 + 2 + 4). The poll interval moves the number most: set the panel to 250 ms and the worst case becomes 260 ms. A serial link adds tens of milliseconds per transaction.
What happens if an HMI button writes to a real input address?
The input module wins, because the module rewrites its point into the input image at every input scan, so a panel write to a module-owned address survives for less than one scan, and on a small controller that is at most about 1-10 ms, the range vendor data sheets list for this class.
The scan order explains it. The input image is rebuilt from the field devices before logic runs, so the panel's 1 is erased before any rung can rely on it, and a write that does land on a module-owned point survives as a pulse of one scan at most; this page follows how that one-scan pulse forms from an external software write. Some CPUs and protocols reject writes to input memory outright, which the controller and driver documentation state plainly.
How long does a momentary HMI button stay on?
As long as the finger stays down, because a momentary object writes 1 to the bit on touch and writes 0 when the finger lifts, so the on-time is the press duration, usually a few hundred milliseconds, never one scan.
That is the documented momentary behaviour: touch writes the active value, release writes the inactive one, and the object never holds the bit between the two. A hardwired maintained switch holds its state with no finger at all, which is exactly the difference this addressing mistake creates. If the machine action must persist after the finger lifts, the latch or seal-in belongs in the ladder logic on the panel's bit. For the scan-count version of the same question, see how many PLC scans an HMI momentary button bit stays on, including the cases where the bit outlives the press.
Why would the bit read on in one rung and off in another?
It should not happen, because communications are serviced in their own part of the scan, so a panel-written bit reads identically at rung 1 and rung 1000 of one logic scan, and a split reading points to a second writer.
The commonest second writer is your own program: two rungs that each carry a coil on the same bit, where the later rung erases the earlier one every scan, and this page works through that last-write-wins behaviour when two rungs drive one bit. A module point and a panel tag aimed at the same address create the same conflict at scan boundaries. Where the timing of a command matters, read the bit once at the top of the program into an internal working bit and run the logic on the copy, which freezes the value for the whole scan no matter who writes the original.
Which address should an HMI button write to?
A writable internal bit in the controller's data area, one bit per command, since internal bits carry no field device behind them and the panel stays the only writer until your logic deliberately changes the value.
Before assigning it, confirm in the panel driver's documentation that the memory type accepts writes; driver manuals mark read-only areas. Keep three classes apart: input image addresses for module points, command bits in the data area for the panel, and working bits for the logic. Where a field switch and a screen button both represent the same operator request, give each its own address and OR the two bits in one rung, which keeps the source of every command visible during troubleshooting. The same ownership rule explains why an HMI toggle cannot force a physical PLC input.
Worked example: what does a screen button on input X0 do in an 8 ms scan?
Dead on arrival: written between scans and erased by the module at the next input scan 8 ms later at the latest, the command never satisfies a rung that needs the bit held for 50 ms.
Label the example plainly: the wired sensor's point is called X0, the spare internal data bit B10, and the numbers are illustrative inputs for a small controller: scan period 8 ms, panel poll interval 100 ms, Ethernet transfer 2 ms, press duration 300 ms, and a cycle-enable rung that needs the command bit true for 50 ms on a timer.
Wrong wiring, button aimed at X0: the panel's write lands in the communications window, and the next input scan restores X0 to the sensor's off after at most 8 ms. The timer rung accumulates at most 8 ms before the bit drops and the timer resets. 8 < 50, so the enable never fires, every press behaves the same, and the button looks broken.
Correct wiring, button aimed at B10: the write holds for the whole press. The bit reaches logic about 56 ms into the touch on average (50 + 2 + 4), worst case 110 ms, and the timer then needs 50 ms more, so the cycle enables about 106-160 ms after the touch. 300 > 160, so the operator always feels the response before the finger lifts. Decision: readdress the button to B10 and leave X0 to the sensor; the hardware was never at fault.
How do I find every writer of one bit?
Run the cross-reference on that address in your programming software, because the listing of every instruction that reads or writes the bit catches the second writer fastest: an input module's point, a coil on another rung, a recipe write, or another screen object on the same tag.
Then check the panel side: open the project's tag list, search the address, and count the objects bound to it, because each one is a writer. The rule that falls out is one deliberate owner per address: module points belong to the module, command bits to the panel, working bits to the logic. When the suspect bit belongs to the panel's own physical keys, the causes sit on the panel side, covered in why an HMI function key bit stays on after a short press.
What is the decision for a screen full of buttons?
Point every button at a writable internal bit, leave input addresses to the modules, and budget in milliseconds: a command arrives about one poll interval plus one scan after the touch and lasts exactly as long as the press.
Recommendation: assign one writable internal data bit per screen command and OR it with the field switch in ladder logic when both must trigger the same action. Write to an input-module address only where the socket is empty, no module owns the point, and the controller documentation permits writes to that input image. Read the scan order and the live scan time from the controller's status display first, then rerun the arithmetic above with your own numbers. Test any readdressed button with the machine in a safe state, because the first press that truly reaches the logic can start motion.
A panel that also shows shift notices, maintenance messages or andon-style status pages is doing a signage job next to the control job; our shop-floor signage covers that screen separately.
Questions
Can I use a screen button to force an input while troubleshooting?
No. Forcing is a function of the programming software, with its own commands and a visible status flag, and it is the documented way to override a physical point during a bench test. A panel write aimed at a module-owned address is different: the next input scan erases it. Use the software's force functions, note them in the program, and remove them before the machine returns to service.
Do serial and Ethernet panel connections change any of this?
The ownership and overwrite rules are identical on both. Only the transport delay changes: a local Ethernet write moves in about 1-2 ms, while a serial link at 9.6 or 19.2 kbit/s adds tens of milliseconds per transaction, so the latency sum grows but the addressing decision stays the same.
What scan time should I plug into the latency sum?
Use the figure your controller reports while running. Most programming packages show current, minimum and maximum scan time in a live status view, and the maximum is the right number for worst-case timing because the write waits for the communications service point that follows the longest scan.
Does a screen toggle button behave differently from a momentary one?
A toggle reads the bit first and writes the opposite, so it depends on the value it reads being current. With a slow poll the read can be stale and the write can land on a state another writer has already changed.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.