Modbus Exception Code 04 (Device Failure)
Exception code 04, slave device failure, is the Modbus error a device returns when it accepted a perfectly valid request but could not carry it out because something inside the device went wrong. Unlike the request-side exceptions, code 04 points at the device itself. This reference explains what triggers exception 04, why it differs from codes 01 through 03, and where to look when it appears.
Modbus Exception Code 04 Slave Device Failure in one line: Modbus exception code 04, slave device failure, means the device received a valid request but encountered an unrecoverable internal error while processing it, such as a hardware fault or a failed sensor behind the register. Unlike exceptions 01, 02, and 03, which point at the request, code 04 points at the device: the request was legitimate but the device could not complete it.
What Triggers Exception 04
When a device returns exception 04 it is telling you the request was well formed and targeted a real address, but the device hit an internal problem while trying to fulfill it. Typical causes are a hardware fault, a sensor or subsystem behind the register that has failed, or an unrecoverable firmware error. The request is not the problem, which is exactly what makes exception 04 different from the others: it moves the investigation from the Modbus map to the device itself.
This is why a poll that worked yesterday and suddenly returns exception 04 is a strong signal that the field device has developed a fault, not that anyone changed the register map. The place of code 04 among the full set of error responses is laid out in the Modbus exception code reference.
How Exception 04 Differs From 01, 02, and 03
Exceptions 01, 02, and 03 all describe something wrong with the request. Illegal function means the device does not support that operation, illegal data address means the requested address does not exist, and illegal data value means the value or quantity is out of range. Each of those is fixed by changing the request, and each has its own troubleshooting path. Exception 04 is categorically different, because there is nothing wrong with the request to change.
The practical consequence is that retrying an identical request after exception 04 will often just reproduce the error until the underlying device fault is cleared, whereas retrying after fixing a code 02 with a corrected address should succeed. When exception 04 persists, the next steps are device-side: check the device's own diagnostics, power-cycle if appropriate, and inspect the sensor or subsystem the failing register represents. The device's own error counters, readable through the diagnostics command, can corroborate a hardware issue, as covered in the Modbus TCP vs RTU comparison for the serial CRC side of link health.
Frequently Asked Questions
Does exception 04 mean my register map is wrong?
No. Exception 04 means the request was valid and reached a real address, but the device hit an internal fault trying to fulfill it. A wrong map produces exception 02 illegal data address instead. So code 04 directs you to the device itself, its hardware, sensors, or firmware, rather than to the Modbus addressing.
Why did a working poll suddenly start returning exception 04?
Because the request has not changed but the device has. A poll that succeeded yesterday and now returns exception 04 strongly suggests the field device developed a fault, such as a failed sensor behind the register or a hardware problem. The fix is on the device side, not in the SCADA configuration or the register map.
Should I retry after an exception 04?
A retry can catch a transient glitch, but if exception 04 persists it will keep reproducing until the underlying device fault is cleared. Unlike a request-side exception you can fix by correcting the request, code 04 needs device-side attention: check the device diagnostics, inspect the failing subsystem, and power-cycle if the situation warrants it.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- Modbus Application Protocol Specification - Modbus Organization
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.