{"id":3700,"date":"2026-10-31T09:00:00","date_gmt":"2026-10-31T01:00:00","guid":{"rendered":"https:\/\/cnbygele.com\/?p=3700"},"modified":"2026-10-30T19:07:43","modified_gmt":"2026-10-30T11:07:43","slug":"meter-register-map-revision","status":"publish","type":"post","link":"https:\/\/cnbygele.com\/ar\/blog\/meter-register-map-revision\/","title":{"rendered":"\u0645\u0631\u0627\u062c\u0639\u0627\u062a \u062e\u0631\u064a\u0637\u0629 \u0633\u062c\u0644\u0627\u062a \u0639\u062f\u0627\u062f \u0627\u0644\u0637\u0627\u0642\u0629: \u0627\u0644\u062a\u062d\u0642\u0642 \u0645\u0646 \u062a\u0648\u0627\u0641\u0642 \u0627\u0644\u0628\u0631\u0627\u0645\u062c \u0627\u0644\u062b\u0627\u0628\u062a\u0629"},"content":{"rendered":"

A power meter Modbus register map must match the actual device model, installed options and firmware revision. A successful connection does not prove that a register represents the intended quantity. Before accepting readings, identify the instrument, obtain the applicable register document, record its revision, and compare a small set of documented values with an independent reference. Keep the approved map with the commissioning records so a future replacement or firmware change cannot silently alter interpretation.<\/p>\n

This guide explains a document and verification workflow. It does not supply undocumented addresses for any CNBYG instrument. The BY194 multifunctional power instrument family<\/a> is a relevant product reference, but the family page alone cannot establish a specific variant’s register layout, identification commands or supported data formats.<\/p>\n

For the overall integration workflow, start with the power meter Modbus communication guide<\/a>.<\/p>\n

Why communication success can hide a wrong map<\/h2>\n

Modbus defines transactions and data models; manufacturers assign the application meaning of individual data items. The Modbus Application Protocol specification<\/a> describes function codes and addressing, while the device documentation determines which measurements are implemented. These two levels of information are complementary. A generic protocol example is not a substitute for the meter’s communication manual.<\/p>\n

A response can contain the requested number of bytes and still be misinterpreted by the integration. A point may have changed meaning between documented revisions, an optional measurement may be absent, or the client may apply a scale intended for another model. These are possibilities to investigate, not claims that every firmware update changes registers. Many releases preserve compatibility. The acceptance question is whether compatibility is demonstrated for the exact installation.<\/p>\n

Do not infer correctness solely because values look plausible. A mislabeled quantity can remain within a familiar range for weeks. Instead, establish identity, documentation and a repeatable comparison before the data supports production decisions. The related Modbus meter integration guide<\/a> explains a different issue: interpreting documented multiword values after the correct map has been established.<\/p>\n

\"BY194
Product-reference illustration of the disconnected BY194 front beside manual revision control documents. Device-specific features and installed options require exact variant documentation.<\/figcaption><\/figure>\n<\/p>\n

Build a device and document identity record<\/h2>\n

Begin with the physical instrument and purchasing records. Record the exact model designation, serial or asset identifier, documented hardware options, communication interface and available firmware information. Obtain firmware information only through a method described for that variant. If it is unavailable from the front panel or documented interface, request confirmation from the supplier rather than guessing from the enclosure appearance.<\/p>\n

Then identify the register document. Save its title, revision, issue date, applicable models and source. A downloaded filename such as latest-manual.pdf is insufficient because it may later point to different content. Retain a local controlled copy and a file fingerprint so the team can distinguish two documents with the same name. File fingerprints establish file identity; they do not prove technical suitability or supplier authenticity.<\/p>\n

Create an explicit relationship between each asset and the approved document. Several instruments may share one map, but that relationship should follow documented applicability. Identical front panels are not evidence that option codes or firmware behavior are identical. This is particularly important when a replacement was ordered years after the original installation.<\/p>\n

Use an applicability checklist before reading points<\/h2>\n

The following qualitative checklist does not assert model-specific register behavior. It identifies evidence that should exist before the integration is accepted.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n
Check<\/th>\nEvidence to retain<\/th>\nDecision if evidence is missing<\/th>\n<\/tr>\n<\/thead>\n
Exact device variant<\/td>\nNameplate and order-code record<\/td>\nObtain supplier confirmation<\/td>\n<\/tr>\n
Firmware identity<\/td>\nDocumented readout or supplier statement<\/td>\nRecord uncertainty and hold affected points<\/td>\n<\/tr>\n
Register manual applicability<\/td>\nRevision and supported model list<\/td>\nRequest the correct manual<\/td>\n<\/tr>\n
Quantity definition<\/td>\nRegister description, units and sign convention<\/td>\nDo not label an inferred quantity<\/td>\n<\/tr>\n
Data representation<\/td>\nDocumented type, length, scaling and order<\/td>\nKeep decoding unapproved<\/td>\n<\/tr>\n
Optional features<\/td>\nVariant-specific option evidence<\/td>\nExclude unsupported measurements<\/td>\n<\/tr>\n
Commissioning comparison<\/td>\nReference observation and captured response<\/td>\nInvestigate disagreement before release<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Review the evidence as a set. A correct model designation cannot compensate for missing scaling instructions, and a plausible decoded value cannot compensate for an unexplained identity mismatch. Mark unresolved items individually so one unsupported point does not obscure the status of all other verified measurements.<\/p>\n

Compare map revisions deliberately<\/h2>\n

When two revisions exist, compare the sections that affect your point list. Start with applicability notes, change history, supported function codes, register ranges, data types, units, scaling, invalid-value conventions and write operations. Some changes only clarify wording. Others can affect the client configuration or require a new test. Record the actual difference instead of assuming that a newer date means a better match.<\/p>\n

Treat a revised manual and changed firmware as separate events. Documentation can change without a device update, and firmware may change while the published map remains compatible. The acceptance record should state which event occurred, what evidence establishes compatibility, and which points need retesting. Avoid rewriting all integration settings merely because a document was refreshed.<\/p>\n

For each affected point, maintain the old interpretation, new interpretation, reason for change and validation result. Preserve the original approved configuration until the new interpretation is accepted. The configuration backup workflow<\/a> provides a useful companion process for recording settings before replacement or maintenance; it does not establish that every meter offers automatic configuration export.<\/p>\n

Validate a small documented point set first<\/h2>\n

Select a bounded point set representing the measurements the project actually needs. Include different documented data representations if they are used, but do not probe arbitrary addresses in search of interesting values. An unsupported request can fail or behave differently across devices. Testing should use the permitted operations and respect the site’s operational constraints.<\/p>\n

Capture the request, response, timestamp, client configuration and displayed interpretation. Compare measurements with a suitable independent observation under sufficiently stable conditions. For an energy counter, compare an interval change rather than expecting two cumulative totals with different starting points to match. For a displayed measurement, account for refresh timing, rounding and the specified measurement boundaries.<\/p>\n

A comparison is diagnostic evidence, not a universal calibration certificate. The reference method, instrument accuracy, operating condition and timing limit the conclusion. Define acceptance tolerances from the project requirements and documented instruments rather than inventing a fixed percentage. Record the reason for every tolerance so another engineer can reproduce the decision.<\/p>\n

If several points disagree by the same factor, check documented scaling and transformer ratios. If only one field is inconsistent, review its definition, representation and option applicability. Avoid changing multiple settings simultaneously: a correct-looking result produced by compensating errors can be harder to detect than an obvious failure.<\/p>\n

Handle replacements and firmware changes as controlled events<\/h2>\n

Before a planned change, retain the accepted identity record, approved register document, point list and client configuration. Establish which measurements are essential to operations and how missing or uncertain data will be communicated during the work. Schedule changes through the site’s normal procedures, especially where readings feed alarms, billing reconciliation or automated decisions.<\/p>\n

After the change, repeat the identity check before restoring the previous point mapping. Do not assume the old configuration applies because the replacement shares a product family name. Confirm firmware and options, compare relevant documentation and rerun the bounded acceptance test. If compatibility remains unresolved, keep the affected data visibly unavailable rather than publishing unverified values.<\/p>\n

The NIST Guide to Operational Technology Security<\/a> supports configuration management and controlled change in operational environments. Apply those principles proportionately to the installation. They do not imply that one particular meter implements revision tracking, automatic rollback or secure firmware verification.<\/p>\n

\"BY194
Product-reference illustration of the disconnected BY194 front beside manual revision control documents. Device-specific features and installed options require exact variant documentation.<\/figcaption><\/figure>\n<\/p>\n

Keep a point-level acceptance package<\/h2>\n

An effective package contains more than a screenshot of reasonable numbers. Include device identity, document identity, point definitions, configured decoding, captured transactions, reference observations, acceptance criteria, test date and reviewer. Explain limitations such as inaccessible firmware information or a measurement that could not be exercised safely during the visit.<\/p>\n

Use clear point names that include the engineering meaning and unit. Keep the raw protocol address separate from the human-readable name. When the client uses a different address notation from the manual, document that translation explicitly; the separate register address offset guide<\/a> addresses that notation problem. A revision check and an address-offset check solve different risks and both may be needed.<\/p>\n

Assign an owner for future changes. The owner should know where the approved files are stored, which assets use them and what events trigger retesting. Useful triggers include firmware work, replacement, a changed gateway template, a revised register manual or unexplained measurement disagreement. A periodic review can confirm records remain accessible without needlessly disturbing an operating installation.<\/p>\n

Educational background on byte order<\/h2>\n

The following Computerphile lesson explains endianness, one of the representation details checked after a register document has been matched to the device. It helps explain why receiving bytes successfully does not establish the correct interpretation. Device-specific decoding must follow the applicable manual and the acceptance process above.<\/p>\n