RS-485 converter wiring troubleshooting when the link fails

Why does the link still fail after swapping to RS-485?

Most RS-485 failures after a swap are wiring or configuration in the new path. The 50 ft RS-232 run at 9600 baud was inside its 15 m (about 50 ft) specified reach, so distance did not kill the link. The converter path added new places to go wrong.

The symptom tells you which layer to work:

• Worked on RS-232, silent on the converter: the fault sits in the new path. Check the converter's documented two-wire mode, the A/B pair, the termination and the configured port.
• The programming tool talks, the HMI application does not: the HMI driver points at the wrong port number or framing on the same PC.
• Garbled characters at both ends: a framing mismatch. Baud, data bits, parity or stop bits differ between the endpoints.
• The link drops for tens of seconds while the line runs: polling cycle and timeouts, measured under the slow-updates question below.
• No activity anywhere: power or mode. Check the converter's supply arrangement and its documented two-wire or four-wire setting before touching the cable.

Each of these is testable in minutes. Distance, the suspicion that started the swap, takes one multiplication.

Was 50 ft too long for RS-232 at 9600 baud?

No. The RS-232 standard specifies 15 m, about 50 ft, at the full load it defines. At 9600 bit/s practical guidance puts the usable run near 30 m (98 ft), and field guidance reports dependable runs of 150 to 250 ft at that same speed.

The 15 m figure carries a load condition. The standard defines the cable capacitance its drivers must handle, and 15 m is the specified reach at that full load. Lower the speed and the same cable does less damage per bit. That is why a widely used length guide pairs 9600 bit/s with about 30 m, and why field guidance puts dependable runs at 150 to 250 ft at that speed.

One number beats all of these. If this cable carried clean frames at 9600 baud before the trouble started, the distance question is closed. Settle distance with the link's own history, then go to the connector.

How do you restore the known RS-232 link first?

Re-terminate the connector to the documented terminal assignments of the exact port the cable lands on. These failures hide a crossed or open conductor inside the plug more often than anywhere else, so the disturbed connector is the first place the meter should go.

Pull power from the serial side before you repin, because a slipped conductor can reset the PLC. Then work the list:

1. Name the port. Write down which physical port and module the cable lands on, and read that port's wiring assignments from the device documentation.
2. Re-terminate the connector. Open the plug, seat every conductor on its documented pin, and crimp or screw it home. Read the assignments from the documentation; the connector's shape and the cable's colors tell you nothing.
3. Check continuity. Ohmmeter each conductor end to end, then each conductor to shield. Continuity tells you the copper is whole; the documented assignments tell you which conductor goes where.
4. Match the framing. Set the same baud, data bits, parity and stop bits on both endpoints, copied from the port that last worked.
5. Test with one client. Close the programming tool, run the HMI application alone, and watch live data for 30 minutes without a drop.

When that passes, the known working path is back, and every later experiment has a baseline.

Worked example: what does the 50 ft decision look like on paper?

Take the scenario head on. An HMI PC sits 50 ft (15.24 m) from the PLC at 9600 baud, the RS-232 link died after a connector was disturbed, an RS-485 converter swap failed too, and the numbers have to decide where to work.

Distance. 50 ft × 0.3048 m/ft = 15.24 m. The RS-232 specified reach at full load is 15 m, so the cable sits 0.24 m past the specified load case. Against the 9600 bit/s guidance of about 30 m, the headroom is 30 m − 15.24 m = 14.76 m, about 48 ft, and the field range of 150 to 250 ft leaves another 100 to 200 ft. Distance is cleared; the fault is not length.

Failure points. The same numbers decide where to work:

The converter path carries 15 items to get right where the direct link carries 8, and the disturbed connector is broken in both. The numbers send you back to the connector, not deeper into the converter.

Which wiring details stop an RS-485 converter link?

A handful of details stop two-wire RS-485 more often than anything else: A/B polarity, the termination resistor value and placement, the signal reference, the cable's characteristic impedance, and the master count. Each carries a number or a documented name to check against.

• Polarity. The standard names A the inverting (negative) line and B the non-inverting (positive) line, but device terminals carry labels such as D+, D−, + and − in whatever convention each maker chose, so crossed pairs are routine. The pair is differential: a swapped pair reads as inverted data, so swap the pair at one end and retry. A silent link that comes alive had reversed polarity.
• Termination. Match the resistor to the cable's differential-mode characteristic impedance and fit it at the two physical ends of the network. A 120 Ω cable takes 120 Ω resistors. Fit none on middle drops, where one shortens the drive margin for the whole run.
• Reference. Run the reference or signal-ground conductor the converter's wiring documentation calls for alongside the pair, and land the foil shield's drain where that same documentation draws it.
• Cable. Use one twisted pair whose datasheet lists a characteristic impedance of 120 Ω; 24 AWG shielded twisted pair is the common instrument-grade choice. A four-conductor foil-shielded data cable qualifies when its datasheet prints 120 Ω, so read the jacket's printing before you trust its color.
• One master. One device drives the pair at a time. Two masters on one RS-485 bus silence the network, and why two Modbus RTU masters stop one bus is its own diagnosis.

Get these right and a two-wire converter link comes up on the first or second try.

How do you isolate the dead segment: PC, converter, cable or PLC port?

Test one segment at a time and in this order: PC to converter, converter settings, cable end to end, then the PLC port. Each step ends in live data or hands you the failed segment by elimination.

1. PC to converter. Confirm which port number the PC application opens, because adapters that enumerate as new devices change numbers when they move sockets. Send a test write and watch the converter's status LED if its documentation gives it one.
2. Converter settings. Set the documented mode, two-wire on a two-wire network, check the supply arrangement, and check whether the documentation requires handshake lines.
3. Cable. Ohmmeter every conductor end to end, then every conductor to shield, with both ends isolated from the devices.
4. PLC port. Run the programming software on the same physical port at the same framing. If the programming tool talks and the HMI application does not, the fault sits on the PC side, and a dead programming link with a live PLC link has its own checklist.
5. Port match. The classic miss: the wiring landed on one port while the program configured another. Count the ports and match the physical one to the configured one.

Two passes through the list end in live data or a named failed segment.

Why do PLC updates slow to more than 30 seconds on a polled link?

Slow updates are the polling cycle, not the copper. A master that questions three slaves in sequence waits out a full timeout on every slave that stops answering, and a 3 s timeout with one retry turns one silent slave into about 6 s of dead air per cycle.

The arithmetic uses example values you can replace from your own driver's configuration screen. At 9600 bit/s with 11-bit frames, one byte takes 11 ÷ 9600 = 1.15 ms on the wire, so a 100-byte request or response takes 0.115 s. A master questioning three slaves in sequence spends about 0.23 s of wire time plus 0.1 s of processing per slave, 0.33 s each, or one second per cycle.

Now one slave stops answering. A 3 s timeout with one retry takes that slave 3 + 3 + 0.115 s, about 6.1 s, and the cycle comes to 2 × 0.33 + 6.1 = 6.8 s, roughly seven times slower. Leave a 5 s timeout with two retries in place and two silent slaves out of five add 2 × (5 × 3 + 0.115) = 30.2 s of waiting on their own, which pushes the full cycle past 30 s. That is the intermittent-loss signature: the copper is fine, the timers starve the cycle.

The fixes are configuration, not copper:

• Shorten the timeout to cover the slowest live slave plus margin; 0.5 s covers most local polls.
• Cut retries on status-only polls and keep them on writes.
• Poll critical slaves more often and slow ones less, on a schedule the master controls.
• Run one client per serial port at a time; an HMI application and a programming tool on one port contend for it.

When is moving the HMI link to RS-485 the right call?

Move when the topology demands it: several devices on one pair, or a run past about 30 m at 9600 baud. At 50 ft point to point with one PLC, RS-232 already works and RS-485 adds failure modes instead of reach.

Decide per case:

• 50 ft, one PLC, dead link: stay on RS-232 and fix the connector wiring. The distance is cleared and the direct path carries about half the checks.
• Past about 30 m at this speed, one device: the converter path earns its place; work polarity, termination, reference and cable in that order.
• Several devices on one pair: two-wire RS-485 multidrop is the right topology, and wiring one HMI panel to three PLCs on an RS-422 multidrop shows the same discipline on a related standard.
• More RS-232 length instead: extend the existing cable properly; how to extend an RS-232 HMI cable by 10 feet safely gives the rules for staying inside the margin.

If the crew also needs this data on a wall, that is a separate screen with its own playback. The shop-floor displays in our use-factory category handle the wall board while the PLC link stays untouched.

Recommendation: restore the RS-232 link first and leave it in place; at 50 ft and 9600 baud it sits inside its documented reach and the fault to fix is connector wiring. Move to two-wire RS-485 when you hang more than one device on the pair or the run outgrows RS-232's reach, then bring the link up one segment at a time, PC to converter, cable, PLC port, checking A/B polarity, termination at both ends and the signal reference on the way.

Questions