# Module 14: Troubleshooting Workflow

> A repeatable evidence-first method for diagnosing failed reads, writes, and timeouts.

**Phase:** Integration & Real Systems  
**Estimated time:** 13 min  
**Release status:** Published  
**Content version:** 1.0.0  
**Source:** https://learnmodbus.studioseventeen.io/lesson/troubleshooting-workflow

## What you'll be able to do
- Apply a repeatable Observe → Hypothesize → Test → Record loop.
- Choose the right layer to investigate first (transport, framing, addressing, decoding).
- Produce a hand-off report another integrator can act on.

## Three things people get wrong
1. **Changing two things at once.** One variable per test. Otherwise you can't tell which change mattered.
2. **Skipping the capture.** Always capture the bytes. Conversations about Modbus without a capture are mostly fiction.
3. **Treating success as 'understood'.** If you don't know why a change worked, the bug will be back.

## From the field
**The capture that ended the standoff**

Two vendors blamed each other for a flaky meter for three months. A 15-minute capture showed the meter responded correctly to every poll — but the gateway re-asked the same question 11 ms later, before the bus had settled. The capture replaced the argument with a configuration change.

## References
- [Wireshark Modbus dissector](https://www.wireshark.org/docs/dfref/m/modbus.html)

## Lesson

# Module 14 Lesson: Troubleshooting Workflow
## Learner Outcome

By the end of this module, learners can classify a Modbus problem as no response, exception response, or wrong value; choose the next evidence-producing test; and document one change at a time without confusing transport, addressing, gateway, and data-decoding faults.

## Key Concepts

- Troubleshooting starts with the exact variant and path: RTU, ASCII, TCP, Modbus Security, RTU-over-TCP, or gateway path.
- Use the 3-bucket method before changing settings: no response, exception response, wrong value.
- Physical/network reachability comes before register-map edits.
- Function code, table, documented address, PDU address, quantity, Unit Identifier or serial server address, and transport wrapper must be recorded together.
- A valid exception response proves that something understood enough of the request to reject it.
- A normal response with an implausible value is a data-meaning problem until proven otherwise.
- Write tests require a safety gate; start with read-only evidence.

## Key Terms

- Evidence bucket: the first troubleshooting classification, such as no response, exception response, wrong value, or safety stop.
- No response: a client observation that no valid Modbus response arrived.
- Wrong value: a valid response whose decoded meaning does not match expectation.
- Hypothesis: the suspected cause selected from current evidence.
- One-change test: a controlled next step that changes one variable and records the result.
- Safety stop: a required pause before write-capable, hardware, or production-affecting action.

## Source-Grounded Explanation

### The 3-Bucket Method

Most field symptoms can be sorted before deep analysis:

| Bucket | What The Learner Sees | First Evidence To Collect |
|---|---|---|
| No response | Timeout, no bytes, connection failure, malformed frame discard, or no valid response before deadline. | Variant, reachability, serial settings, wiring, Unit Identifier or serial server address, gateway path, timeout chain, raw request evidence. |
| Exception response | Function code with high bit set and an exception code. | Requested function, PDU address, quantity, data value, device access mode, safety state, gateway exception context. |
| Wrong value | Normal response but decoded value is missing, stale, nonsensical, or outside expected range. | Raw response bytes, data type, signedness, word order, scale, unit, quality/freshness, state context, source map. |

The bucket is not the root cause. It is the first sorting step that prevents random changes. A timeout should not send the learner straight to word order. A valid exception response should not send the learner straight to wiring. An impossible value should not be treated as a dead device until the bytes are checked.

### Step 1: Identify The Variant And Path

Record the path before interpreting symptoms:

- RTU, ASCII, TCP, Modbus Security, RTU-over-TCP, or vendor dialect.
- Pure serial, pure Ethernet, secure TCP, or TCP-to-serial gateway.
- Serial server address, MBAP Unit Identifier, or gateway route identifier.
- Legacy labels in manuals or tools, such as slave ID, device ID, station number, or unit ID.

Transport changes the evidence. RTU uses a serial address and CRC. ASCII uses ASCII hex characters, LRC, and text delimiters. True Modbus TCP uses MBAP plus PDU and no serial CRC. A gateway may add route behavior that is product-specific.

### Step 2: Prove Reachability Before Map Changes

For serial paths, check baud rate, parity, data bits, stop bits, serial server address, wiring polarity labels, common conductor, termination, topology, adapter mode, and duplicate IDs before changing register addresses.

For TCP paths, check IP reachability, TCP port, firewall, connection handling, Unit Identifier requirements, and gateway status before changing PDU address or scale.

For gateways, compare upstream client timeout, gateway timeout, downstream serial settings, route table, retry behavior, and downstream target health. Do not invent timeout defaults; use selected product documentation or lab evidence.

### Step 3: Read A Known-Good, Read-Only Value

Start with a safe read-only value when possible:

- Model number.
- Firmware version.
- Device status.
- Line frequency.
- Temperature.
- Input voltage.

Record the request as a complete evidence row:

| Field | Example |
|---|---|
| Function code | `03` or `04` as specified by the map |
| Documented address | `40010`, `30051`, or vendor row reference |
| Actual PDU address | zero-based offset actually sent |
| Quantity | count of coils, bits, or registers |
| Unit Identifier or serial server address | MBAP Unit Identifier or RTU/ASCII address |
| Expected data meaning | type, width, scale, unit, word order, state/freshness note |
| Expected normal response | function code, byte count, raw data length |
| Likely failure mode | timeout, exception `01`, `02`, `03`, `04`, `0A`, `0B`, or wrong value |

### Step 4: Interpret Exceptions As Evidence

An exception response is useful because it is still a Modbus response. The exception function sets the high bit on the requested function code. For example, a failed function `03` response uses exception function `83`.

Use common exceptions as evidence, not as final diagnoses:

| Exception | Practical Direction |
|---:|---|
| `01` Illegal Function | Function unsupported, forbidden, wrong access path, or device state does not allow it. |
| `02` Illegal Data Address | Address, table, range, gap, or quantity crosses unsupported data. |
| `03` Illegal Data Value | Quantity, byte count, written value, or request data shape is invalid. |
| `04` Server Device Failure | Device could not perform the requested action; check device state and manual. |
| `0A` Gateway Path Unavailable | Gateway path/route availability evidence is needed. |
| `0B` Gateway Target Device Failed To Respond | Gateway responded but the downstream target did not answer. |

Do not treat exception `02` as proof that the device is offline. It proves the responder rejected the addressed data range.

### Step 5: Verify Value Meaning

If communication succeeds, the next question is whether the value is meaningful:

- Did the tool use the correct table and function code?
- Was the documented address converted to the correct PDU address?
- Is the value signed or unsigned?
- Is it one register, two registers, four registers, or a string?
- Is word order high-word-first or low-word-first?
- Is there a scale, offset, unit, enum, bitfield, or sentinel value?
- Is the device in a state where the value should be valid?
- Could a gateway, cache, or dashboard be showing stale data?

Wrong decoded values should be handled with raw bytes and map evidence, not by changing serial settings at random.

## Practical Example: Dashboard Shows an Impossible `2.7e23 Hz`

Scenario: an integrator expects AC line frequency near `60 Hz`, but the dashboard shows about `2.7e23 Hz` — a value far too large to be real, even though the Modbus response came back normal.

| Item | Value |
|---|---|
| Transport | Modbus TCP |
| Function code | `04` Read Input Registers |
| Documented register | Input register `30051` |
| Actual PDU address | `0x0032` if one-based `30001` notation is confirmed |
| Quantity | `2` registers |
| Data type | 32-bit IEEE-754 float |
| Raw response registers | `0x4270 0x6666` (bytes `42 70 66 66`) |
| Correct value | `60.1 Hz` when the two registers are combined in the documented word order |
| Word order | Needs source-map verification |
| Scale/unit | Direct `Hz` unless source map says otherwise |
| Expected normal response | Function `04`, byte count `4`, two registers |
| Likely failure mode | Wrong value from reversed word order or a type mismatch; exception `02` only if address/range is invalid |

Troubleshooting flow:

1. Confirm whether the symptom is no response, exception response, or wrong value. Here the dashboard has a value, so start in the wrong-value bucket even though the number is absurd.
2. Capture or log the raw response bytes: `42 70 66 66`.
3. Confirm the function code is `04` because the map says input register.
4. Confirm the PDU address is `0x0032`, not the displayed `30051`.
5. Decode the two registers using the map's word order. Combined as `0x4270 0x6666` the float is `60.1 Hz`; combined in reversed word order as `0x6666 0x4270` the float is about `2.7e23 Hz`, which matches the wrong dashboard value.
6. Compare the result to a local HMI, vendor software, or expected operating range.
7. Record the final address, type, word order, scale, and evidence in the troubleshooting log.

Because reversing the word order turns the absurd reading back into a plausible `60.1 Hz`, the root cause was decoded-value interpretation, not Modbus reachability.

## Common Pitfalls

- Changing address, Unit Identifier, word order, scale, and timeout in one attempt.
- Treating no response as an illegal-data-address exception.
- Treating a valid exception response as a wiring failure.
- Assuming exception `02` means the whole device is offline.
- Reading input registers with function `03` or holding registers with function `04` without checking the source map.
- Treating `40001` notation as bytes sent in the request.
- Testing write functions before read-only communication and safety constraints are proven.
- Retrying too aggressively through a slow gateway and increasing bus load.
- Treating stale cached values as fresh device state.

## Instructor Flow

1. Put the 3-bucket table on screen and require a bucket before any fix is proposed.
2. Walk one no-response case, one exception case, and one wrong-value case.
3. Require learners to fill the evidence log with one hypothesis and one test at a time.
4. Use the worked frequency example to show why a normal response can still be wrong.
5. Stop any write-function scenario at the safety gate and route it to Module 15.

## Check-Your-Understanding

1. A client receives function `83` and exception code `02`. What does the high bit on the function code mean?
2. Why is a known-good read-only register a better first target than a write command?
3. What evidence separates an off-by-one address problem from a word-order problem?
4. Why do bad RTU CRC or parity cases often look like timeouts?
5. A TCP capture shows Unit Identifier `1`, but the intended downstream RTU server is `3`. Which configuration area should be inspected?

## Source Notes

- Official protocol basis: Modbus Application Protocol Specification V1.1b3 for PDU addressing, function codes, normal and exception response shape, exception codes, and public request/response behavior.
- Official serial basis: Modbus over Serial Line Specification and Implementation Guide V1.02 for RTU/ASCII framing, serial settings, CRC/LRC, timing, serial addressing, and silent discard behavior.
- Official TCP basis: Modbus Messaging on TCP/IP Implementation Guide V1.0b for MBAP, Unit Identifier, TCP behavior, and gateway context.
- Official citation targets: [official-citation-map.md](https://learnmodbus.studioseventeen.io/resource/official-citation-map) rows for normal response vs exception response, exception codes and exception response PDU shape, addressing model and zero-based PDU addresses, RTU/ASCII frame fields, RTU timing and ASCII framing, CRC/LRC checking, MBAP header fields, Unit Identifier and gateway routing, and TCP connection behavior and concurrency.
- Internal course basis: `modbus-wiki.md`, `course-phase-drafts/phase-4-integration-troubleshooting-real-systems.md`, `release/troubleshooting-evidence-log.md`, and Module 5-14 draft packages.
- Tool behavior: Wireshark, Node-RED, PyModbus, mbpoll, simulator logs, and client UI wording require version-pinned verification before release.
- Synthetic source: scenario cards in the Module 14 lab are course-authored fixtures, not captured production logs.

## Completion Checkpoint

Before moving on, learners should classify a scenario into no response, exception response, wrong value, or safety stop, then record the next one-change test and the evidence that would confirm or reject the hypothesis.

## Troubleshooting Decision Tree

Follow the branches in order — never skip a layer to "save time".

```mermaid
flowchart TD
  S["Symptom reported"] --> Q1{"Any bytes on the wire?"}
  Q1 -- "No" --> T1["Transport<br/>baud · parity · wiring · IP/port"]
  Q1 -- "Yes" --> Q2{"CRC / LRC / TCP length valid?"}
  Q2 -- "No" --> T2["Framing<br/>cable · termination · bit timing"]
  Q2 -- "Yes" --> Q3{"Response FC ≥ 0x80?"}
  Q3 -- "Yes" --> T3["Exception<br/>read exception code → addressing / value"]
  Q3 -- "No" --> Q4{"Value matches expected meaning?"}
  Q4 -- "No" --> T4["Decoding<br/>type · word order · scale · unit · sentinel"]
  Q4 -- "Yes" --> Done["Solved — record root cause"]
  T1 --> Loop["Observe again"]
  T2 --> Loop
  T3 --> Loop
  T4 --> Loop
  Loop --> S
```

Text equivalent of the decision tree, in the same order:

1. **Any bytes on the wire?** If no, the problem is at the **transport** layer — check baud, parity, wiring, and IP/port — then observe again. If yes, continue.
2. **Are the CRC, LRC, or TCP length valid?** If no, the problem is **framing** — check cable, termination, and bit timing — then observe again. If yes, continue.
3. **Is the response function code `0x80` or higher?** If yes, it is an **exception** — read the exception code and follow it to an addressing or value problem — then observe again. If no, continue.
4. **Does the value match its expected meaning?** If no, the problem is **decoding** — check data type, word order, scale, unit, and sentinel handling — then observe again. If yes, the case is **solved**; record the root cause.

Each layer loops back to observing the symptom again so you change one thing at a time and re-test.

## Reusable Assets

- [Troubleshooting scenario lab](https://learnmodbus.studioseventeen.io/lesson/troubleshooting-workflow?page=lab-1)
- [Troubleshooting decision tree](https://learnmodbus.studioseventeen.io/resource/troubleshooting-decision-tree)
- [Troubleshooting evidence log](https://learnmodbus.studioseventeen.io/resource/troubleshooting-evidence-log)
- [Module 14 quiz](https://learnmodbus.studioseventeen.io/lesson/troubleshooting-workflow?page=quiz)

## Diagram source

```mermaid
flowchart TD
  S["Symptom"] --> O["Observe<br/>(capture evidence)"]
  O --> H["Hypothesize<br/>(layer + cause)"]
  H --> T["Test<br/>(single change)"]
  T --> R["Record<br/>(log + decide)"]
  R -->|Solved| Close["Close"]
  R -->|Not yet| O
```

## Labs

### Lab 1

# Lab 19: Troubleshooting Scenario Cards
## Learner Outcome

Learners can classify staged Modbus failures into no response, exception response, or wrong value, then choose one evidence-producing next step without changing unrelated settings.

## Prerequisites

- Module 4: function codes and exception responses.
- Module 5: documented address versus PDU address.
- Module 7: data types and word order.
- Module 8: scale, unit, quality, and freshness.
- Module 9-13: serial, RTU/ASCII, TCP, and gateway evidence.
- Module 14 lesson through the 3-bucket method.

## Safety And Scope

This is a no-hardware paper lab using synthetic cards. It does not connect to a simulator, network, gateway, or real device. Do not scan networks, write to devices, or change production settings. Any write-function card stops at the safety gate and routes to Module 15 before a command is sent.

## Scenario Setup

You are reviewing failed Modbus reads from a training system. Each card gives enough evidence to choose the first diagnostic bucket and next test. Record one hypothesis and one next action at a time.

## Scenario Cards

| Card | Evidence | Learner Task |
|---|---|---|
| A | RTU client sends server `7`, function `03`, PDU address `0x0009`, quantity `1`. No bytes are accepted before timeout. Notes show client `9600 8-E-1`; device label `19200 8-E-1`. | Classify the bucket and name the next setting to verify. |
| B | RTU client sends server `1`, function `03`, PDU address `0x0009`, quantity `1`. No response. Device label says serial address `7`. | Decide whether to change map address or serial server address first. |
| C | TCP client reads function `03`, documented holding register `40010`, but sends PDU address `0x000A`. Response is `83 02`. | Explain why a valid exception response changes the troubleshooting path. |
| D | TCP client reads function `04`, documented input register `30051`, PDU address `0x0032`, quantity `2`. Response is normal with two registers, but dashboard shows about `2.7e23 Hz` (raw registers `0x4270 0x6666`). | Classify as wrong value and name the raw-byte checks. |
| E | Gateway request uses Unit Identifier `8`, PDU `03 00 14 00 02`. Gateway returns exception `83 0B`. | Separate downstream target failure from upstream timeout. |
| F | Client receives normal response for function `03`, byte count `4`, but the route note says the gateway may answer from cache when downstream polling is stale. | Decide what freshness evidence is needed. |
| G | Client configured for true Modbus TCP sends RTU-style bytes with serial address and CRC over TCP. No valid Modbus TCP response is seen. | Identify the mode mismatch before changing addresses. |
| H | Request reads holding registers `40020-40035` as one block through a vendor map with a reserved gap at `40027`. Response is `83 02`. | Redesign the read grouping. |
| I | Client reads a changing 32-bit counter as two separate one-register reads. Values occasionally jump backward. | Identify coherency risk and safer read strategy. |
| J | Technician wants to test function `06` write single register on a live controller because reads are confusing. Process effect is unknown. | Apply stop conditions and route to safety review. |

## Procedure

1. For each card, choose one bucket: no response, exception response, wrong value, or safety stop.
2. Record the evidence that proves the bucket.
3. Identify the likely fault domain: transport, serial settings, server or Unit Identifier, function/table/address/quantity, gateway, data decoding, freshness, coherency, polling plan, or safety.
4. Choose exactly one next test.
5. Write what not to change yet.
6. Fill out the evidence log for at least three cards.

## Worksheet

| Card | Bucket | Fault Domain | Evidence Used | Next Test | What Not To Change Yet |
|---|---|---|---|---|---|
| A |  |  |  |  |  |
| B |  |  |  |  |  |
| C |  |  |  |  |  |
| D |  |  |  |  |  |
| E |  |  |  |  |  |
| F |  |  |  |  |  |
| G |  |  |  |  |  |
| H |  |  |  |  |  |
| I |  |  |  |  |  |
| J |  |  |  |  |  |

## Answer Key

| Card | Bucket | Fault Domain | Evidence Used | Next Test | What Not To Change Yet |
|---|---|---|---|---|---|
| A | No response | Serial settings | Timeout plus baud mismatch note | Verify baud and match client to documented device setting | PDU address, word order, scale |
| B | No response | Serial server address | Request sent to server `1`; device labeled `7` | Send read-only request to server `7` or confirm actual configured ID | Register map and word order |
| C | Exception response | Addressing/range | Exception function `83`, code `02`, PDU address `0x000A` for `40010` | Recalculate one-based `40001` notation and try PDU `0x0009` if source supports it | Serial/TCP reachability; a response arrived |
| D | Wrong value | Data decoding | Normal response but implausible engineering value | Inspect raw bytes, data type, word order, scale, unit, and source map | IP, port, serial settings |
| E | Exception response | Gateway downstream target | Gateway returned exception `0B` | Check downstream target, route, serial settings, and gateway log | Treating it as upstream silence |
| F | Wrong value | Freshness/cache | Normal response with stale-cache note | Check timestamp, quality, cache age, polling status, or direct downstream comparison | Packet syntax if response is structurally valid |
| G | No valid response | TCP mode mismatch | RTU-style bytes used where true MBAP is expected | Select true Modbus TCP mode or verify RTU-over-TCP support | Address base and scale |
| H | Exception response | Poll grouping/map gap | Exception `02` on a range crossing reserved gap | Split reads around the gap and document supported ranges | Gateway reachability |
| I | Wrong value | Multi-register coherency | Separate reads of a changing multi-register value | Read both registers in one request or use device-supported snapshot/latch method if documented | Scaling until raw coherency is proven |
| J | Safety stop | Write safety | Unknown process effect and live controller | Stop; complete write-safety checklist, authorization, preconditions, rollback, and independent verification | Sending the write command |

## Expected Observations

- A timeout does not prove the register address is wrong.
- A valid exception response proves that some responder parsed enough of the request to reject it.
- Wrong value requires raw bytes and source-map evidence.
- Gateway exceptions provide different evidence than client-side silence.
- Polling design can create failures even when individual addresses are valid.
- Safety stop is a correct troubleshooting outcome when the next test is a live write.

## Troubleshooting Notes

- Change one variable per trial and record it.
- When a card has a valid Modbus exception, do not start by changing wiring or firewall settings.
- When a card has no valid response, do not start by changing word order.
- When a card has a normal response, do not declare success until data type, scale, unit, and freshness make sense.
- Keep tool-specific messages out of the final answer key until the toolchain is version-pinned.

## Check Questions

1. Which cards are no-response cases?
2. Which cards are exception-response cases?
3. Which cards are wrong-value cases?
4. Which card should stop before any Modbus write is sent?
5. Why is Card C not primarily a wiring problem?
6. Why is Card D not primarily an IP reachability problem?

## Instructor Notes

- Require learners to defend why their chosen next test is narrower than a broad configuration reset.
- Ask learners to fill [Troubleshooting Evidence Log](https://learnmodbus.studioseventeen.io/resource/troubleshooting-evidence-log) for Cards C, D, and E.
- Use Card J as the bridge into Module 15 security and write safety.
- Optional extension: convert Cards A-H into Node-RED or simulator exercises only after tool versions and expected outputs are verified.

## Source Notes

- Official protocol source: Modbus Application Protocol Specification V1.1b3 for exception response shape and exception codes.
- Official serial source: Modbus over Serial Line Specification and Implementation Guide V1.02 for RTU/ASCII framing, CRC/LRC, addressing, and silent discard behavior.
- Official TCP source: Modbus Messaging on TCP/IP Implementation Guide V1.0b for MBAP and Unit Identifier context.
- Internal course source: Modules 5-13 draft packages, `modbus-wiki.md`, and `release/troubleshooting-decision-tree.md`.
- Synthetic source: all cards are course-authored scenario fixtures, not captured tool logs or production traffic.

## Knowledge check

# Module 14 Quiz: Troubleshooting Workflow
## Questions

1. A client receives no valid response before timeout. Which first bucket should be assigned?
   A. No response
   B. Exception response
   C. Wrong value
   D. Safety stop

2. A response to function `03` comes back as exception function `83` with exception code `02`. What does the high bit on the function code indicate?
   A. The serial CRC was accepted as data.
   B. The response is a Modbus exception response to function `03`.
   C. The server sent a 32-bit float.
   D. The client used the wrong TCP port.

3. A normal response returns raw bytes, but the dashboard value is impossible. What should be checked first?
   A. Firewall rules.
   B. Serial termination.
   C. Data type, word order, scale, unit, address base, and freshness.
   D. Whether all write functions are enabled.

4. A Modbus RTU request has the wrong parity setting and the client times out. Why is an exception response unlikely?
   A. Malformed serial frames are normally discarded rather than parsed into Modbus exceptions.
   B. Exception responses only exist in Modbus TCP.
   C. Parity settings change the documented register number.
   D. The response must be a stale cached value.

5. A valid exception `02` appears when reading a large range that crosses a reserved map gap. What is the best next action?
   A. Change word order.
   B. Split the polling group around the gap and verify supported ranges.
   C. Add RTU CRC bytes to Modbus TCP.
   D. Increase writes until the device responds.

6. A gateway returns exception `0B`. Which statement is most accurate?
   A. The upstream client received no Modbus response.
   B. The gateway returned a valid exception saying the downstream target failed to respond.
   C. The value is definitely scaled incorrectly.
   D. The request must have used function `04`.

7. A technician wants to send function `06` to a live controller because reads are confusing and the process effect is unknown. What is the correct course action?
   A. Send the write and inspect the echo.
   B. Stop and complete write-safety, authorization, precondition, rollback, and independent-verification checks.
   C. Change baud rate first.
   D. Change word order first.

8. Which troubleshooting habit best preserves evidence?
   A. Change several settings at once to save time.
   B. Change one variable per trial and record observation, hypothesis, test, result, conclusion, and next action.
   C. Start with writes because they prove control.
   D. Ignore raw bytes when the dashboard is wrong.

9. A TCP capture shows MBAP Unit Identifier `1`, but the intended downstream RTU server is `3`. Which area should be inspected?
   A. Gateway route or Unit Identifier configuration.
   B. IEEE-754 exponent bits.
   C. Coil write mask.
   D. ASCII LRC delimiter.

10. Which source boundary is correct for troubleshooting workflows?
    A. Official specs define response shapes and protocol fields; tool UI messages, simulator logs, and field workflows need tool or lab evidence.
    B. Tool screenshots are official Modbus protocol rules.
    C. Field notes override the application protocol.
    D. A dashboard value is always enough evidence.

## Answer Key

1. A. Timeout or no valid response belongs in the no-response bucket.
2. B. Exception responses set the high bit on the requested function code, so `83` is an exception response to `03`.
3. C. A normal response with impossible meaning is a wrong-value problem until data meaning and freshness are checked.
4. A. Bad serial settings or corrupt frames often prevent a valid Modbus frame from being parsed, so clients see timeouts.
5. B. Exception `02` on a range crossing a gap points to address/range evidence and polling-group redesign.
6. B. Exception `0B` is gateway-response evidence about downstream target failure, not client-side silence.
7. B. Unknown live write effects require a safety stop and Module 15 write-safety workflow before any command.
8. B. One variable per trial keeps the evidence chain usable.
9. A. In a gateway path, Unit Identifier and route configuration are the first evidence to inspect.
10. A. Official specs govern protocol mechanics; tool behavior and workflows need verified tool/lab/source support.

## Distractor Review Notes

| Question | Correct | Why The Distractors Are Wrong |
|---:|---|---|
| 1 | A | B requires a valid exception response, C requires a normal response with bad meaning, and D is reserved for unsafe action or write-risk conditions. |
| 2 | B | A treats an exception function as data, C invents a float, and D confuses the function byte with transport configuration. |
| 3 | C | A/B fit no-response connectivity or physical-layer cases, and D jumps to write policy before value interpretation evidence. |
| 4 | A | B falsely limits exceptions to TCP, C confuses serial framing with addressing, and D invents cache behavior. |
| 5 | B | A changes interpretation, C mixes RTU and TCP, and D escalates to unsafe writes instead of narrowing the range. |
| 6 | B | A contradicts receipt of a valid exception, C jumps to scale, and D invents the request function. |
| 7 | B | A trusts a write echo too much, while C/D change unrelated settings before safety boundaries are satisfied. |
| 8 | B | A destroys evidence, C is unsafe, and D discards the raw evidence needed to debug a wrong value. |
| 9 | A | B/C/D are data, write, or ASCII details that do not resolve a Unit Identifier route mismatch. |
| 10 | A | B/C elevate secondary evidence above official protocol mechanics, and D treats a dashboard value as sufficient evidence. |

## Instructor Notes

- Use questions 1-3 to reinforce the 3-bucket method.
- Use questions 6 and 9 to connect Module 14 back to Module 13 gateway evidence.
- Use question 7 as the bridge into Module 15.
- Add real tool screenshots only after tool versions are pinned in `lab-toolchain-bom.md`.

## Source Notes

- Official citation targets: [official-citation-map.md](https://learnmodbus.studioseventeen.io/resource/official-citation-map) rows for normal response vs exception response, exception codes and exception response PDU shape, addressing model and zero-based PDU addresses, RTU/ASCII frame fields, RTU timing and ASCII framing, CRC/LRC checking, MBAP header fields, Unit Identifier and gateway routing, TCP connection behavior and concurrency, and write single register shape and echo boundary.
- Tool UI messages, simulator logs, PCAP workflows, and field troubleshooting steps remain versioned lab-evidence gates.

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