— Layer-by-Layer from Wire to Application

(Module 6 · Troubleshooting & Diagnostics – Mastering Modbus Problem Solving)

---

Learning objectives

1. Recognise the tell-tale symptoms of the most frequent Modbus failures.
2. Apply a structured, four-layer methodology (Physical → Link → Protocol → Application) that isolates root causes in minutes.
3. Measure timing, electrical, and protocol health with oscilloscopes, logic analyzers, serial monitors, and Wireshark.
4. Document & escalate findings clearly so maintenance or vendors can act without guess-work.

---

19.1 Symptom-to-layer cheat sheet

Observable symptom	Probable troubleshooting layer (first)	Typical root cause
Total silence (timeouts)	Physical	Broken wire, swapped A/B, wrong baud
Intermittent CRC errors	Physical ▶ Link	Bad shield, no bias, star topology reflections
Exception 02 (Illegal Addr)	Protocol ▶ Application	Off-by-1 address, wrong table
Exception 06 (Device Busy)	Application	PLC flashing FW, drive in tuning mode
Write succeeds, value reverts	Application	Wrong register, slave property read-only
One slave freezes others	Link ▶ Physical	Address clash, stuck TX-Enable

(Fig-19-1 placeholder: symptom–layer decision tree.)

---

19.2 The four-layer troubleshooting model

┌──────────────────┐
│ 4. Application   │ Logic, scaling, vendor quirks
├──────────────────┤
│ 3. Protocol      │ FC, PDU, exception, byte order
├──────────────────┤
│ 2. Link & Timing │ CRC, T3.5 gap, address duplicates
├──────────────────┤
│ 1. Physical      │ Voltage, cabling, termination, bias
└──────────────────┘

Start bottom-up. A framing error ≠ PLC bug; a CRC storm ≠ scaling issue.

---

19.3 Layer 1 — Physical (cable, transceiver, power)

19.3.1 Checklist

✔︎	Test	Pass criterion
☐	Continuity A→A, B→B	< 1 Ω each, no shorts
☐	Termination 120 Ω ± 10 % at both ends	Measured with meter (bus un-powered)
☐	Bias voltage idle VAB ≥ +0.2 V	Scope DC measurement
☐	Shield ground one end only	< 1 Ω to earth
☐	Star taps avoided	No stub > 0.1 m

(Fig-19-2: good vs. bad termination scope captures.)

19.3.2 Common physical faults

Fault	Oscilloscope sign	Fix
Unterminated stub	Echo/reflection after edge	Remove stub or add repeater
Swapped A/B	Inverted waveform, CRC errors every frame	Cross wires at one device
Missing bias	Idle line floats ± 50 mV; phantom frames	Add 680 Ω pull-up / pull-down

---

19.4 Layer 2 — Link & timing (RTU focus)

19.4.1 Measure T3.5 and T1.5

Formula: Tchar = 11 bits / baud; T3.5 = 3.5 × Tchar.
Use logic analyzer trigger “idle > T3.0” to delineate frames.

Baud	T3.5 ideal	Good range
9 600	4.0 ms	3.5 – 5 ms
38 400	1.0 ms	0.8 – 1.3 ms
115 200	0.335 ms	0.25 – 0.45 ms

19.4.2 Address and collision tests

1. Temporarily set master to broadcast ID 0 read function — every slave should not reply.
2. Swap to ID 1; if two replies overlap, duplicate address exists.

---

19.5 Layer 3 — Protocol (PDU & FC)

Tool	Filter	Purpose
Wireshark	modbus && tcp.port==502	Decode MBAP, FC, exception
RealTerm	Hex view	Check RTU frame bytes, CRC
pymodbus.framer	--decode CLI	Validate function/length offline

19.5.1 Top protocol mistakes

• Off-by-one address (40001 vs 40000).
• Reading 126 registers (spec max = 125).
• Word/byte swap mis-interpretation → seemingly random values.
• Mixed table RW rights: writing to 3X or 1X causes exception 01.

---

19.6 Layer 4 — Application logic

1. Verify value ranges: drive speed > rated → slave returns 03 Illegal Value.
2. Check firmware state: many VFDs reject Modbus writes in LOCAL mode.
3. Ensure poll frequency < device update interval; slow sensor may reply same data and mislead you.

---

19.7 Five-step systematic workflow

Step	Action	Tool	Expected output
1	Power & wiring audit	Multimeter, eyes	Solid LEDs, correct shield
2	Scope idle & frame	Saleae / scope	Clean differential, proper gaps
3	Serial tap decode	RealTerm + pycrc	Valid CRCs
4	Protocol capture	Wireshark	Correct FC, no exceptions
5	Compare to spec	Datasheet spreadsheet	Scaling & address match

(Fig-19-3: printable flowchart.)

---

19.8 Common scenarios — step-by-step

19.8.1 Scenario A — Intermittent CRC errors

1. Symptom: Wireshark shows TCP retry, RealTerm shows bad CRC every few minutes.
2. Layer 1: scope reveals ringing after 1.2 m stub → star drop to new sensor.
3. Cut stub, retest: CRC clean 24 h.

19.8.2 Scenario B — Exception 02 after firmware upgrade

1. New slave firmware added 100 registers at top, shifted map.
2. Spreadsheet mismatch; poller still asks old addresses.
3. Update poll list, publish change log; alarm cleared.

---

19.9 Using diagnostic tools effectively

Tool	Quick recipe
Modbus Poll	Menu → Display → Monitor → highlight exception frames red.
Wireshark I/O Graph	Plot modbus packets; spike ⇒ flood/loop.
RealTerm timestamp	Enable “Time [ms]” to spot frame gaps.
Logic-2 protocol decode	Saleae “Modbus” analyzer; export CSV of CRC errors.

---

19.10 Preventive measures

• Design: follow termination & bias checklist from Chapter 4.
• Documentation: maintain single source register map; version-control.
• Monitoring: log exception rate; alert if > 0.1 % of polls.
• Change control: re-baseline timing and map after any firmware or wiring change.

---

19.11 Best-practice wall chart

✔︎	Rule
☐	Always begin at the bottom layer (voltage).
☐	Validate bias before tweaking software.
☐	Trust exception frames over silent timeouts.
☐	Use CRC calculator on captured frames to confirm integrity.
☐	Keep oscilloscope and Wireshark captures for post-mortem.

---

Chapter recap

• A repeatable four-layer method turns chaotic Modbus issues into deterministic tasks.
• 80 % of faults live in physical & timing layers—fix wiring before code.
• Protocol tools (Wireshark, RealTerm) quickly flag off-by-one addresses and illegal values.
• Document findings and enforce preventive standards; tomorrow’s outage is prevented today.

---

Assets to create

ID	Visual / file
Fig-19-1	Symptom-layer decision tree
Fig-19-2	Good vs bad termination scope
Fig-19-3	Five-step flowchart
Worksheet	Printable 4-layer checklist (PDF)
Sample captures	CRC-error Saleae file, Wireshark pcap with exception

---

Next: Chapter 20 – Diagnostic Tools in Depth will walk through RealTerm, PuTTY, Wireshark dissectors, hardware protocol analyzers, and integrated PLC logs, giving you a toolbox for every scenario from a noisy RS-485 trunk to an overloaded Modbus/TCP VLAN.