Modbus Protocol Complete Reference: TCP, RTU, and ASCII

Modbus Protocol Complete Reference

This technical reference documents the Modbus protocol family (Modbus RTU, Modbus ASCII, and Modbus TCP) with precise protocol limits, framing, register mapping, exception handling, timing requirements, gateway configuration, and practical deployment guidance. It consolidates the Modbus Application Protocol Specification V1.1b3 and vendor documentation into a single, actionable resource for automation engineers responsible for reliable fieldbus and Ethernet-based communications.

Key Concepts

Protocol Overview

Modbus is an application-layer client/server protocol used extensively in industrial automation. It operates over serial lines (Modbus RTU and Modbus ASCII) and over TCP/IP (Modbus TCP). According to the MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1b3, Modbus defines the Application Data Unit (ADU) and Protocol Data Unit (PDU) formats, supports up to 247 slaves on an RS485 multi-drop network, and specifies maximum ADU sizes of 256 bytes for serial transports and 260 bytes for Modbus TCP (due to the 7-byte MBAP header) (modbus.org).

ADU, PDU and Message Types

At the PDU level Modbus defines three distinct PDUs: the request PDU (mb_req_pdu), the normal response PDU (mb_rsp_pdu), and the exception response PDU (mb_excep_rsp_pdu). The maximum PDU size is 253 bytes for serial transports (256 ADU minus 1-byte slave address and 2-byte CRC) and 253 bytes for TCP payload (260 ADU minus 7-byte MBAP header), leading to practical limits on the number of registers or coils that can be exchanged in a single request (MODBUS spec V1.1b3).

Register and Addressing Model

Modbus provides four primary data types mapped into commonly used address blocks: coils (0xxxx), discrete inputs (1xxxx), input registers (3xxxx), and holding registers (4xxxx). Function codes operate on these areas; for example, Function 03 reads holding registers and Function 01 reads coils. Conventionally, register counts are limited by the PDU size: read functions typically allow up to 125 registers per request for holding/input registers (reads of 2000 bits for coils), though vendor implementations sometimes impose smaller practical limits (modbus.org).

Implementation Guide

Serial Variants: RTU and ASCII

Modbus serial operates in two mutually incompatible encodings:

• Modbus RTU — a compact binary format in which each 8-bit byte is transmitted LSB-first. Frames are delimited by a silent interval of at least 3.5 character times; CRC-16 provides a 2-byte error check. RTU is the preferred serial mode for efficiency and is typically used at baud rates between 9600 and 19200 bps; many devices support up to 115200 bps. Example RTU frame writing a single coil (slave 1, function 05, address 0x00AC, value 0xFF00): 01 05 00 AC FF 00 4E 8B (Waveshare, MODBUS spec).
• Modbus ASCII — a human-readable text encoding where each data byte is represented by two ASCII hex characters. Frames start with ':' and terminate with CR/LF; a longitudinal redundancy check (LRC) provides a single-byte error check. ASCII allows larger inter-character gaps (up to 1 second) but approximately doubles the transmitted byte count compared to RTU, making it less efficient for high-throughput applications (ProSoft KB).

Important: RTU and ASCII modes are not interoperable; ensure all devices on a serial bus use the same mode and agree on baud/parity/stop-bit settings.

Timing and Serial Physical Layer

Serial timing requirements are strict for RTU framing. RTU frames must be separated by at least 3.5 character times; for example:

• At 9600 bps, one character time (11 bits including start/stop/parity) ≈ 1.146 ms, so 3.5 character times ≈ 4.0 ms.
• At 19200 bps, 3.5 char times ≈ 2.0 ms.

RS485 physical layer recommendations follow TIA/EIA-485-A: use proper bus termination (typically 120 Ω at each extreme), avoid more than 32 unit loads without repeaters, and maintain cable length and grounding best practices. Adhere to recommended biasing resistors and fail-safe line states for robust multi-drop networks (DEOS blog).

Modbus TCP

Modbus TCP wraps the PDU in a 7-byte MBAP (Modbus Application Protocol) header: 2-byte Transaction ID, 2-byte Protocol ID (0 for Modbus), 2-byte Length, and 1-byte Unit ID (analogous to the slave address in serial). Modbus TCP uses TCP port 502 by convention, relies on TCP for transport integrity (no CRC), and supports a maximum ADU length of 260 bytes (MBAP + PDU) (MODBUS spec).

Gateway and Conversion Considerations

When deploying serial-to-TCP gateways, map serial slave addresses to the MBAP Unit ID field and ensure the gateway buffers entire RTU frames before encapsulation. Be aware of byte order: Modbus transmits register high byte then low byte (big-endian within the register) but application-level data types (32-bit integers, floats) require agreed-upon word and byte order between systems. In multi-protocol gateways, unit ID 255 commonly addresses the gateway itself; use appropriate unit addressing for downstream devices (Chipkin, Seneca).

Best Practices

Serial Strategy and Performance

Prefer RTU over ASCII for production systems due to its higher efficiency. Limit serial poll rates to avoid overruns — keep polling under 10 Hz for typical multi-drop RS485 networks unless hardware explicitly supports higher throughput and you have validated inter-frame timing. Implement retries and backoff: retry up to 3 times on transient CRC/LRC errors, then escalate an alarm after repeated failures (MODBUS spec).

Polling and Register Mapping

Group register reads to maximize payload efficiency while staying within PDU limits. For holding and input registers, request up to 125 registers per Function 03/04 request where possible; for coils and discrete inputs, group into bit arrays but respect per-request bit limits (up to 2000 coils). Use 0-based offsets in PDU payloads and document your mapping with the conventional 0xxxx/1xxxx/3xxxx/4xxxx notation to prevent off-by-one errors between devices and SCADA systems (MODBUS spec, Seneca).

Security

Modbus itself lacks authentication, encryption, and integrity protections. For Ethernet-based deployments, do not expose Modbus TCP port 502 directly to untrusted networks. Use VPNs, TLS tunnels, or industrial DMZ architectures to protect traffic. Apply network segmentation, access control lists, and monitoring to comply with ISA/IEC 62443 and minimize attack surface (DPS Telecom, MODBUS spec).

Diagnostics and Instrumentation

Implement diagnostic routines using Function 08 (Diagnostics) and Function 43/14 (Read Device Identification) to discover device type, vendor, and firmware. Log raw frames for at least short-term troubleshooting, capture timestamps to analyze timing-related framing errors, and maintain statistics for CRC/LRC failures, exception responses, and request timeouts to guide maintenance and network tuning (MODBUS spec).

Function Codes and Register Mapping

The following table summarizes commonly used function codes, typical payload limits, and the register types they operate on. Function code limits derive from PDU size constraints and the MODBUS specification.

Function Code	Name	Registers/Bits	Typical Limit per Request	Use Case
01	Read Coils	Discrete outputs (0xxxx)	Up to 2000 bits (vendor-limited)	Read multiple binary outputs
02	Read Discrete Inputs	Discrete inputs (1xxxx)	Up to 2000 bits	Read multiple binary inputs
03	Read Holding Registers	16-bit registers (4xxxx)	Up to 125 registers	Read configuration or measured values
04	Read Input Registers	16-bit registers (3xxxx)	Up to 125 registers	Read analog inputs or sensor values
05	Write Single Coil	Single bit	Single coil	Control discrete outputs
06	Write Single Register	Single 16-bit register	Single register	Set setpoints, parameters
15 (0x0F)	Write Multiple Coils	Multiple bits	Up to 1968 coils (spec limit), vendor limits apply	Batch discrete outputs
16 (0x10)	Write Multiple Registers	Multiple 16-bit registers	Up to 123 registers (vendor limits may be 125/120)	Write multiple setpoints/config values
43/14	Read Device ID / Read FIFO	Device information	Vendor-dependent	Identify device, firmware, and capabilities

Exception Handling

When a slave cannot comply with a request, it returns an exception response where the function code has 0x80 added and a one-byte exception code describing the error. Key exception codes include:

• 01 — Illegal Function: the function code is not supported by the slave.
• 02 — Illegal Data Address: the data address requested is outside the slave's accessible range.
• 03 — Illegal Data Value: the data value in the request is invalid or out of range.
• 04 — Slave Device Failure: unrecoverable error performing the requested action.
• 07 — Acknowledge: lengthy operation started (useful for some diagnostics).
• 08–0B — Device-specific or server-defined errors.

Design pollers to handle exception frames gracefully: log the event, avoid tight immediate retries for illegal data/addresses, and implement a backoff strategy for device-failure conditions (MODBUS spec).

Product Compatibility and Gateway Examples

Although Modbus itself is essentially versionless, vendors