HMI reads the PLC but cannot write: how to prove why

What each symptom points to

These are the signatures, and the check that follows each one:

• Reads stay live, but an entry never takes. A rung is writing that same address on every scan and reasserting its own value. Go straight to the spare-address test below.
• The programming software changes the address, and the panel never can. The CPU accepts writes at that address, so suspicion moves to the panel: the object's write configuration, or the CPU's live protection status.
• The button never changes color, and the lamp stays dark. The lamp may be watching a different bit than the button writes, or something resets the bit the instant it sets. Watch the raw address in the data table; color on a graphic is the last witness to trust.
• Both error logs are clean. A write that logic overwrites completes without an error, and a write that never sends raises none, so clean logs fit all three causes. That is exactly why the test below watches the address and skips the logs.
• The same objects behave in simulation. A simulation answers its own writes on the PC and never touches the PLC, so a passing run says the screen layout is plausible and stops there.

One neighboring case stays outside this test: when the panel reports a write error, the failure has already announced itself, and the article on fixing HMI write errors when PLC reads still work walks that path, key switch first. This article is for the quiet version, where both logs stay clean.

Check the CPU protection status first

Start with the cheapest check. The protection setting visible in the project describes the file on your laptop; the CPU carries its own protection state, and a panel inherited from a previous stage of a project is exactly where the two stop matching. Read the controller's live status in the programming software:

• Machine Edition: Target > Online Commands > Show Status > Protection
• Logicmaster: F3 (PLC Control & Status), then F2 (Password Protection)
• VersaPro: SHIFT + F4 opens the status window, then read the Protection tab

If the CPU reports protection on while the project says otherwise, clear it through the programming software's documented protection commands, from the station that holds the source project. Protection is the first suspect for writes that never appear, and the status view convicts or clears it in a minute.

Many PLC CPUs hold two connections at once, so the software can watch the data table while you press the button on the panel. If yours allows one connection at a time, write from the panel first, then connect and read the spare address: an address no rung writes keeps whatever it was handed, so a late read still separates a stuck write from a missing one.

Run one write test on a spare address

1. Pick a spare internal address. One spare %M bit and one spare %R register. Search the ladder for each address and confirm that no rung writes it and that no machine action hangs off it. Keep the test on internal coils and registers; a physical input point is a different animal, and the article on why an HMI toggle cannot force a PLC physical input explains that wall.
2. Point the problem object at the spare. For a numeric entry, retarget its write tag to the spare %R register. For a pushbutton, leave the production button alone and build a temporary toggle object on the spare %M bit. A toggle takes press-and-release timing out of the measurement, including the 1 second delay on release the production buttons carry.
3. Open the raw data table. Keep the programming software online with the reference view showing the spare address and, a few lines down, the original one.
4. Write once from the panel and watch for 30 seconds. Enter 12345 into the test entry, or flip the test toggle once, and note what the raw value does: nothing, a change that sticks, or a change that reverts.
5. Write once from the software. Put 12345 into the same register from the programming side and watch the panel's display pick it up. One write here clears the address, the CPU and the cable together.
6. Undo the test. Repoint the entry, delete the toggle, and restore the values you found.

The shape of the whole test follows one rule: every check must leave a result that convicts a single cause, which the page on industrial troubleshooting that proves a cause with each test argues in more depth.

What the three outcomes mean

For the reverted write, scan speed is the reason it looks like nothing happened. A small PLC program typically scans in 1 to 10 ms, so a rung that writes a coil on every pass reasserts its value 100 to 1000 times a second: at a 5 ms scan, 1000 ms ÷ 5 ms = 200 rewrites per second. A valid one-shot panel write to a logic-owned address survives less than one scan, which looks identical to a write that never left the panel. The spare address splits the two cases, because no rung fights you there. The scan-timing details are in the article on HMI button writes versus the PLC input scan.

For the missing write, work down two places: the protection status you read above, then the object itself. Confirm the entry has a write tag at all, and that the tag's operand type matches the memory you mean; the article on the HMI thumbwheel with the wrong address type walks that trap on entry objects. A common setup uses one tag for both display and entry on a numeric object, and that setup only writes if the object is configured as an entry with a write destination.

For the stuck write, the panel, its object and the path are all good, so the fault lives at the original address. Search the ladder for every rung that writes it, condition that write to a command window, or move the operator command to a spare bit no logic touches.

Recommendation: run the spare-address test before you edit anything. Enter 12345 into a spare %R register from the panel, watch the raw value for 30 seconds, and let the result pick the room: a stuck write sends you into the ladder, a missing write into the status view and the object, a reverted write to the rung that owns the address. One test, then one edit, in the right place.

Example: a start button that never lights

A 15-inch panel runs a small motor line. The %R registers stream motor speed and load to the screen and the numbers move, so the read path looks healthy. Start and stop are momentary pushbuttons writing %M coils, each with a 1 second delay on release, and a lamp on the screen shares each bit. Pressing start does nothing: no color on the button, no motor, no entry in either error log. The same objects pass in simulation. From the programming software, toggling the same %M bit starts the motor and the lamp follows it, so the coil, the rung and the machine all respond.

The status view reports protection off, matching the project, so protection is out. A spare %M bit with no write references gets a temporary toggle; flipping it from the panel leaves the raw value at 0 after 30 seconds. The numeric test entry is retargeted to a spare %R register; 12345 entered from the panel never appears in the data table. One write of 12345 from the software lands instantly, and the panel's display shows it, so the cable, the driver and the CPU are all fine. Verdict: the panel's writes never leave the screen.

That verdict points at the objects. The tag database shows the cause: the numeric entries carry a display tag only, and the pushbuttons were drawn with the write tag left empty. The screen reads everything and writes nothing. Each entry gets its write tag set to its own register, each button gets its bit, and the test repeats: 12345 into the spare register now sticks for the full 30 seconds. The production screens go back to momentary buttons with their 1 second release delay, and the next start press lights the button and the motor.

Keep the test off the production logic

Two habits keep this test cheap and safe. Put every test write on a spare address with no rung and no machine action tied to it: a path test on a live start circuit can start a motor, so the test bit stays unwired and unwritten by choice. And keep the operator's command separate from the logic's state: give the operator a command bit the ladder reads and clears, and let the ladder own the state bit the screen displays. An object that writes a bit the logic also writes fights the scan on every pass, and the scan wins. When the diagnosis is done, delete the toggle, repoint the entries and put the momentary buttons back before the shift ends.

Questions