HMI to PLC serial timeout with a dead com light

8 min read · Published November 6, 2026

When the panel reports a PLC timeout and the PLC com light never flickers, the PLC is receiving nothing it recognizes. Prove the PLC first: a PC through the same adapter reading one data word at 9600 baud, 7 data bits, even parity, 2 stop bits closes out the PLC, adapter and port settings. Then loop the cable at pins 2 and 3, check the transmit voltage, and fix the unit number.

The panel reports a PLC timeout, and the com light on the PLC never flickers. Read those two facts together and you know one thing: the PLC is receiving nothing it recognizes as a frame addressed to it. Every wiring swap you have tried sits on the same three conductors, so it tests the same three wires twice. Split the fault on purpose: prove the PLC side with a known-good master, prove the cable with a loopback jumper, then fix the settings no cable change can reach. The numbers here are for a Host Link at 9600 baud, 7 data bits, even parity, 2 stop bits, the frame this class of compact PLC uses on its peripheral port.

What the dead light tells you

The com indicator on a PLC serial port flickers while the port exchanges data with another device, so it works as a receive indicator. A dead light while the panel polls means one of three things: the bytes never arrive, they arrive with framing the port rejects, or the port configuration discards them. The light cannot separate those three. The tests below can, in the order that costs the least.

Symptoms and what each points to

  • Timeout on every poll, light dead from the first second. The PLC receives nothing valid. The fault is the cable, the panel transmit path, or a setting that discards the frame: unit number, port mode, protocol driver. Work this article top to bottom.
  • Light flickers, panel still times out. The PLC sees traffic and declines to answer it. That points at addressing: the panel sends a unit number the PLC ignores. Record the number the PLC actually answers on, with the known-good master test below.
  • Light flickers, panel reports checksum or framing errors. Both ends are talking with different frames. Read the data bits, parity and stop bits back on both devices and make them match. The framing fixes are in HMI PLC timeout and invalid checksum errors.
  • Timeout only after minutes or hours of clean running. An intermittent conductor or connector. Flex each connector and each cable end while watching the light; a flicker on movement localizes the fault to that end.

On a Modbus RTU line the same split applies, and the address half of that diagnosis is covered in Modbus RTU master no reply and address errors.

Prove the PLC side with a known-good master

This test decides the whole job, so run it before touching the cable again. Power down before you unplug or reseat anything; serial ports on this class of PLC were not built for connecting or disconnecting under power.

  1. Power down. Take the panel cable off the adapter and confirm the adapter is seated on the PLC's peripheral port, with the programming cable off that port.
  2. Connect a PC to the same adapter with a cable known to work with it. Set the PC to the same frame, 9600 baud, 7 data bits, even parity, 2 stop bits, and read the settings back from the software.
  3. Power up and go online, watching the com light during the connect attempt. If the light stays dead in front of a known-good master, the PLC port settings are rejecting the traffic: set the port to Host Link with the same frame, following the port settings in the PLC's operation manual. PLCs of this class commonly apply serial settings only after a power cycle, so cycle power after every change and read the settings back before judging.
  4. Read one data word through the protocol. A value coming back closes out the PLC, the adapter, the port and its settings, and puts the fault on the panel side. Write down the unit number the PLC answers on; the panel must send exactly that number.

If the PLC will not answer a known-good master, stop there. No panel setting and no cable change helps until it does.

Prove the cable with a pin 2 to pin 3 jumper

The loopback jumper makes the panel talk to itself through the whole cable. On a DB9 wired as DTE per TIA-574, pin 2 receives and pin 3 transmits, so a jumper from pin 2 to pin 3 at the free end returns the panel's own bytes to it.

  1. Leave the adapter end of the cable unplugged. Jumper DB9 pin 2 to pin 3 at that free connector.
  2. Power the panel with polling active and watch its error display. A change from timeout to a checksum or framing error is a pass: the panel drives the line, both signal conductors carry data end to end, and the panel port receives.
  3. No change points to the panel or an open conductor. Go to the voltage check next.
  4. Remove the jumper and ring the three conductors with both ends unplugged: DB15 pin 2 to DB9 pin 3, DB15 pin 3 to DB9 pin 2, DB15 pin 5 to DB9 pin 5. Confirm no conductor is shorted to the shield or to another pin. An open signal ground on pin 5 gives a silent link even with both signal wires intact.
  5. Confirm the panel's transmit pin from its hardware manual, and that the conductor from it lands on the adapter's receive pin. Check the pin numbering against the connector face and confirm the DB9 gender: solder-cup connectors mirror the numbering, which is a routine way to build a cable exactly to plan and still have it wrong.

Check the panel transmit voltage

With the adapter end still unplugged and the panel polling, measure DC volts between the transmit conductor and pin 5 at the free DB9. A healthy RS-232 line idles negative, between -3 V and -15 V, and the reading moves while the panel sends. A steady 0 V means the port is not driving the line: the wrong port is selected, the protocol driver is not loaded, or the driver has failed. A fixed negative value that never moves means the driver is idle and polling is not running at all.

Settings wiring changes cannot reach

Setting What it must be How to confirm
Panel protocol driver The Host Link driver, not the panel maker's proprietary link driver Driver name on the panel's communication setup page
Serial frame 9600 baud, 7 data bits, even parity, 2 stop bits, identical on both ends Read back on both devices
PLC unit number The number the known-good master test recorded Panel's PLC address field, checked after a power cycle
Link mode Single link, one panel to one PLC Panel setup page, read back after a power cycle
PLC port mode Host Link, frame matching the panel PLC settings read back online

The proprietary link driver sends a frame set a Host Link port never accepts, so flipping between the two while the PLC stays in host mode changes nothing. The unit number works the same way: with the panel addressing unit 1 and the PLC answering on unit 0, the wiring can be perfect and the light still stays dead.

A panel polls a compact PLC through a peripheral-port adapter. The panel reports a PLC timeout on every poll, and the com light has never flickered. Both ends read 9600 baud, 7 data bits, even parity, 2 stop bits. The cable was made to the adapter's published mapping, the one rung in the test step above. Swapping the signal pins and switching link modes changed nothing, which is expected: both tests stay on the same three wires.

The line time first. One character carries 1 start + 7 data + 1 parity + 2 stop = 11 bits. At 9600 baud, 11 / 9600 = 1.146 ms per character. A 12-character poll frame takes 12 × 1.146 = 13.8 ms on the wire, and a reply of similar length puts the whole round trip near 28 ms. A 1 s timeout is more than 30 times the round trip, so line speed has nothing to do with this fault: the reply is missing, not late.

Test one: a PC through the same adapter, set to the same frame, reads one data word and gets a value. The com light flickers during the exchange, and the PLC answers on unit number 0. That closes out the PLC, the adapter and the port settings; the fault is in the cable or the panel.

Test two: jumper DB9 pin 2 to pin 3 at the cable's free end. The panel error changes from timeout to a checksum error. The panel drives the line and hears its own bytes back; both signal conductors and the panel port pass. Continuity rings on all three wires, ground included.

Test three: what is left is the address. The panel's PLC address field holds unit number 1. Set it to 0, power cycle both devices, and the timeout clears with the com light flickering at the poll rate. A write from the panel reads back online with the same value, and pulling the cable at the panel end for 5 seconds brings the timeout back until the connector goes home.

Verify before you leave

  • Power cycle both devices with the adapter and cable installed.
  • Confirm the com light flickers at the panel's poll rate. No flicker means the panel-to-PLC path is still open; go back to the voltage check.
  • Change one address from the PLC side and watch the panel show the new value.
  • Write a value from the panel, read it back online in the PLC, and confirm the two match.
  • Pull the cable at the panel end for 5 seconds: the timeout returns and clears on reconnect with no power cycle. How a master should behave across that drop and return is covered in Modbus master reconnect after an error.

Recommendation: work this fault in one order: known-good master, cable jumper, settings. If the PLC answers a PC through the same adapter with the same frame, stop working on the PLC and check the cable and the unit number; those two carry most silent links. If the PLC will not answer the known-good master, fix its port mode and frame first, because nothing on the panel side helps until it does.

Questions

How long should one poll take at 9600 baud with 7 data bits, even parity and 2 stop bits?

One character carries 11 bits: 1 start, 7 data, 1 parity, 2 stop. At 9600 baud that is 1.146 ms per character, about 873 characters per second. A short poll and a short reply together sit near 30 ms on the wire, so a timeout setting of one second is more than 30 times the round trip. A timeout always means no reply came, never that the line was slow.

Why does swapping pins 2 and 3 not rule out the cable?

Both directions of the pair travel the same three conductors, and both mappings share the same signal ground on pin 5. An open ground or a broken conductor stays broken whichever way the signal pins are crossed, so the swap repeats the same test with the same blind spot. The pin 2 to pin 3 jumper at the far end is the test that actually exercises the conductors and the panel port together.

Does a dead com light mean the PLC port hardware has failed?

Rarely, and you can rule it out cheaply. The light stays dead when the port receives nothing, receives garbage, or is configured to ignore what it receives, and the first two cover nearly every field case. The known-good master test separates them in one step: if the light flickers for the PC, the port receives fine and the panel side owns the fault. A port that stays dead for a known-good master with matching settings is the one case that points at the port or the adapter itself.

Can I run the loopback jumper with the PLC still connected?

No. Unplug the cable from the adapter first and jumper the two signal pins at that free end. With the PLC connected, its own transmitter drives one of those pins, and two drivers on one conductor make the panel's reaction unreadable. The jumper test works because the panel hears only its own bytes coming back.

Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.

Keep reading

Build your signAsk for a quote