{"id":3660,"date":"2026-10-29T13:00:00","date_gmt":"2026-10-29T05:00:00","guid":{"rendered":"https:\/\/cnbygele.com\/?p=3660"},"modified":"2026-10-28T19:08:01","modified_gmt":"2026-10-28T11:08:01","slug":"modbus-coherent-snapshot","status":"publish","type":"post","link":"https:\/\/cnbygele.com\/fr\/blog\/modbus-coherent-snapshot\/","title":{"rendered":"Lectures coh\u00e9rentes des registres des compteurs Modbus : \u00e9viter les valeurs incoh\u00e9rentes"},"content":{"rendered":"

A coherent Modbus meter read must return the words of a value, and any related measurements used together, from a compatible update state. Reading adjacent registers in one request reduces opportunities for mixed reads, but the protocol alone does not guarantee a meter-wide simultaneous measurement snapshot. Confirm the exact device’s documented update and buffering behavior before treating a returned block as atomic.<\/p>\n

This distinction matters when energy counters cross word boundaries or when a calculation combines values that change at different times. A response can have correct length and valid transport checks while still containing a combination that is unsuitable for the intended calculation. Begin with the power meter Modbus setup guide<\/a> to establish addressing and basic interpretation before investigating consistency.<\/p>\n

Separate three kinds of consistency<\/h2>\n

The first question is whether a multiword number is internally consistent. A 32-bit value might occupy two 16-bit registers. If the client reads each word independently while the source changes, the assembled result could combine words from different versions. Word order and scaling can be correct and the value can still be wrong because the pieces were captured at different moments.<\/p>\n

The second question is whether related quantities share a useful measurement window. Voltage, current and power may have different refresh paths or averaging periods. A coherent two-word power value does not prove it was measured at exactly the same instant as a separately read current value. Decide which timing relationship the application actually requires.<\/p>\n

The third question concerns the complete data path. A gateway might poll the meter once, cache the result and answer many clients. The client’s transaction time then describes its interaction with the gateway, not necessarily the meter’s measurement time. Avoid describing all three issues simply as communication errors; each requires different evidence and a different remedy.<\/p>\n

What the Modbus specification establishes<\/h2>\n

The Modbus Application Protocol Specification<\/a> defines register read requests and their responses. Function 03 reads holding registers and function 04 reads input registers. The returned structure identifies the data bytes belonging to that request. These transport definitions do not describe every manufacturer’s internal measurement refresh architecture.<\/p>\n

Use the specified function, starting address and quantity from the exact register map. Do not combine an entire address range merely because a request can express it. A range may cross unsupported locations, different data groups or implementation boundaries. Respect the instrument’s documented request limits and timing; the protocol’s general limits do not establish the capability of a specific model.<\/p>\n

The CNBYG BY194 family<\/a> includes optional RS485\/MODBUS communication. The family product page is not evidence of a particular multiword encoding, latch function or snapshot guarantee. Ask for the applicable firmware-specific register map and update description. This article supplies an integration review method without assigning undocumented behavior to the instrument.<\/p>\n

\"Disconnected
Product-reference illustration of the disconnected BY194 front exterior beside multiword read consistency review records. Props illustrate the review process and do not establish installed interfaces, snapshot guarantees, backup functions or gateway features.<\/figcaption><\/figure>\n<\/p>\n

Understand a torn counter with a bounded example<\/h2>\n

Consider a hypothetical unsigned 32-bit counter stored as a high word and low word, with no additional scale. Its value is high word multiplied by 65,536 plus low word. Just before a boundary, the words might be 0 and 65,535. After one increment, they become 1 and 0. These are illustrative register values, not a BY194 register assignment.<\/p>\n

If separate reads capture the old high word and the new low word, the client assembles zero. If they capture the new high word and old low word, the client assembles 131,071. Neither is the true boundary value. The error arises from mixed versions rather than a bad multiplication factor. Keeping raw words and request times allows the reviewer to recognize that distinction.<\/p>\n

A large apparent jump can also result from reset, rollover, wrong type, missing words or mapping errors. Do not diagnose a torn read from the graph alone. Compare raw evidence, device documentation and the circumstances of the transition. The energy counter rollover guide<\/a> helps keep normal counter limits separate from an inconsistent capture.<\/p>\n

Choose the narrowest supported read strategy<\/h2>\n

Start by requesting all words of one value together when the register map permits that operation. Decode only after the complete successful response has been validated. A partial, timed-out or mismatched response must not update half of the application’s stored number. The application should publish either a complete accepted value or a clearly identified failure state.<\/p>\n

A documented snapshot or latch feature may provide a stronger guarantee, but using it can involve a specific sequence, additional status checks or a state-changing command. Follow the exact manual and change-control process. Do not experiment with writes to production equipment in an attempt to discover whether an undocumented latch exists.<\/p>\n

Some implementations document a version counter or consistency indicator. Its location, ordering rules and rollover behavior must be specified before a client can use it reliably. A generic repeated-read trick is not a universal replacement for those rules. If the source updates continuously or uses an unexpected order, repeated equal words can still give misleading confidence.<\/p>\n

\n\n\n\n\n\n\n\n\n\n
Situation<\/th>\nUseful evidence<\/th>\nAppropriate response<\/th>\n<\/tr>\n<\/thead>\n
Separate requests assemble one number<\/td>\nRaw words and per-request times<\/td>\nUse one supported block read and verify documented consistency<\/td>\n<\/tr>\n
One block still shows unexplained jumps<\/td>\nDevice refresh and buffering description<\/td>\nObtain model-specific clarification and preserve questionable samples<\/td>\n<\/tr>\n
Related quantities appear inconsistent<\/td>\nAveraging windows and update times<\/td>\nAlign the calculation inputs or mark them unsuitable for comparison<\/td>\n<\/tr>\n
Two clients disagree<\/td>\nGateway cache age and routing<\/td>\nTrace which source instance and update each client received<\/td>\n<\/tr>\n
Partial response reaches the decoder<\/td>\nRequest and response lengths<\/td>\nReject the incomplete sample; retain the last value only with explicit quality<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Preserve evidence before changing the system<\/h2>\n

Record the device identity, firmware, map revision, client version and gateway route. Retain each diagnostic request with its function, start address, quantity, response bytes and local capture time. Where available, preserve a documented source timestamp or sequence value separately. Keep timezone and clock synchronization evidence so that two logs can be compared meaningfully.<\/p>\n

Limit diagnostic collection to approved reads at a rate the network can support. A very aggressive test can increase timeouts and produce a new problem that masks the original one. The polling interval guide<\/a> discusses bus capacity and update rates; a faster client request does not necessarily create a newer measurement inside the instrument.<\/p>\n

State the diagnostic hypothesis in advance. For example, suspect that two separate reads cross an energy counter update boundary, then compare with a supported contiguous read under comparable operating conditions. Change one variable at a time. Record whether the suspected anomaly disappears, persists or cannot be reproduced, without treating a short quiet period as proof of correctness.<\/p>\n

Distinguish numeric decoding from snapshot behavior<\/h2>\n

Verify address offset, data type, word order, signedness, units and scale before attributing a discrepancy to timing. A stable but implausible value is often a mapping issue. A value that changes dramatically only near a word boundary may justify a consistency investigation, but both conditions can coexist if a client configuration has more than one error.<\/p>\n

Keep the raw register pair and the decoded result in the same diagnostic record. This lets a reviewer recompute the interpretation without recollecting the event. Document the decode formula or format reference rather than a screenshot of the final dashboard alone. A numerical display hides whether the application silently reused an old word or substituted a default.<\/p>\n

Reject nonfinite or otherwise invalid values according to the documented data contract. Do not smooth an impossible jump just to make a report look plausible. A filter can reduce visible noise while concealing an actual integration error. Preserve the original sample, its quality state and the reason it was excluded from subsequent calculations.<\/p>\n

Test the calculation, not only the transport<\/h2>\n

An acceptance test should identify the quantity that depends on coherence. A total energy display may require internally consistent counter words. A phase comparison may require an agreed measurement window. A transient investigation may require capabilities beyond the ordinary polling interface. Write those needs explicitly so that a successful register reply cannot be mistaken for satisfying every use case.<\/p>\n

Use a safe test arrangement with controlled or independently observed changes where feasible. Include transitions relevant to the suspected failure, such as a counter word boundary, but do not alter production counters to manufacture one. A software simulator can test the client’s response assembly logic; it cannot prove how the real meter buffers its measurements.<\/p>\n

\"Disconnected
Product-reference illustration of the disconnected BY194 front exterior beside multiword read consistency review records. Props illustrate the review process and do not establish installed interfaces, snapshot guarantees, backup functions or gateway features.<\/figcaption><\/figure>\n<\/p>\n

NIST’s OT security guidance<\/a> provides the wider context for controlled changes and dependable operational information. In this workflow, keep the approved map, test configuration and results together. If exact consistency semantics remain undocumented, record that limitation and avoid using the channel for calculations that require a stronger guarantee.<\/p>\n

Report uncertainty in the downstream system<\/h2>\n

Store value, quality, source identity and time information as separate fields. An incomplete or questionable read should not become an ordinary valid zero. If the application retains the last accepted value, preserve its original acquisition time and indicate that it is old. Otherwise the dashboard can make a failed consistency check look like a stable operating condition.<\/p>\n

For derived quantities, define how input quality propagates. A calculation should not report a fresh valid result when one required input is rejected or belongs to an incompatible window. Keep the policy visible to operations and reporting owners. This is especially important when automated summaries hide individual raw records and display only a daily or monthly total.<\/p>\n

Further learning: timing can change correctness<\/h2>\n

Computerphile’s lesson on race conditions explains why the order and overlap of operations can affect results. It is conceptual background for the mixed-read example, not a Modbus implementation specification. The exact meter documentation and controlled acceptance evidence determine which consistency claim is justified.<\/p>\n