# Module 10: RS-232, RS-422, RS-485

> Topologies, biasing, termination, and why your bus quietly stops working at node 17.

**Phase:** Physical Network & Transport  
**Estimated time:** 8 min  
**Release status:** Published  
**Content version:** 1.0.0  
**Source:** https://learnmodbus.studioseventeen.io/lesson/rs-physical-layers

## What you'll be able to do
- Wire a multi-drop RS-485 bus with correct termination and biasing.
- Pick RS-232 / RS-422 / RS-485 for a given topology.
- Diagnose 'works at node 5, dies at node 17' bus problems.

## Three things people get wrong
1. **Terminating one end only.** Terminate near both trunk ends, never on a derivation, and choose the termination network from the official design case plus the cable and device documentation.
2. **Skipping fail-safe biasing.** Use one bus-wide polarization network only when the connected devices require it; verify the values against the device and network design.
3. **Mixing A/B polarity across vendors.** Different vendors label A/B opposite ways. Trust the signal name (D+/D-) over the letter.

## From the field
**The 17th drop**

Adding one more meter to an existing RS-485 trunk caused every device to start dropping frames. The added stub was 80 cm — long enough to reflect at 38400 baud. Rerouting the cable as a true daisy-chain fixed the problem without changing any device settings.

## References
- [TIA-485-A standard](https://global.ihs.com/doc_detail.cfm?document_name=TIA-485-A)
- [Modbus over Serial Line V1.02](https://www.modbus.org/file/secure/modbusoverserial.pdf) — Section 3 — physical layer

## Lesson

# Module 10 Lesson: RS-232, RS-422, And RS-485
## Learner Outcome

By the end of this module, learners can distinguish Modbus serial transmission modes from physical/electrical layers, compare RS-232, RS-422, and RS-485 at a troubleshooting level, and identify common RS-485 topology, termination, common-conductor, polarity-label, and server-ID faults before blaming the Modbus register map.

## Key Concepts

- Modbus RTU and Modbus ASCII describe serial Modbus framing. RS-232, RS-422, and RS-485 describe electrical interfaces that can carry serial bytes.
- RS-232 is commonly used for short point-to-point links, bench work, and older equipment.
- RS-422 uses differential signaling and is commonly treated in this course as point-to-point or one-driver/multiple-receiver unless a device manual says otherwise.
- RS-485 is the common physical layer for multidrop industrial Modbus RTU networks.
- On a 2-wire RS-485 bus, topology, common conductor, terminations, polarity labels, bias/polarization, stubs, and duplicate server IDs can all create timeouts or intermittent communication.

## Key Terms

- RS-232: a point-to-point serial physical-layer option.
- RS-422: a differential serial physical-layer option often used for longer distances or one-driver/multiple-receiver variants.
- RS-485: a common differential multidrop serial physical layer used with Modbus RTU.
- Topology: the physical arrangement of devices and cable runs.
- Termination: resistance used to reduce signal reflections on a bus.
- Bias: a method for keeping an idle RS-485 line in a known state.
- Common conductor: a reference conductor that may be required by device manuals or site standards.
- Polarity label: vendor terminal naming for differential pairs; labels can vary.

## Source-Grounded Explanation

The Modbus PDU can be the same while the wiring problem changes completely.

```text
Modbus PDU:         Function Code | Data
Serial Modbus ADU:  Server Address | Function Code | Data | CRC or LRC
Physical layer:     RS-232, RS-422, RS-485, or another serial interface
```

Module 9 taught serial settings. Module 10 teaches the electrical layer carrying those serial characters.

| Physical Layer | Common Course Use | Topology | Troubleshooting Emphasis |
|---|---|---|---|
| RS-232 | Bench setup, legacy devices, short point-to-point links | Point-to-point | Cable/adapter, port settings, local loopback-style checks |
| RS-422 | Differential signaling, longer links, limited receive-only multidrop patterns | Usually point-to-point or one-driver/multiple-receiver in this course | Direction, pairs, device-manual-specific wiring |
| RS-485 | Industrial Modbus RTU field buses | Multidrop bus, commonly 2-wire half-duplex | Trunk/stubs, terminations, common conductor, unique server IDs, polarity labels, biasing |

### RS-485 Course Rules

The project wiki summarizes official serial-line guidance with these RS-485 points:

| Topic | Course Rule | Source Boundary |
|---|---|---|
| Bus shape | Use one trunk with daisy-chain devices or short derivations. | Official serial-line guide basis; final wording needs direct review. |
| Termination | Terminate near both ends of the trunk, not at every device. | Do not teach a universal resistor value without a selected cable/device source. |
| Derivations/stubs | Keep derivations short and do not terminate stubs. | Official guide gives a maximum derivation value in the wiki; final release should verify directly. |
| Common conductor | Standard 2-wire Modbus uses a balanced pair plus common conductor. | Grounding and shielding details are installation-specific. |
| Driver control | Only one driver should transmit at a time on a 2-wire bus. | Adapter direction-control behavior is hardware/tool-specific. |
| Node count | The wiki uses the official guide's 32-device statement as a conservative course anchor. | Higher counts require documented low-unit-load devices or repeaters. |
| Bias/polarization | If needed, implement for the segment rather than independently at many devices. | Resistor values are hardware-design or vendor-manual details. |
| Polarity labels | A/B, D+/D-, and vendor terminal names are not universal. | Verify against the device manual or controlled test evidence. |

Field note: many serial Modbus problems are RS-485 problems: A/B label reversal, missing common conductor, too many terminations, no termination, star topology, long stubs, duplicate server IDs, mismatched serial settings, weak biasing, ground loops, bad shielding, or adapter direction-control timing. Treat this as triage guidance, not a universal diagnosis.

## Practical Example: Three Meters On One RS-485 Trunk

Scenario: One Modbus RTU client polls three energy meters on a 2-wire RS-485 trunk.

| Field | Example |
|---|---|
| Variant | Modbus RTU |
| Physical layer | RS-485 2-wire half-duplex |
| Serial server addresses | `1`, `2`, and `3` |
| Function code | `04` Read Input Registers |
| Documented address | `30001` |
| Actual PDU address | `0` if the map uses one-based `30001` notation |
| Quantity | `2` registers |
| Data type/scale | vendor-defined 32-bit value, scale/unit from meter map |
| Expected normal behavior | Only the addressed server responds to each request |
| Likely physical-layer failure modes | timeout or intermittent failures from bad topology, missing common conductor, too many terminations, polarity mismatch, duplicate IDs, or direction-control problem |

Triage sequence:

1. Draw the trunk, stubs, devices, and client before changing software.
2. Confirm the physical layer really is RS-485 and not RS-232 or Ethernet-to-serial gateway behavior.
3. Confirm only one driver transmits at a time on the 2-wire segment, and that normal Modbus transactions are initiated by the client with unique server IDs.
4. Confirm there are terminations near the two trunk ends only.
5. Confirm common conductor, polarity labels, and shield/grounding approach from the device manuals.
6. Only after the physical layer and serial settings are credible should learners change function code, PDU address, data type, scale, or word order.

## Common Pitfalls

- Calling RS-485 "the Modbus protocol."
- Assuming a Modbus RTU problem must be an RS-485 problem; RTU can also appear over other serial interfaces.
- Building a star topology because Ethernet wiring habits leak into serial work.
- Adding termination at every device instead of at the trunk ends.
- Leaving out the common conductor and then chasing intermittent timeouts.
- Assuming A/B labels mean the same thing across all vendors.
- Treating a hardware app note or vendor high-node-count claim as a universal Modbus rule.
- Changing register addresses when the problem is a physical bus fault or duplicate serial server ID.

## Instructor Flow

1. Reuse the Module 9 layer diagram and move the focus to the physical layer.
2. Compare RS-232, RS-422, and RS-485 in one table.
3. Walk through the RS-485 course rules with source-boundary labels.
4. Use topology fault cards: correct trunk, star topology, three terminations, long stub, missing common, duplicate server ID, and uncertain A/B labels.
5. End by tying physical-layer evidence back to the three troubleshooting buckets: no valid response, exception response, wrong value.

## Check-Your-Understanding

1. Why can the same Modbus RTU request behave differently over RS-232 and RS-485 even if the PDU is unchanged?
2. On a passive RS-485 trunk, where should termination normally be placed?
3. Why should A/B or D+/D- labels be treated as vendor-specific evidence?
4. A bus has four servers and only one replies reliably. Name two wiring/topology checks and two configuration checks.

## Source Notes

- Official serial basis: Modbus over Serial Line Specification and Implementation Guide V1.02 for RS-485 topology, common conductor, termination, derivation, node-count, and polarization guidance as summarized in the project wiki.
- Official citation targets: [official-citation-map.md](https://learnmodbus.studioseventeen.io/resource/official-citation-map) rows for RS-485 implementation guidance, serial server address range and broadcast address, serial client/server legacy terminology, RTU/ASCII frame fields, CRC/LRC checking, and RTU timing and ASCII framing where symptoms depend on framing/timing.
- Secondary hardware sources: hardware vendor application notes listed in `notebooklm-source-list.md` should be used before publishing exact cable, shielding, termination resistor, surge, isolation, high-node-count, RS-232, or RS-422 comparison guidance.
- Field-note basis: project troubleshooting notes for common RS-485 fault patterns.
- Needs verification: final release needs direct serial-guide review and selected hardware-source review before turning draft wording into release-ready field guidance.

## Completion Checkpoint

Before moving on, learners should identify whether a symptom belongs to the physical layer, serial settings, Modbus frame evidence, or register-map interpretation. They should not perform field wiring changes from this lesson alone.

## Reusable Assets

- [RS-485 wiring review checklist](https://learnmodbus.studioseventeen.io/resource/rs485-wiring-review-checklist)
- [Physical-layer comparison lab](https://learnmodbus.studioseventeen.io/lesson/rs-physical-layers?page=lab-1)
- [Module 10 quiz](https://learnmodbus.studioseventeen.io/lesson/rs-physical-layers?page=quiz)
- [Serial settings triage checklist](https://learnmodbus.studioseventeen.io/resource/serial-settings-triage-checklist)

## Diagram source

```mermaid
flowchart LR
  T["120Ω term"] --- N1["Node 1"] --- N2["Node 2"] --- N3["Node 3"] --- Nx["Node N"] --- T2["120Ω term"]
  Bias["Bias resistors<br/>(idle high)"] -.-> N1
```

## Labs

### Lab 1

# Lab 11: Physical-Layer Topology Fault Cards
## Learner Outcome

Learners can inspect simplified serial-network diagrams, identify likely physical-layer faults, separate physical-layer evidence from Modbus PDU evidence, and choose the next check before changing register-map assumptions.

## Prerequisites

- Module 9: serial settings and timeout triage.
- Module 10 lesson through RS-485 course rules.

## Safety And Scope

This is a no-hardware topology exercise. It does not instruct learners to wire real equipment. Optional real-device or adapter labs require selected hardware, device manuals, safe bench power, and instructor review.

The diagrams are simplified teaching fixtures. Exact cable, termination resistor, shielding, grounding, surge protection, and isolation choices must come from the device manuals, site standard, and hardware references.

## Scenario

A Modbus RTU client polls three meters on an RS-485 2-wire half-duplex segment. All devices are intended to use the same serial settings. Learners receive eight topology cards and must identify the likely failure mode and next evidence to gather.

## Topology Cards

Legend:

```text
C = client
M1/M2/M3 = meters
T = trunk-end termination
--- = trunk
| = derivation/stub
? = unresolved wiring or label evidence
```

Card A: baseline trunk

```text
T  C --- M1 --- M2 --- M3  T
```

Card B: star topology

```text
        M1
        |
C ------+------ M2
        |
        M3
```

Card C: too many terminations

```text
T  C --- M1(T) --- M2(T) --- M3  T
```

Card D: no termination documented

```text
C --- M1 --- M2 --- M3
No trunk-end terminations documented
```

Card E: long stub

```text
T  C --- M1 --- M2  T
                  |
                  long derivation to M3
```

Card F: missing common conductor

```text
D0/D1 pair connected through trunk
Common conductor not connected or not documented
```

Card G: duplicate serial server IDs

```text
T  C --- M1(ID 1) --- M2(ID 1) --- M3(ID 3)  T
```

Card H: polarity labels unresolved or mismatched

```text
Client terminals: A/B
Meter terminals: D+/D-
Manual pages missing from commissioning folder
```

## Procedure

1. Classify each card as baseline, topology fault, termination fault, common-conductor issue, identity/configuration issue, or unresolved evidence.
2. Name the likely symptom: no valid response, intermittent response, response from wrong/duplicate server, or needs verification.
3. Choose the next evidence to gather.
4. State what not to change yet.
5. Fill the answer table.

## Worksheet

| Card | Classification | Likely Symptom | Next Evidence | What Not To Change Yet | Source Label |
|---|---|---|---|---|---|
| A |  |  |  |  |  |
| B |  |  |  |  |  |
| C |  |  |  |  |  |
| D |  |  |  |  |  |
| E |  |  |  |  |  |
| F |  |  |  |  |  |
| G |  |  |  |  |  |
| H |  |  |  |  |  |

## Answer Key

| Card | Classification | Likely Symptom | Next Evidence | What Not To Change Yet | Source Label |
|---|---|---|---|---|---|
| A | Baseline topology | Expected to work if settings, IDs, and wiring details are correct | Confirm actual terminations, common, polarity, settings, and server IDs | Do not assume it works without evidence | Official guide basis plus field verification |
| B | Star topology | Reflections/intermittent or no valid response | Draw actual cable path and redesign as trunk with short derivations where needed | Register map, scale, word order | Official guide basis |
| C | Too many terminations | Weak signal/intermittent or no valid response | Locate enabled terminations and leave only trunk-end terminations | Function code and PDU address | Official guide basis |
| D | No termination documented | Intermittent or no valid response depending on length, speed, and devices | Confirm whether trunk-end termination exists and whether devices include switchable termination | Register map and data type | Official guide basis plus hardware/manual verification |
| E | Long stub/derivation | Intermittent response, especially at higher speeds or with noise | Measure derivation length and compare to source-backed limit | Data type and scale | Official guide basis, final length wording pending direct review |
| F | Missing common conductor | Intermittent communication or noise sensitivity | Verify common conductor and grounding approach from device manuals/site standard | Register address | Official guide basis plus installation-specific review |
| G | Duplicate server IDs | Colliding responses or wrong device responding | Verify every server address is unique on the segment | Baud/parity if other devices work | Official serial addressing plus field verification |
| H | Unresolved or mismatched polarity labels | No valid response or intermittent response | Get manuals or perform controlled bench test to map A/B to D+/D- | Do not swap wires repeatedly without evidence | Vendor-specific note / Needs verification |

## Expected Observations

- Physical-layer faults often produce no valid response or intermittent response, not clean Modbus exceptions.
- A good-looking topology sketch is not proof; learners still need settings, terminations, common, polarity, and server-ID evidence.
- Duplicate server IDs are a configuration/identity problem, but the symptom can look like a bus problem.
- Polarity labels are implementation-specific and should be verified rather than assumed.

## Troubleshooting Notes

- Do not let learners solve every card by changing PDU address.
- Keep exact resistor values, shield bonding, surge protection, and isolation out of the answer key until hardware references are selected.
- If learners mention 120-ohm termination, ask for the cable/device source rather than accepting it as a universal Modbus rule.
- Optional hardware extension should use a verified training bench, not production wiring.

## Check Questions

1. Which cards are physical topology faults?
2. Which card is primarily a serial server identity problem?
3. Why is Card H marked needs verification rather than simply "swap A and B"?
4. Which cards could create timeouts without any Modbus exception response?

## Instructor Notes

- Ask learners to separate official serial-line guidance, vendor/manual evidence, and field notes.
- Use this lab before Module 11 frame decoding so learners do not confuse CRC failures with topology mistakes.
- If teaching with real hardware later, require a written bench plan and stop point before rewiring anything.

## Source Notes

- Official source: Modbus over Serial Line Specification and Implementation Guide V1.02 as summarized in `modbus-wiki.md` for RS-485 trunk, derivation, termination, common conductor, node count, and polarization guidance.
- Secondary source: hardware application notes listed in `notebooklm-source-list.md` for exact physical-design details before release.
- Synthetic source: all topology cards are course-authored teaching diagrams.

## Knowledge check

# Module 10 Quiz: RS-232, RS-422, And RS-485
## Questions

### Multiple Choice

1. Which statement is safest?
   - A. RS-485 is the Modbus protocol.
   - B. Modbus RTU and Modbus ASCII are serial transmission modes; RS-232, RS-422, and RS-485 are electrical layers.
   - C. Modbus TCP requires RS-485 wiring.
   - D. RS-232 is always multidrop.

2. A passive RS-485 trunk has termination enabled at the client, M1, M2, and the far end. What is the likely issue?
   - A. Too many terminations.
   - B. Wrong word order.
   - C. Illegal function code.
   - D. Missing MBAP header.

3. A bus has two meters both configured as serial server ID `1`. What should be checked first?
   - A. Unique server IDs.
   - B. Scale factor.
   - C. IEEE-754 byte order.
   - D. Port 502.

4. Why should A/B or D+/D- polarity labels be treated carefully?
   - A. The labels are always identical across vendors.
   - B. They are implementation-specific and should be verified against manuals or controlled tests.
   - C. They are PDU addresses.
   - D. They are Modbus exception codes.

5. Which guidance should not be taught as a universal Modbus rule without a hardware source?
   - A. RS-485 is an electrical layer, not the Modbus PDU.
   - B. A passive trunk should not have termination at every device.
   - C. An exact termination resistor value for every cable and device.
   - D. Duplicate serial server IDs can cause trouble.

6. On a passive RS-485 trunk, where should termination normally be placed?
   - A. At every device on the bus.
   - B. Near the two ends of the trunk only.
   - C. Only at the client, never at the servers.
   - D. Termination is never needed on RS-485.

7. Following the official serial-line guide as a conservative course anchor, how many standard unit loads does the guide use as the device count for a single RS-485 segment before repeaters or low-unit-load devices are required?
   - A. 8.
   - B. 16.
   - C. 32.
   - D. 247.

### Short Answer

1. Explain why the same Modbus RTU PDU can have different failure modes over RS-232 and RS-485.
2. List three RS-485 physical-layer checks to make before changing a register address.
3. Why is a star topology risky in an RS-485 Modbus field bus?
4. What source would you need before teaching exact cable, shielding, or termination resistor values?

### Applied Scenario

One Modbus RTU client polls three meters on an RS-485 2-wire segment. M1 responds reliably, M2 and M3 are intermittent. A sketch shows a long branch to M3 and termination enabled at M1, M2, and the trunk end.

Tasks:

1. Name two likely physical-layer issues.
2. Name one configuration issue to check.
3. State what not to change yet.
4. Label which claims are official serial-line guidance, field notes, or needs verification.

## Answer Key

1. Multiple choice: B. RTU/ASCII define serial Modbus framing; RS-232/422/485 define electrical interfaces. A and C confuse protocol/transport layers, and D is false.
2. Multiple choice: A. The course rule is termination near the two trunk ends, not at every device. Word order, function code, and MBAP are different layers.
3. Multiple choice: A. Duplicate server IDs can cause colliding or confusing responses on a multidrop segment.
4. Multiple choice: B. Polarity labels are vendor/device-specific evidence and should not be assumed universal.
5. Multiple choice: C. Exact resistor values depend on cable/device/hardware references. The other statements are appropriate course-level guidance with source labels.
6. Multiple choice: B. The course rule is termination near the two trunk ends only. Terminating at every device, only at the client, or omitting termination entirely all diverge from that rule.
7. Multiple choice: C. The wiki uses the official guide's 32-unit-load statement as a conservative course anchor for a single segment; higher counts require documented low-unit-load devices or repeaters. `247` is the top serial server address, not a node-count limit.

## Distractor Review Notes

| Question | Correct | Why The Distractors Are Wrong |
|---:|---|---|
| 1 | B | A confuses electrical layer with protocol, C assigns TCP to serial wiring, and D invents multidrop behavior for RS-232. |
| 2 | A | B/C/D are data, function, or TCP framing issues rather than an RS-485 termination issue. |
| 3 | A | B/C/D are interpretation or TCP details that do not resolve duplicate serial server IDs on a multidrop bus. |
| 4 | B | A overgeneralizes vendor labels, and C/D confuse terminal markings with PDU addresses or exception codes. |
| 5 | C | A/B/D are defensible course-level boundaries; C requires named hardware, cable, or installation evidence before becoming a universal rule. |
| 6 | B | A over-terminates the bus, C terminates only one node, and D denies that termination is ever needed; the rule is termination near the two trunk ends. |
| 7 | C | A/B understate the guide's 32-unit-load anchor, and D confuses the top serial server address (`247`) with a segment device count. |

Short answer:

1. The Modbus PDU can be identical, but RS-232 and RS-485 use different electrical interfaces and topologies. RS-485 multidrop faults such as stubs, terminations, polarity labels, common conductor, duplicate IDs, or bus contention do not apply the same way to a short point-to-point RS-232 link.
2. Good answers include trunk shape, termination count/location, common conductor, polarity labels, server IDs, stubs/derivations, bias/polarization source, serial settings, and adapter direction control.
3. A star creates multiple branches rather than one controlled trunk with short derivations; it can create signal integrity and reflection problems.
4. A named device manual, cable/hardware reference, installation standard, or reviewed hardware application note.

Applied scenario:

1. Likely physical-layer issues: long branch/stub and too many enabled terminations.
2. Check unique serial server IDs and matching serial settings.
3. Do not change register address, word order, scale, or units until the bus evidence is corrected or ruled out.
4. Official serial-line guidance: trunk/derivation and termination discipline at course level. Field notes: intermittent symptoms and common field failure patterns. Needs verification: exact cable length, resistor values, shielding/grounding, and product-specific terminal labels.

## Source Notes

- Official citation targets: [official-citation-map.md](https://learnmodbus.studioseventeen.io/resource/official-citation-map) rows for RS-485 implementation guidance, serial server address range and broadcast address, serial client/server legacy terminology, RTU/ASCII frame fields, CRC/LRC checking, and RTU timing and ASCII framing.
- Exact cable, shielding, termination, resistor, surge, isolation, and terminal-label guidance remains hardware-source or vendor-specific until reviewed.

---
_Learn Modbus · learnmodbus.studioseventeen.io · Module 10/16 · v1.0.0 · Exported for offline / agent use._