HMI switch mirrors a PLC bit and toggles by itself

Why does an HMI switch toggle by itself after one tap?

Because the switch and the PLC bit are mirroring each other: two procedures copy the switch into the PLC bit, two more copy the PLC bit back into the switch, and one stale copy re-triggers the opposite write. The switch sits in the panel's internal memory so the graphic answers the touch instantly, and the copies were added to keep it in step. Every copy fires on a change, so one change fans out to the other side. The panel reads and writes on cycles you set, so a copy can act on a value read before your latest write landed. That stale value is the opposite of your last command, and writing it re-triggers the other side. A slow tap leaves time for the copies to settle, which is why the fault shows up after a quick on and off and hides during careful testing.

Which symptom points to which cause?

Match what you see against the five cases below before you change anything: repeated movement with no tap is the mirror loop, and the other patterns point at a lost release, a slow link or a late answer.

• The switch moves after you let go. A stale feedback copy applied a read that started before your write landed. Watch the copy that writes the switch while you tap once.
• The switch and the machine bit alternate several times after a quick on and off. The reciprocal copies are echoing each other, each copy re-triggering the opposite one. Disable the copy that writes the switch and run the same tap test.
• A momentary button's bit stays at 1 after release. A momentary press is two writes, and the release write was lost. Have the PLC consume request bits after one scan, and a stuck command loses its effect.
• The machine answers late but the switch moved promptly. The delay sits in display refresh or communications on the indication path, and the PLC has usually already acted. Compare the bit change and the screen change within one toggle.
• Unrelated tags lag or drop out at the same time. The link or the project load is the bigger problem, with the loop as one contributor. Run the panel's communications diagnostics before touching the project.

How do I prove which side is echoing?

Watch the switch's internal value and the PLC bit in two separate windows, toggle once, and write down the order they move in; the side that moves second without a tap is the echo.

1. Make the test tap harmless first: run it on a bit that drives nothing, or with the machine stopped.
2. Back up the HMI project and the PLC program.
3. Open the live value view for the switch's internal tag and the PLC bit side by side, toggle once, and record the order they move in.
4. Disable the copy that writes the switch from the PLC side, download, and toggle once. If the repeat switching stops, that copy is the echo path.
5. Restore it and disable the opposite copy instead, so one path changes at a time; with both removed you can hide the cause and the control function together.
6. If the alternating survives either single change, hunt the second writer: another screen or popup with its own switch to the same bit, or PLC logic that writes the bit directly.

What does one racing tap look like in a worked example?

With a 50 ms write latency, a 10 ms PLC scan and a 150 ms status read, one tap in three races, because a read issued during the 50 ms a write takes to reach the PLC carries the old bit value.

These are example values, picked to show the shape: the panel needs 50 ms to land a write in the PLC, the PLC scan is 10 ms, and the panel refreshes its status read every 150 ms. Call the machine bit C1, leave both mirror copies in place, and tap ON once.

• t = 0 ms. The switch flips to 1 and the switch-to-PLC copy queues C1 = 1.
• t = 30 ms. A status read goes out before the write lands, so its reply still carries C1 = 0.
• t = 50 ms. The ON write lands, and the scan at t = 60 ms runs it: 50 ms + 10 ms = 60 ms from tap to C1 = 1.
• t = 60 ms. The stale reply arrives and the PLC-to-switch copy applies C1 = 0: the switch flips back to OFF with no tap. That flip fires the OFF copy, which queues C1 = 0.
• t = 110 ms. The OFF write lands and the scan clears C1. The machine bit ends OFF when you pressed ON.
• t = 180 ms. The next status read samples C1 = 0 and leaves the switch at OFF. One tap has shown ON then OFF on the screen and left the machine in the wrong state.

The arithmetic that matters: the race window is the write latency, so 50 ms against the 150 ms read cycle puts one tap in three in the race, which is why the fault looks random. Widen the read cycle to 300 ms and the same window catches 50 ÷ 300, or 1 in 6 taps. Cut the write latency to 20 ms and 20 ÷ 150 drops it to 13 taps in 100. The share moves with your numbers and the direction never does: every race applies the opposite of the last command.

How do I fix it so the switch never toggles itself again?

Split command from feedback: the switch writes one request bit and nothing else, the PLC owns the machine bit and clears the request after one scan, and the screen's indication reads the machine bit without writing to it.

1. Delete every procedure that writes the switch from the PLC side. Keep none as a temporary measure: the copy is the echo path.
2. Point the switch's write at a request bit that only PLC logic consumes, the same command-bit arrangement as in make an HMI button turn on a PLC output through a command bit.
3. In the PLC, set the machine bit from the request behind your interlocks, then clear the request after one scan, so a lost release write cannot leave a command stuck at 1.
4. Bind the switch's resting color to the machine bit as a read-only indication, so a PLC-side change shows within one read cycle and fires no write.
5. Download and test three cases: a single tap, a fast double-tap, and a PLC-driven change of the machine bit while the screen is open. The indication follows, and the switch moves only when you tap it.

If operators still double-tap faster than one update cycle during a migration, a delayed write commit timer for HMI switch presses handles the fast-tap queue on its own terms.

Recommendation: Give each operator command its own request bit, let the PLC own the machine bit, clear every request after one scan, and leave nothing on the PLC side that writes the switch. Keep an internal-memory switch with mirror copies only while you migrate an old project, and only while the PLC consumes each request within one scan; the moment any other logic can change the machine bit, remove the copies.

When can an internal-memory switch stay?

It can stay as a display trick only where the PLC consumes the request within one scan and nothing writes the switch from the PLC side; drop it the moment the PLC can change the machine bit on its own.

You can keep the fast feel in the clean design: animate the switch on the touch itself, bind the resting color to the machine bit, and the operator sees the press at once and the machine state one read cycle later. What internal memory can no longer do is hold a second copy of the machine state. With no other writer to the machine bit and a one-scan acknowledge, a mirrored pair limps along; the first PLC-side writer, a second panel or an added interlock turns it back into a self-toggling switch. Build the request pattern once and skip that stage.

Is this a sign of too many buttons or a weak screen?

No: the echo comes from the mirror copies you wrote, and the same arrangement reproduces on any panel, so trimming the screen will not fix it.

Slow screens attract the blame because the panel got slower as the project grew, but the two lags have different homes. If the one switch is slow while every other tag stays current, the lag is in that object and its copies.

If unrelated tags lag or drop out too, run the panel's communications diagnostics, and time the project again with the copies removed: every bounce is extra writes and reads on the wire, so an oscillating loop loads the link on top of everything else.

A minimal test screen with one switch and one indicator tells you what the panel can do; with the copies still present it only measures the loop again. A switch that misbehaves only after power up is a different fault, covered in why an HMI toggle switch resets at PLC power up. Judge screen speed only after the copies are gone; a speed problem that survives that test is a real capacity or communications question.

Questions