{"id":3636,"date":"2026-10-28T09:00:00","date_gmt":"2026-10-28T01:00:00","guid":{"rendered":"https:\/\/cnbygele.com\/?p=3636"},"modified":"2026-10-27T20:00:17","modified_gmt":"2026-10-27T12:00:17","slug":"modbus-exception-codes","status":"publish","type":"post","link":"https:\/\/cnbygele.com\/ru\/blog\/modbus-exception-codes\/","title":{"rendered":"\u041a\u043e\u0434\u044b \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0439 Modbus \u0438\u0437\u043c\u0435\u0440\u0438\u0442\u0435\u043b\u044f \u043c\u043e\u0449\u043d\u043e\u0441\u0442\u0438: \u0434\u0438\u0430\u0433\u043d\u043e\u0441\u0442\u0438\u043a\u0430 \u043e\u0442\u043a\u043b\u043e\u043d\u0451\u043d\u043d\u044b\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432"},"content":{"rendered":"

Power meter Modbus exception codes indicate that a device received a request but could not carry out the requested operation. They are different from a timeout, a damaged serial frame or a value decoded with the wrong byte order. Start by saving the exact request and response, then check the exception against the register map for the installed meter variant. Do not change protection settings, reset counters or issue write commands simply to make the error disappear. A read-only investigation usually provides a safer, clearer route to the cause.<\/p>\n

This guide explains how to recognize an exception response, separate protocol errors from communication failures, and prepare evidence that a meter supplier or integration engineer can actually use. It does not provide a BY194 register map or claim that every device supports every function described in the protocol.<\/p>\n

Identify what actually came back<\/h2>\n

A normal response and an exception response have different structures. The Modbus Application Protocol specification<\/a> defines the exception function code as the requested function code with its most significant bit set. The exception data then identifies the reported condition. For example, an exception to function 03 uses function 83 hexadecimal. That example describes protocol framing, not an address or a capability of a particular meter.<\/p>\n

First confirm that the response belongs to the request under investigation. On a serial bus, compare device identity and the captured frame. Across a TCP gateway, retain transaction identifiers and routing details as well. A gateway may report its own problem rather than return an exception generated by the meter. The distinction matters because a valid gateway response does not prove that the downstream instrument was reachable.<\/p>\n

A timeout contains no valid response to classify. A CRC failure means the received serial message failed an integrity check and should not be accepted as an application response. A valid normal response containing an implausible measurement raises different questions: address, type, scaling, units and data freshness. Keep those categories separate in the incident record.<\/p>\n

\"Disconnected
Product-reference illustration of the disconnected BY194 exterior with response-review materials. Context objects illustrate a review process; they do not establish installed interfaces, wiring, register formats, error diagnostics or measurement capabilities.<\/figcaption><\/figure>\n<\/p>\n

Read the code without overdiagnosing it<\/h2>\n
\n\n\n\n\n\n\n\n\n\n\n
Exception<\/th>\nProtocol meaning<\/th>\nUseful first check<\/th>\nWhat the code does not establish<\/th>\n<\/tr>\n<\/thead>\n
01<\/td>\nIllegal function<\/td>\nCompare requested function with the device manual<\/td>\nThat the meter hardware is defective<\/td>\n<\/tr>\n
02<\/td>\nIllegal data address<\/td>\nCheck starting offset and complete requested range<\/td>\nThat changing only the device address will help<\/td>\n<\/tr>\n
03<\/td>\nIllegal data value<\/td>\nCheck request structure and permitted quantity or field values<\/td>\nThat the measured voltage or current is outside range<\/td>\n<\/tr>\n
04<\/td>\nServer device failure<\/td>\nPreserve evidence and follow manufacturer diagnostics<\/td>\nA specific failed component<\/td>\n<\/tr>\n
05 or 06<\/td>\nAcknowledge or server device busy<\/td>\nCheck whether that operation and response are documented<\/td>\nPermission to retry indefinitely<\/td>\n<\/tr>\n
0A or 0B<\/td>\nGateway path or target response problem<\/td>\nInvestigate the gateway route and downstream link<\/td>\nThat the application register exists<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

The labels and distinctions above follow the application protocol specification. Their occurrence and handling depend on implemented functions and device documentation. Some codes are relevant to operations that a particular power meter may never support. Never build troubleshooting instructions around the assumption that all listed codes can occur on the installed model.<\/p>\n

Code 03 is particularly easy to misread. In this context, \u201cdata value\u201d concerns the request field or structure that the server rejected. It is not a general alarm stating that the measured physical quantity is unsafe. Operational electrical alarms must be interpreted using the meter manual and the installation’s protection arrangements.<\/p>\n

Check the complete read request<\/h2>\n

Record the function, starting address and requested quantity together. Checking only the first register can miss a range crossing an unsupported boundary. A read beginning at a valid location may still include a reserved register, exceed a device-specific supported block, or split a value that requires a documented access pattern.<\/p>\n

Work from the exact variant’s manual, including its revision and any communication-option details. Printed register references may use a human numbering convention that differs from the offset transmitted in the message. Use the separate register address offset guide<\/a> to document that conversion explicitly. Do not try a sequence of guessed offsets on a production system without an approved, bounded test plan.<\/p>\n

Choose one manufacturer-documented read-only item as a baseline. Verify the requested function and allowed quantity. If the baseline works and the intended block fails, compare the two requests rather than changing baud rate, wiring and register addressing at the same time. One controlled difference provides much stronger evidence than a broad configuration reset.<\/p>\n

When the entire integration fails, also verify the basic power meter communication setup<\/a>. A communications option listed on a product page is not proof that a particular supplied unit includes it, has the expected configuration or uses the map found for a different variant.<\/p>\n

Distinguish meter rejection from gateway rejection<\/h2>\n

Document every intermediary between software and instrument. Include the gateway model, communication mode, routing identifier, relevant firmware revision and the ownership of configuration changes. A serial device address can be translated or selected through a gateway setting; a request sent to the wrong downstream route may produce a gateway error even when the network connection is healthy.<\/p>\n

Collect gateway logs where available, but avoid assuming undocumented counters or diagnostics exist. Compare the gateway’s own response with an approved capture at the downstream boundary if the installation supports that procedure. Such work should be performed by the responsible controls team without disrupting a shared bus or exposing an operational network.<\/p>\n

An immediate exception and a delayed timeout call for different next actions. The immediate exception may show that the target understood enough of the request to reject it. A timeout may result from routing, device availability, line configuration or a lost response. Neither observation alone identifies a faulty instrument. Preserve timings as observations rather than turning them into unsupported response-time specifications.<\/p>\n

Use bounded retries and escalation<\/h2>\n

Repeatedly sending an invalid request does not improve its validity. For illegal function or illegal address responses, stop the affected request and compare it with the manual before retrying. For a documented temporary busy condition, use the manufacturer’s recommended delay, a maximum attempt count and a clear escalation path. Do not treat a busy response as permission for unlimited polling.<\/p>\n

A shared bus may contain several clients or gateways, so coordinate any investigation. Prevent an integration retry loop from overwhelming equipment or hiding the original fault in a large log. Keep the first failure, the controlled changes and the final result. A successful later read should not erase the evidence needed to explain why the first request was rejected.<\/p>\n

The Modbus serial line specification<\/a> helps distinguish message framing and integrity from application exceptions. Use it alongside the device manual, rather than treating a valid serial frame as proof that every requested application operation is supported.<\/p>\n

Build a supplier-ready evidence package<\/h2>\n

A useful support request includes the meter model and variant, serial number where appropriate, manual revision, installed communication option, firmware information if available, and the intended measurement. Add the exact register reference as printed in the manual and the actual starting offset and quantity sent by the client.<\/p>\n

Attach one request and its corresponding raw response with a timestamp and consistent hexadecimal notation. State whether the capture was taken at the client, gateway or serial interface. Include the expected response based on the manual, the exception observed, the bounded tests already performed and their outcomes. Remove credentials, sensitive network details and unrelated operational data before sharing the package.<\/p>\n

For CNBYG BY194 multifunctional instruments<\/a>, the public product information identifies optional RS485\/MODBUS communication. Obtain the documentation for the actual ordered configuration before selecting functions or registers. The product photograph cannot establish protocol support, installed options, terminal assignment or exception behavior.<\/p>\n

\"Disconnected
Product-reference illustration of the disconnected BY194 exterior with response-review materials. Context objects illustrate a review process; they do not establish installed interfaces, wiring, register formats, error diagnostics or measurement capabilities.<\/figcaption><\/figure>\n<\/p>\n

Verify the correction before reopening collection<\/h2>\n

After a documented correction, repeat the original approved read and compare the response structure with the expected format. Confirm that the result comes from the intended instrument and represents the intended measurement. Check units, scaling and interpretation separately; eliminating an exception does not establish measurement accuracy.<\/p>\n

For multi-register values, continue with byte and word order verification<\/a> rather than judging success from a plausible number. Compare readings against an appropriate trusted reference under stable conditions and record the acceptance criteria chosen by the project. A single coincidentally reasonable value is weak evidence.<\/p>\n

Restore ordinary collection gradually, review whether exceptions recur, and retain the final request definition in the integration record. If a different exception appears, open a separate diagnostic branch instead of overwriting the previous explanation. This keeps future maintenance work reproducible and makes replacement instruments easier to integrate correctly.<\/p>\n

Further learning: integrity failures versus rejected requests<\/h2>\n

The neutral educational lesson below explains how transmission errors can be detected. It supports the distinction made earlier: an integrity failure is different from a validly received application exception. The lesson does not define Modbus exception codes or replace the protocol documents; use it as background for keeping those diagnostic branches separate.<\/p>\n