Modbus ADU vs PDU: Message Structure

Back to Blog

The PDU: The Part That Never Changes

The protocol data unit is the heart of a Modbus message: a single function code byte followed by the data that function needs, such as a starting address and a quantity for a read. This is the same whether the message travels over serial RTU, serial ASCII, or TCP. When two engineers talk about what a Modbus request says, they are talking about the PDU, and the function codes that define it are covered in the Modbus function code reference.

The Modbus specification caps the PDU size, which is why a single read tops out at 125 registers and a single write at fewer, since the address and quantity and data must all fit. The read limit and its arithmetic are explained in the Modbus 125-register read limit reference. Because the PDU is transport-independent, the same request logic works everywhere, which is a large part of why Modbus is so portable.

The ADU: What the Transport Wraps Around It

The application data unit is the PDU plus everything the transport adds to deliver it. On serial RTU the ADU prepends a one-byte slave address and appends a two-byte CRC, so the frame is address, PDU, CRC. On serial ASCII the wrapping is a colon, the PDU encoded as hex characters, an LRC, and a carriage-return line-feed. On TCP the ADU replaces the serial address and checksum with the seven-byte MBAP header in front of the PDU, as detailed in the Modbus MBAP header reference.

This is why a gateway can bridge serial and TCP so cleanly: it strips one ADU wrapping off the PDU and applies the other, leaving the function code and data untouched. It is also why the RTU CRC vanishes on TCP, since the transport provides its own integrity, a point drawn out in the Modbus TCP vs RTU comparison. Knowing which bytes are ADU wrapping and which are PDU turns any capture into something readable.

A Byte-by-Byte Worked Example

Take the most common request there is: read a block of holding registers. The PDU is five bytes - the function code 0x03, a two-byte starting address, and a two-byte register count. On serial RTU the master prepends the one-byte slave address and appends the two-byte CRC, so eight bytes cross the wire. On TCP the same five PDU bytes ride behind the seven-byte MBAP header - transaction identifier, protocol identifier, length, and unit identifier - for twelve bytes in total. Line the two frames up side by side and the middle five bytes match exactly; only the wrapper differs.

The table summarizes what each transport wraps around that identical core:

Field	Serial RTU ADU	Modbus TCP ADU
Addressing	One-byte slave address ahead of the PDU	One-byte unit identifier inside the MBAP header
Frame boundaries	Silent idle gaps between frames	Length field in the MBAP header
Integrity check	Two-byte CRC after the PDU	None - TCP's own checksums cover it
The PDU itself	Function code plus data, untouched	Function code plus data, untouched

Once you can name each byte's owner - transport or protocol - a capture stops looking like noise and starts reading like sentences.

Which Layer Owns Which Failure

The split earns its keep in troubleshooting, because symptoms sort cleanly by layer. Garbled frames, checksum mismatches, and messages that vanish without any reply are ADU territory: wiring, termination, baud rate, byte format, or a collision corrupted the wrapper before the PDU was ever evaluated. Persistent RTU CRC errors, for example, are a physical-layer complaint dressed up as a protocol problem, and chasing them in the register map wastes an afternoon.

An exception response is the opposite: proof the ADU arrived intact. The slave decoded the wrapper, read the PDU, and refused the request on its merits - an unsupported function, an address outside its map, a value it will not accept. That answer lives entirely inside the PDU, which is why a Modbus exception code looks identical on serial and on TCP. Silence points at the transport; an exception points at the request. Sorting every fault into one of those two buckets before touching anything is the fastest triage there is.

Where the Size Limits Come From

The specification fixes the maximum serial ADU at 256 bytes. Subtract the one-byte slave address and the two-byte CRC and the PDU may occupy at most 253 bytes - and that 253-byte ceiling was carried over to TCP unchanged, even though TCP could easily haul more, so that a gateway never has to split or refuse a legal PDU when re-wrapping it. Every per-request limit in Modbus falls out of that arithmetic, including the familiar register-per-read cap.

This has a practical consequence for driver and poll-plan design: the limits are properties of the PDU, not of the transport you happen to be on. Moving a serial device behind a TCP gateway does not raise its ceilings, and a request that is legal on one transport is legal on the other. Budget your polls around the PDU and the transport takes care of itself.

Frequently Asked Questions