A Modbus RTU slave answers a PLC request, yet the register stays blank. The electrician suspects damaged RS-485 wiring; the programmer increases the timeout. Neither action will fix a perfectly valid exception response. Modbus exception codes tell an integrator that the device received a request but rejected the requested operation. The first task is to distinguish that response from a missing or corrupted reply.
This matters when integrating Tachyonic Intelligence’s Titania remote I/O and PyXis vibration monitoring with PLCs, gateways and SCADA. A working serial link does not prove that the client’s function code, register offset or requested length matches the installed firmware.
Recognise a real exception response
The Modbus Application Protocol Specification V1.1b3 states that an exception response sets the high bit of the original function code and returns an exception code. For example, a request using function 03 (read holding registers) can receive a response function of 0x83. The following byte indicates the reason. This is different from a timeout, CRC failure or framing error, where the master may not receive a valid response at all.
Four responses that point to different investigations
| Exception | Meaning | First check |
|---|---|---|
| 01 — Illegal function | The function is not allowable for that server in its current implementation or state. | Check whether the map calls for coils, discrete inputs, holding registers or input registers. |
| 02 — Illegal data address | The requested address or combined address-and-quantity range is not valid. | Check the documented range, zero-based offset and total number of requested items. |
| 03 — Illegal data value | A field within the request has an invalid structure or allowable value under the protocol. | Check request length and parameters; do not assume the process measurement itself is out of range. |
| 04 — Server device failure | The server encountered an unrecoverable error while attempting the requested action. | Record the request and device state; investigate according to its supported diagnostics. |
These are protocol definitions, not promises that every firmware release exposes every optional function or diagnostic. Never infer an undocumented register merely because another product returns the same code.
Check function code before changing wiring
Function 03 reads holding registers; function 04 reads input registers. Their data classes are distinct even when a service tool displays a familiar 3xxxx or 4xxxx reference. A device may legitimately reject a read of its input-register identity data through function 03. Do not test a suspected mapping problem by writing to holding registers; start with an approved read-only request.
Modbus protocol data-unit addresses start at zero, while some manuals number reference entries from one. A driver may expect a raw offset, a numbered reference or a prefixed address. Record which convention the driver uses, then translate the released map once. Repeatedly adding or subtracting one without understanding the interface can accidentally read a different, valid item.
Check the whole range, not only its first register
An address may be valid by itself but invalid when the request spans beyond the implemented block. If a read of one documented register works and a larger batch fails with exception 02, check quantity, block boundaries and the firmware-specific map before blaming electrical noise. Reduce the request to a known supported range and rebuild batches around documented boundaries.
Establish identity and revision first
The controlled Titania 8DI/8DO and PyXis 222x Rev 08 datasheets identify their respective Modbus device families, but the exact registers, types, scales and feature availability require the approved map for the installed firmware. Use a known supported identity read and reconcile hardware, firmware and serial details before importing a tag template. See the Titania identity commissioning procedure and PyXis device traceability guide.
Make the repair reproducible
- Capture slave ID, baud and serial format, function, raw starting address, quantity, reply bytes, CRC validity and timestamp.
- Classify the result as a valid exception, a valid normal reply, a timeout or a damaged frame.
- Compare the query with the issued device map and the master driver’s address convention.
- Correct one read-only parameter at a time; retest the smallest documented range before expanding it.
- Verify the final PLC tag, SCADA value, engineering units and quality flag after the correction.
Do not retain an old value as though it were new when a read has failed. The Modbus polling and freshness guide explains how to keep last-good values separate from current measurements.
For an integration review, contact Tachyonic Intelligence with the exact request/response trace, device serial and firmware revision, released register-map issue and PLC driver configuration.
Technical references: Modbus Application Protocol Specification V1.1b3, especially addressing and exception responses; Titania 8DI/8DO TTN-DS-2026-001 Rev 08; PyXis 222x TTN-DS-2026-002 Rev 08, both issued July 2026. Confirm the actual firmware-specific register map before use. No undocumented addresses, compatibility or safety certification is claimed.
Image: “Industrial Circuit Board Panel with Wire Connections” by Warren Yip / Pexels, reused from the TISB media library under the Pexels licence. Illustrative generic wiring; it does not depict a Titania or PyXis product, an actual register fault or an endorsement.
