Exception responses

An exception response is a normal Modbus response saying the server received the request but didn’t process it. In PDComm, a request or execute that receives one succeeds with a result like this:

{"ok":true,"result":{"response":[131,2],"source":"wire","status":"exception"}}

• response[0] is the request’s function code plus 128 (0x80); 131 is an exception to function 03.
• response[1] is the exception code.
• Don’t stop at ok; your application must check status.

PDU, ADU and function codes defines the exception codes.

01 Illegal Function

When a PDComm server sends it

• An unsupported function code: user-defined codes (65–72, 100–110), MEI 13 or an undefined code. Example: 5A → [218,1]
• An unsupported diagnostics sub-function (such as 19) or MEI type
• A serial-line-only function (07, 08, 11, 12, 17) sent to a TCP server. Example: 0800001234 → [136,1]
• With Modbus/TCP Security, a function the client’s role isn’t allowed. Example: 06 from reader → [134,1]
• A serial-line-only function sent to a gateway

What to check

• Check that the device manual lists the function. Many devices support 03 but not 04 or 16.
• Make sure you aren’t using a serial-line-only function over TCP.
• On a secure connection, check that the server’s roles or null_role contains the function and that the client certificate carries the role you expect.

02 Illegal Data Address

When a PDComm server sends it

• The start address plus the quantity leaves the table range of the server model. The default model covers 0–1023 in every table. Example: 0304000001 → [131,2]
• A missing file number or record, or a file request whose reference type isn’t 6
• A missing FIFO pointer address. Example: 1800FF → [152,2]
• An MEI 14 individual read of an object that doesn’t exist

What to check

• When you converted the manual address to a PDU address, did you subtract 1 and drop the table prefix digit? See Wrong address.
• Devices often implement only parts of an address range. If a multi-register read returns 02, try reading smaller ranges.
• For a PDComm server, check the table’s start and number of values with data_get.

03 Illegal Data Value

When a PDComm server sends it

• A quantity of 0 or above the limit (read 2000 bits or 125 registers, write 1968 bits or 123 registers). Example: 0300000000 → [131,3]
• A byte count that doesn’t match the data length. Example: 0F0000000101 → [143,3]
• A function 05 value other than FF00 or 0000. Example: 0500000001 → [133,3]
• A PDU whose length doesn’t fit the function. Example: 030000 → [131,3]
• An MEI 14 read code outside 1–4, or an individual read (4) on a model that doesn’t allow individual access

What to check

• Count the PDU bytes again; 16-bit values go high byte first.
• A device may accept smaller quantities than the standard limits. Check the manual’s maximum.

Note

A PDComm client catches such malformed requests before sending them and returns service errors such as Value or Length instead. You mostly see exception 03 from execute or from other clients. See Request PDU checks.

04 Server Device Failure

The server hit an unrecoverable error while processing the request. The default PDComm server sends it only when its internal data is inconsistent, which can’t happen with a model that passed model_set validation. From a real device, check the device’s state and diagnostics.

05 Acknowledge, 06 Server Device Busy

• 05: the device accepted a long-running request; query the result later. A PDComm server never sends it.
• 06: the device is busy. A PDComm gateway sends 06 when its queue (64 requests) is full.

In both cases, don’t blindly resend writes. Check the state the way the device manual describes, then let your application decide whether to send again.

08 Memory Parity Error

The device found a parity error in file record memory. A PDComm server never sends it. For a real device, follow its diagnostics or repair procedure.

0A Gateway Path Unavailable

When PDComm sends it

• A PDComm TCP server received a unit identifier that is neither its configured unit nor a direct-addressing value, 255 (0xFF) or 0. Example: unit 2 → [131,10]
• A PDComm gateway has no entry for the unit in routes.

What to check

• Match the client’s unit identifier to the server’s unit or the gateway routes. When you address a PDComm server directly, 0xFF also works. A gateway forwards 0xFF only when a route lists it.
• For a gateway, check that the route table contains the TCP unit.

0B Gateway Target Device Failed to Respond

When a PDComm gateway sends it

• The serial device didn’t answer within the gateway’s timeout_ms, its reply was corrupted, or the serial port failed.
• The request’s time ran out while it waited in the queue.

What to check

• Check that a device really exists at the route’s serial address and uses the gateway’s serial settings.
• In the gateway’s trace, look for tx to that address without a following rx.
• Give the TCP client a longer timeout_ms than the gateway’s serial wait so you receive 0B instead of a timeout.

Unknown exception codes

The specification defines exception codes 01–06, 08, 0A and 0B. A device can send other codes, such as the legacy 07 or a vendor-specific code. A response that holds the function code + 128 followed by one code byte is still an exception response (Modbus Application Protocol V1.1b3 §7), so a PDComm client returns it with "status":"exception" and the code exactly as received in response[1]. For example, code 07 for function 03 gives [131,7]. Look up what the code means in the device manual.