Modbus Exception Responses: Read the Two Bytes Separately

Modbus Exception Responses mark a request that received an error reply from the addressed device. In the serial frame described by Siemens, two adjacent bytes tell different parts of that story. The first is the response function byte with its highest bit set. The second is a separate exception code describing the reported reason. Reading the bytes independently makes it possible to tell what type of reply was received and what the device said about the request.

The high bit marks the reply as an exception

Modbus messages carry a function code that identifies the requested operation and gives the following data a particular structure. The Siemens example returns a modified function byte for a recognized request error. It keeps the lower bits from the request function while setting the highest bit. That bit has the hexadecimal value 0x80 in an eight-bit byte.

For an illustration, use an invented record in which the logged request function is 0x03 and the saved response function byte is 0x83. The low bits still identify function 0x03. The high bit tells the reader that the following data should be read as exception information. The value 0x83 on its own does not say which exception occurred. It has to be interpreted at the function-byte position in a response.

The next byte supplies the reported reason

In the Siemens example frame structure, the modified function code is followed by one exception byte. Code 0x01 denotes an illegal function in its table. Code 0x02 denotes an illegal data address. Code 0x03 denotes an illegal data value. These code names identify different questions. A requested function can be unavailable even when the rest of the message is understandable. An address can be rejected for a supported function, and a value error concerns the request data in the context the server implements.

Another useful distinction concerns the name Read Exception Status. The Schneider page lists it as a specific requested function that returns status data in its supported context. An ordinary reply to a request with that name can contain the requested status bits. An exception response has its own marked function byte and reason byte. Seeing the word exception in the requested operation is therefore insufficient to choose how to decode the response.

In the invented record, suppose the next byte after 0x83 is 0x02. Reading 0x02 as the next register value would hide the meaning of the response. The exception tells the reader that the device reported an address problem for the identified function. It does not by itself identify which requested address or range boundary was unacceptable. That interpretation still depends on the saved request and the relevant device documentation.

The same product can distinguish errors by connection and request

Schneider Electric's SCADAPack E explanation gives a product-specific example. Its documentation describes a function that is supported on the product's serial slave connections but returns an illegal-function exception over its Modbus TCP connection. In the serial case, some unsupported subfunctions return an illegal-data-value exception. The product page also describes a particular data-length condition that produces no reply.

That example shows why the transport and device family belong with a decoded message. A data display can put the same operation name next to two connection types, but the implementation determines which operations the server accepts. The example also separates two observations that could otherwise share one generic label in a log. Receiving an explicit exception byte is different from having no response bytes to interpret.

Keep an unanswered request separate from an error reply

In the Siemens description, a serial client waits for a response during a monitoring interval. A captured exception frame supplies evidence of a reply carrying a reason byte. An expired wait with no received frame supplies no such byte. The time record can state how long the client waited. It cannot be decoded into an exception value that never arrived.

These distinctions matter when several layers write to one diagnostic record. The address and checksum in a serial frame belong to the surrounding frame format. The modified function code and exception byte carry the application-level information in the example. A message from local software about an expired wait may look like an error code in a display, but it comes from a different observation than an exception sent by the device.

A readable training record can preserve the source of each number, mark which byte was the response function and which was the exception, and leave the exception field empty when no reply was observed. The result distinguishes the operation involved, the server's reported response and the client's own timing record. Further examples are available in the robot communication learning collection and the technical article archive.

Primary sources Siemens STEP 7 Modbus communication and exception-frame documentation and Schneider Electric SCADAPack E documented function responses.