{"id":3616,"date":"2026-10-27T09:00:00","date_gmt":"2026-10-27T01:00:00","guid":{"rendered":"https:\/\/cnbygele.com\/?p=3616"},"modified":"2026-10-26T19:07:24","modified_gmt":"2026-10-26T11:07:24","slug":"power-meter-modbus-address-offset","status":"publish","type":"post","link":"https:\/\/cnbygele.com\/ar\/blog\/power-meter-modbus-address-offset\/","title":{"rendered":"\u0625\u0632\u0627\u062d\u0629 \u0639\u0646\u0648\u0627\u0646 \u0633\u062c\u0644 Modbus \u0644\u0639\u062f\u0627\u062f \u0627\u0644\u0637\u0627\u0642\u0629: \u062f\u0644\u064a\u0644 \u0627\u0644\u062a\u062d\u0642\u0642 \u0644\u0644\u0642\u0631\u0627\u0621\u0629 \u0641\u0642\u0637"},"content":{"rendered":"

A power meter Modbus register address offset is the numeric address transmitted inside the protocol request. It can differ from the register reference printed in a manual or entered into monitoring software. Resolve the difference by identifying the register table, function code and numbering convention, then checking one documented read-only value against the actual request. Do not apply a universal \u201csubtract one\u201d rule to every driver. Some drivers already perform that conversion; others expect the transmitted offset directly. A correct response alone does not prove that the intended measurement was selected.<\/p>\n

This guide concerns address interpretation. For serial settings and physical communication, start with the power meter Modbus setup guide<\/a>. For interpreting the returned bytes, use the separate byte and word order guide<\/a>.<\/p>\n

Separate the three addresses on the commissioning sheet<\/h2>\n

A useful integration record has three different fields: the manual’s printed reference, the address entered into the client application, and the address actually transmitted. Calling all three \u201cregister number\u201d creates avoidable confusion. Keep the notation and number base beside each value. A hexadecimal entry copied into a decimal field can select an entirely different location while still producing a legitimate reply.<\/p>\n

The Modbus Application Protocol specification<\/a> distinguishes its data model from protocol addressing. Protocol data addresses start at zero. The relationship between application data and a device’s internal implementation is device dependent. Traditional references such as 40001 are a documentation convention; they are not necessarily the literal number that belongs in the two-byte starting-address field.<\/p>\n

The CNBYG BY194 instrument family<\/a> provides a relevant product context because its published description offers an optional RS485\/MODBUS interface. The product image and family description do not establish the register map of every supplied variant. Obtain the exact model, firmware and communication manual before building tags. Do not copy a register from another manufacturer’s meter merely because both products use Modbus.<\/p>\n

Read the table heading before entering a number<\/h2>\n

First identify whether the source describes holding registers, input registers, coils or discrete inputs. A number without its data table is incomplete. Function 03 and function 04 select different read operations in the standard protocol. A driver may combine table selection with a printed address prefix, or expose the function as a separate setting. Record both decisions.<\/p>\n

Next find the manual’s explanation of addressing. Look for worked requests, hexadecimal columns, statements about base zero or base one, and examples supplied for the recommended client. A worked packet is often more decisive than a column simply labelled \u201caddress.\u201d If two sections disagree, pause the affected tag and ask for clarification rather than changing every address in the project.<\/p>\n

\n\n\n\n\n\n\n\n\n\n
Evidence in the documentation<\/th>\nWhat to establish<\/th>\nCommissioning record<\/th>\n<\/tr>\n<\/thead>\n
A traditional register reference<\/td>\nWhich table the prefix denotes<\/td>\nReference and selected function<\/td>\n<\/tr>\n
A zero-based address column<\/td>\nWhether the client expects that exact offset<\/td>\nClient entry and transmitted address<\/td>\n<\/tr>\n
A one-based register number<\/td>\nWhere the client applies conversion<\/td>\nConversion rule with one worked example<\/td>\n<\/tr>\n
A hexadecimal starting address<\/td>\nWhether the client field accepts hexadecimal<\/td>\nBoth decimal and hexadecimal notation<\/td>\n<\/tr>\n
A measurement spanning several words<\/td>\nFirst address and required word count<\/td>\nStart, length and representation<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

This table is an interpretation checklist based on the protocol’s addressing model. It is not a BY194 register map. No addresses or supported functions for an individual CNBYG variant can be inferred from it.<\/p>\n

\"Disconnected
Product-reference illustration of the disconnected BY194 exterior. Context materials illustrate the review process; this image does not establish interface options, register formats, security capabilities or measurement specifications.<\/figcaption><\/figure>\n<\/p>\n

Work through a hypothetical conversion<\/h2>\n

Suppose a hypothetical manual explicitly says that its holding-register reference 40001 corresponds to transmitted offset zero. Under that stated convention, reference 40010 corresponds to offset nine. A client configured to accept traditional references might therefore need 40010, while a client configured for raw offsets might need 9. These are two ways of selecting the same documented starting location, not interchangeable entries for the same input field.<\/p>\n

Now suppose another hypothetical manual prints hexadecimal address 0010 and says the column already contains protocol offsets. The decimal equivalent is 16. Subtracting one would select offset 15 and introduce an error. The rule comes from the column definition and the client configuration, not from the appearance of the number.<\/p>\n

A real project should attach the relevant manual page and a saved client configuration to this calculation. Include the register quantity as well. For a hypothetical two-register measurement starting at offset nine, requesting one register returns only part of the representation. Reading the correct start with the wrong length is a different fault from using the wrong base.<\/p>\n

Verify with the smallest safe read<\/h2>\n

Begin on an approved maintenance connection with permission to access the instrument. Select a documented, read-only value that is available on the exact variant. Prefer a value with an independent comparison or recognizable identity. A measured current can be useful only when the relevant wiring, scaling and display interpretation are already understood. Zero under no load is weak evidence because many unrelated locations can also contain zero.<\/p>\n

Disable automatic writes, time synchronization writes and configuration discovery that changes settings. Confirm the destination identity and unit identifier. Save the client mode, function, start address and count before transmitting. A read-only test should remain read-only even if a software wizard suggests fixing an unexpected response by writing a value.<\/p>\n

Capture the request through a client log or an authorized protocol capture. Compare the transmitted starting address with the calculation on the commissioning sheet. For Modbus RTU, also retain the destination address and relevant serial parameters. The Modbus Serial Line guide<\/a> explains the transport framing; it does not replace the product’s application register map.<\/p>\n

Distinguish a valid reply from a valid measurement<\/h2>\n

A normal reply demonstrates that a request was accepted at some level. It does not demonstrate that the selected register is voltage, current, power or accumulated energy. A plausible number can result from an adjacent measurement, the wrong data type or a scaling coincidence. Validate meaning separately from transport success.<\/p>\n

Compare the decoded value with a stable display reading or another approved reference. Record the time and operating condition so that a changing load does not look like an address fault. If there is a discrepancy, retain the raw returned words before changing decoding settings. Raw evidence lets the next engineer distinguish an offset error from word order, signedness, multiplier or CT-ratio problems.<\/p>\n

An exception reply also needs careful interpretation. An illegal-address exception can be caused by an unsupported range or a request that crosses a permitted boundary. It does not prove that every address in the request is wrong. A timeout is a separate observation and should lead back to transport and destination checks before altering the map.<\/p>\n

Use adjacent checks without blind scanning<\/h2>\n

After proving one documented value, validate another nearby documented measurement. Keep its expected word count and type separate. This checks that the chosen convention works across a meaningful part of the map. It is more useful than confirming the same zero reading repeatedly.<\/p>\n

Do not scan undocumented register ranges simply to find numbers that look reasonable. Scanning can consume bus capacity, trigger unusual device behavior or create misleading confidence. Follow the manufacturer’s permitted request sizes and site access procedures. Use the polling interval guide<\/a> when returning the verified tags to a shared acquisition schedule.<\/p>\n

If a multi-register group fails, test smaller documented groups without splitting a value that must be read together. Record the boundary that causes the exception. The outcome may reveal a device range restriction rather than a base-numbering problem. Any conclusion about coherent snapshots still requires explicit device documentation.<\/p>\n

Build a register crosswalk that survives a software change<\/h2>\n

For every approved tag, retain the engineering name, manual revision, printed reference, table, function, transmitted offset, quantity, type, byte order, scale and unit. Keep configuration version and verification date alongside the data. An exported tag database without the driver’s addressing mode can be insufficient to reproduce the installation.<\/p>\n

When changing gateways or monitoring platforms, rerun the canary read before importing the complete tag list. Two products can label their input fields similarly while expecting different representations. Avoid mass subtraction or addition in a spreadsheet until the target driver’s behavior has been demonstrated with an actual request.<\/p>\n

\"Disconnected
Product-reference illustration of the disconnected BY194 exterior. Context materials illustrate the review process; this image does not establish interface options, register formats, security capabilities or measurement specifications.<\/figcaption><\/figure>\n<\/p>\n

Acceptance and purchasing questions<\/h2>\n

Accept the integration only when the selected value, raw request and independent comparison agree within the limits of the comparison method. This is a communication mapping acceptance, not a calibration certificate. Keep measurement accuracy assessment in the separate meter accuracy verification procedure<\/a>.<\/p>\n

Before ordering, request the exact interface option, register-map revision, supported read functions, addressing examples and available configuration export. Ask whether firmware changes can alter the map. Require the supplier to identify any reserved ranges and restrictions on grouped reads. A sample request and expected reply for the ordered variant can prevent substantial commissioning work later.<\/p>\n

Educational background: binary representation<\/h2>\n

The educational lesson below explains how computers interpret ordered bytes. It supports the distinction between selecting a register and interpreting its contents; it does not define meter addresses or substitute for a manufacturer’s register map. Address selection must be verified before changing representation settings.<\/p>\n