MODBUS Application Protocol Specification V1.1b3
The current Modbus Organization application-protocol specification defines the transport-independent PDU, four logical data tables, zero-based PDU addressing, public function codes, limits, and exception responses. It deliberately leaves device meaning, scaling, multi-register types, and transport framing to other contracts.
Version 1.1b3, dated 26 April 2012 and still listed by the Modbus Organization as the application-protocol specification, is the source of truth for Modbus request/reply semantics. Its apparent simplicity is real, but so is the amount of meaning that the device profile must supply.
What the specification establishes #
- A Modbus PDU is a one-byte function code followed by function-specific data. A transport adds its own fields to form an ADU.
- The PDU is limited to 253 bytes. An RTU ADU adds a one-byte server address and two-byte CRC for 256 bytes total; a Modbus TCP ADU adds the seven-byte MBAP header for 260 bytes total.
- The logical model contains coils, discrete inputs, input registers, and holding registers. The first two are one-bit objects; the latter two are 16-bit words.
- PDU addresses are zero-based from 0 to 65535. Human-facing references such as
40001are conventions outside the wire address and must never be sent literally without mapping. - Multi-byte address and data fields are encoded most-significant byte first. The specification does not define the word order of a 32-bit value spread across two 16-bit registers.
- An exception response returns the requested function code with its high bit set and a one-byte exception code. A timeout is a different observation: no valid response arrived.
What the device contract must add #
The application specification does not assign engineering units, signedness, scaling, enumerations, byte/word order above 16 bits, writable ranges, atomicity across multiple registers, freshness, or safe polling rates. Those properties belong in the device data map and integration test. Nor does plain Modbus provide authentication or message confidentiality; the Modbus Organization publishes a separate TLS-based Modbus Security protocol.
Visual audit #
All 50 pages were text-extracted; pages 3–8 and the exception-response section were rendered and inspected. Figures 3–8 are load-bearing because they separate PDU from ADU, show normal versus exception transactions, distinguish the four data tables, and expose the one-based-reference/zero-based-wire mismatch. The topic keeps those relationships in a new theme-aware SVG rather than copying the source artwork. Function-specific state diagrams are omitted because they repeat the same request/validate/execute/respond pattern and are more legible as a worked frame trace.