P2000 PLC-to-PLC RS-232 Works Over a 3-Wire Pin 1-3-4 Cable

In this installation, two new P2000 CPUs linked port-to-port with a ZipLink ZL-RJ12CBL-2 RJ12 crossover cable timed out on every poll. The master's Tx LED flashed, the remote showed no activity, and no exception response came back. Rewiring the link to carry only pins 1, 3 and 4 fixed it. The same cable runs two Click PLCs with the same port pinout without complaint, which is why it gets trusted on the P2000 and why hours go into baud rates and RTS modes before anyone looks at the copper.

The checks below run in order. Each one names the reading to take and where to go next.

Check 1: Watch the remote port's LEDs during a poll

Trigger the read instruction on the master (MRX or RX) and watch both CPUs' serial port LEDs at the same time. This one reading tells you which layer to work on.

• Master Tx dark: the instruction is not executing, or it points at the wrong port. Check the rung enable and the port selection in the instruction.
• Master Tx flashes, remote shows nothing: the request is not arriving electrically. Settings on the slave cannot matter yet because the port sees no line activity. Skip ahead to Check 3. This is the state this installation was in.
• Remote receives but never transmits: the frame arrives and the slave will not answer it. Suspect a baud, parity, stop-bit or node-address mismatch. Go to Check 2.
• Both sides transmit, master still errors: the reply is not reaching the master's receive pin, or it arrives garbled. Check the return half of the data pair in Check 3.

Stop cycling baud rates, RTS modes and instructions

These are the usual night-shift moves. None of them can fix a wiring fault, and all of them were tried here without result.

Quick fix tried	Why it fails when the remote shows no activity
Stepping through baud rates	A baud mismatch makes the slave discard frames it receives. It does not stop the slave's port from seeing line activity at all.
Swapping RX for MRX	Both instructions put a request on the same physical port. If the far end never receives it, the instruction choice is irrelevant.
Changing RTS mode	The RTS setting controls when firmware asserts the line. It does not change what that pin is wired to on the far CPU.
Disabling RTS in the Hardware Config	The pin stays physically connected and the port driver still holds it at a defined level. In this installation, disabling RTS did not clear the fault.

Reset the port settings to one known, documented set on both CPUs and leave them alone while you work the cable.

Check 2: Read the MRX result as timeout or exception

A timeout and an exception response point to different layers:

• Exception response: the slave received the frame, parsed it and refused it. Common reasons are a bad register address or an unsupported function. The wiring and baud rate are good, so fix the request.
• Timeout with no exception string: nothing valid came back inside the timeout window. Either the slave never saw a valid frame addressed to it, or its reply never made it back.

This installation got a timeout with no exception string, and the remote LED stayed dark. That combination points at the physical layer. Before condemning the cable, confirm these settings once:

1. Baud rate, parity, data bits and stop bits match on both ports.
2. Both ports run the same protocol, with the remote port configured to answer as a slave.
3. The remote port's node address is 11.
4. The slave/node field inside the master's MRX is 11. The master port's own address (10 here) is not what the request targets. A request sent to the wrong node times out silently, exactly like a broken wire.

If all four match and the remote port still shows no receive activity, go to Check 3.

Check 3: Meter the crossover cable against the P2000 port pinout

A six-position RJ12 crossover built for PLC-to-PLC use crosses the transmit/receive pair so that each CPU's TX lands on the other's RX. The ZL-RJ12CBL-2 also crosses the RTS position at one end onto the +5 VDC position at the other. On the P2000, that puts one port's RTS output directly on the other port's +5 V supply pin, in both directions.

Tying an output driver to a supply pin is a contention fault. How a port tolerates it depends on its transceiver and supply design. The Click port shrugs it off. The P2000 port stopped receiving, even with RTS disabled in configuration. That difference is why a cable proven on one CPU family is not proof for another, even when the RJ12 pinouts match.

1. Power down both CPUs and unplug the cable from both ends.
2. Meter each of the six positions end to end, and write down the map: which pin at end A lands on which pin at end B.
3. Pull the serial port pinout from the P2000 CPU hardware manual. Identify signal ground, TX, RX, RTS and +5 V by position.
4. Flag any conductor that lands an RTS pin or a +5 V pin on anything at the far end. On this cable, you will find RTS-to-+5 V in both directions.
5. Confirm the data pair crosses (TX to RX, RX to TX) and that signal ground runs straight through.

Match the symptom to the layer before rewiring

Symptom	Most likely cause	Next action
Master Tx flashes, remote shows nothing, MRX times out	Cable fault: RTS/+5 V crossover, open data conductor, or data pair not crossed	Build the three-wire link below
Remote receives, never replies, timeout	Baud/parity/format mismatch, or the MRX targets the wrong node	Re-run Check 2 line by line
Exception response returned	Bad register address or function for the slave	Fix the request; the link itself is working
Intermittent timeouts after a clean start	Marginal ground, noise, or a timeout set too short	Verify signal ground continuity, then run the soak test below
Works on Click, fails on P2000 with the same cable	The port does not tolerate RTS driven into +5 V	Remove RTS and +5 V from the cable

Wire only pins 1, 3 and 4 to restore the link

Temporary restore (tonight): this is what got this installation running.

1. Put an RJ12 breakout board on each CPU port.
2. Jumper only positions 1, 3 and 4 between the boards. Use the same mapping the crossover cable uses for those three positions (you recorded it in Check 3): signal ground straight through, the data pair crossed.
3. Leave every other position open. That includes RTS and +5 V.
4. Power up and trigger the MRX. The remote port should now show receive activity on every poll.

Permanent repair: do not leave breakout boards and jumpers in a panel.

1. Build a dedicated three-conductor cable, wired only on pins 1, 3 and 4 with the verified mapping.
2. Label both ends: "P2000 to P2000 — pins 1, 3, 4 only."
3. Meter the finished cable against the map before installing it.
4. Keep the ZL-RJ12CBL-2 with the Click spares so it does not end up back on a P2000 pair.

Prove the wired link before adding radio modems

The end goal in this installation is radio modems. Adding radios before the wired link is proven stacks two unknowns on one timeout. Close out the wired link first:

1. LEDs: on every poll, the remote port receives and then transmits a reply.
2. Instruction status: the MRX completes with its success status set, and no timeout or error flag.
3. Live data: put a free-running counter in the slave's source register and confirm the master's destination tag tracks it.
4. Fault injection: unplug the cable. The master should time out. Reconnect it, and polling should recover without a CPU restart.
5. Soak test: let it poll for a full shift and count successes against errors. The error count should stay at zero on a wired link.

Revisit RTS when the radio modems go in

RTS was the problem only because it was wired into a supply pin. Many radio modems use RTS on purpose, to key the transmitter or to manage half-duplex turnaround. At the radio stage, RTS may need to return as a deliberate connection to the radio's RTS input, and never to a power pin.

• Get the radio's serial pinout from its manual. Note which pins it needs, and whether its connector supplies or expects power on any pin.
• If the radio needs RTS, set the P2000 port's RTS mode and any turn-on/turn-off delays to match the radio's keying time. The radio manual lists that time.
• If the radio needs no handshaking, keep the three-wire scheme on the radio side too.
• Build the radio cables from the pinouts, not from the RJ12 crossover.
• Re-run the verification list over the radio path. Expect to lengthen the MRX timeout to cover radio latency.

FAQ