PLC in TERM but HMI will not write: cycle the mode switch

Why does the panel say connection accepted but the PLC never answers?

"Connection accepted" only means the panel software linked its switch object to its driver; it is not evidence the PLC answered, and on a brick PLC with the switch in TERM the slave port answers once a TERM-RUN-TERM cycle has left the RUN light on.

The accepted flag lives inside the panel application. It confirms the object link was built and says nothing about the cable, the port, the protocol or the state of the PLC, which is why the same installation can show an accepted link and a dead output at the same time. The check that matters sits at the other end of the cable: does a value in the PLC change when you operate the switch? The basics of what the TERM position does for panel communications are in PLC mode switch TERM: panel communications and RUN restart; this article stays on the accepted-but-silent case.

Which symptom points to which part of the link?

Match the symptom before changing anything: a link accepted with no PLC change points at run state or protocol, a dark RUN light points at the PLC itself, and a C bit that changes while the output LED stays dark points at missing ladder logic.

• Link accepted, nothing changes at the PLC. The panel never got an answer. Do the mode-switch cycle in the next section first, then check the driver values against the port.
• RUN light off. The PLC is not running its program. Sort the run state before judging the panel; writes that stop right after a program load are the classic sign.
• The programming package connects, the panel does not. The cable and the port are alive. The panel driver is speaking the wrong protocol, station number or parity, or it is pointed at a port whose settings do not match it.
• The C bit changes, the output LED stays dark. The write works and the mapping does not exist yet. Add the rung shown in the worked example.
• Writes worked yesterday and stopped today. A program load or a switch move changed the run state. Run the cycle again and watch the light.

Each cause has a test that separates it: the light separates run state from everything else, the data monitor separates a working write from a missing rung, and the driver's numbers separate a matched port from a mismatched one.

How do you cycle the mode switch so the panel writes land?

Move the physical switch from TERM to RUN and back to TERM, then confirm the RUN light is on before you retry; with the light on and the switch in TERM, the port on this class of brick PLC accepts the panel as a slave.

1. Note the switch position and the state of the RUN light.
2. Move the switch from TERM to RUN.
3. Move it back from RUN to TERM.
4. Read the RUN light. The light is the confirmation, so take the state from the light.
5. Operate the test switch on the panel and watch the target address at the PLC, as the worked example shows.

If the RUN light is still off after step 3, stop the communications work there. The PLC is not running, and no driver setting will change that; load the program, put the PLC in RUN from the programming package, then start this section again.

For a bench test of one switch writing one C bit, the cycle alone is the fix for the accepted-but-silent case. No new logic and no programming session are needed until the target is a physical output.

What serial settings does the panel have to match?

On this class of brick PLC the 6-pin RS-232C port is fixed: 9600 baud, odd parity, station address 1, 8 data bits, 1 start bit and 1 stop bit, asynchronous half-duplex DTE, so those are the values you enter in the panel driver.

The port picks its protocol automatically from the master in front of it and works as a slave only, offering K-sequence, DirectNET and Modbus. Enter whichever the panel driver expects and leave the station number at 1. A panel on the second port is a different job: that port is configurable, so set it to match the driver and read its values from the PLC setup instead of copying the fixed port. In the common programming package the path is PLC > Setup > Setup Sec Comm Port, and it covers the second port only; the fixed port has no settings screen because it has no settings. Connect an HMI to a PLC port with fixed serial settings walks that setup in detail.

Parity is the first suspect when a configurable port goes quiet after its serial settings were changed, because the failure looks like a dead link on a good cable; why Modbus RTU links fail on even or odd parity covers that symptom.

Why can a panel not switch a physical output directly?

A panel write on this class of PLC lands on internal coils, the C bits such as C100, and ladder logic has to carry that bit to the physical output such as Y1; the panel cannot drive an output terminal or force a physical input on its own.

The panel package's documentation shows a direct form such as DL1.Y1 = Switch 1, and a connection in that form is worth trying as a one-off write test. For anything that stays, use the C-bit route: internal bits are what a panel is meant to actuate, and the ladder rung is what turns the bit into an output. Keep the two checks apart on the bench too, because a lit output LED is evidence of the completed logic and output path, while a changing C bit is evidence of the panel write alone. For the input side of the same rule, see why an HMI toggle cannot force a PLC physical input.

What does the worked example look like?

Bench case: a brick PLC with the switch back in TERM and the RUN light on, a panel driver at 9600 baud, odd parity and station 1 writing coil C100, one rung from a C100 contact to a Y1 coil, and the output LED follows the switch.

The ladder is two rungs:

C100 --| |--------------( Y1 )

( END )

The C100 contact drives the Y1 coil and the END rung closes the program so the scan reaches its end. Enter the rungs, load the program, put the PLC in RUN and confirm the light after the mode-switch cycle.

Size the panel's response timeout from the port speed so a silent link is called out quickly. At 9600 baud one bit takes 1 / 9600 s = 0.104 ms, and this port sends 11 bits per character (1 start, 8 data, 1 parity, 1 stop), so one character takes 11 x 0.104 ms = 1.15 ms. A short Modbus RTU write of one coil is 8 bytes, so the command takes 8 x 11 bits x 0.104 ms = 9.2 ms on the wire and the matching reply costs about the same, roughly a 20 ms round trip plus the PLC's turnaround. Set the timeout at 500 ms, well above a healthy exchange, and treat a timeout with no C-bit change as the PLC never answering.

Watch C100 in the programming package's data monitor on the second port if the hardware has one, or read the bit back from the panel itself. The result separates cleanly: C100 changes and the Y1 LED comes on means the whole path works; C100 never moves means the failure is in front of the ladder, in the run state or the port values; C100 changes while Y1 stays dark means the rung is missing or the loaded program is not running.

When does the problem turn out to be something else?

If the RUN light stays off through the cycle, or the link runs on Port 2, the fix moves from the switch to PLC state and port settings; a fixed port has nothing to tune, so silence means a mismatched value.

Bring the path back in this order so a later check cannot hide an earlier failure:

1. RUN light on after the TERM-RUN-TERM cycle, switch left in TERM.
2. Driver values against the port: 9600, odd, station 1 on the fixed 6-pin port, matched values on a configurable port.
3. Test switch operated and the target C bit watched at the PLC.
4. Rung and END present in the loaded program, PLC in RUN.
5. Output LED following the switch.

Keep the machine in a safe state and the output load disconnected while you commission the write, because a link that starts answering energizes a real output the moment the C bit maps through; test writes before motion is the standing procedure.

If the PLC has a second port, leave it to the programming package's monitor and let the panel keep the fixed port, with the second port set to match the monitor session. A working monitor session is not a verdict on the panel's route, because the two masters can sit on different ports with different settings.

One boundary worth stating: an HMI panel is part of the control loop, and a signage screen neither replaces it nor does its job. If the cell also needs a standalone status or notice board that plays its own slides offline, that is a separate screen with a separate job, and our shop-floor displays are built for it.

Recommendation: Cycle the switch from TERM to RUN and back to TERM and retry with the RUN light on before you change any software setting; if the write then reaches the C bit while the output stays dark, add the C100-to-Y1 rung with its END rung, and keep panel writes on internal bits for anything the machine moves.

Questions