{"id":3767,"date":"2026-11-02T19:13:52","date_gmt":"2026-11-02T11:13:52","guid":{"rendered":"https:\/\/cnbygele.com\/?p=3767"},"modified":"2026-11-02T19:13:53","modified_gmt":"2026-11-02T11:13:53","slug":"meter-diagnostic-capture-record","status":"publish","type":"post","link":"https:\/\/cnbygele.com\/th\/blog\/meter-diagnostic-capture-record\/","title":{"rendered":"\u0e1a\u0e31\u0e19\u0e17\u0e36\u0e01\u0e01\u0e32\u0e23\u0e27\u0e34\u0e19\u0e34\u0e08\u0e09\u0e31\u0e22 Modbus: \u0e01\u0e32\u0e23\u0e1a\u0e31\u0e19\u0e17\u0e36\u0e01\u0e2b\u0e25\u0e31\u0e01\u0e10\u0e32\u0e19\u0e04\u0e33\u0e02\u0e2d\u0e41\u0e25\u0e30\u0e01\u0e32\u0e23\u0e15\u0e2d\u0e1a\u0e01\u0e25\u0e31\u0e1a\u0e17\u0e35\u0e48\u0e40\u0e1b\u0e47\u0e19\u0e1b\u0e23\u0e30\u0e42\u0e22\u0e0a\u0e19\u0e4c"},"content":{"rendered":"

A useful Modbus diagnostic log connects each request and response to the correct meter route, timestamp, configuration and reported symptom. Capture enough context to reproduce the interpretation, while limiting collection to an authorized read-only investigation. A screenshot saying \u201ccommunication failed\u201d is rarely sufficient: the next engineer needs to distinguish a timeout, exception response, malformed frame, decoding error and application quality decision without guessing what was actually exchanged.<\/p>\n

This guide covers evidence capture and handover. It does not recommend scanning a live control network, sending undocumented requests or changing meter settings. Obtain site authorization, respect operational constraints and use supported diagnostic facilities. Electrical inspection and invasive network work belong to qualified personnel following the site’s procedures. Where passive capture is unavailable, work with the system owner on an approved alternative.<\/p>\n

Define the question before collecting packets<\/h2>\n

Write a short symptom statement. For example: a gateway reports a timeout for one read operation after a planned configuration change, while other devices remain available. Include the affected asset, start time, frequency, application message and expected behavior. This focuses collection on the relevant route and avoids accumulating large files with little diagnostic value.<\/p>\n

Separate communication success from useful engineering data. A valid response can still be decoded with the wrong byte order or associated with the wrong measurement. A good capture therefore records the request and response alongside the register-map revision, data type, scaling and application point. The guide to register-map revision control<\/a> explains how documentation drift can produce believable but incorrect values.<\/p>\n

Do not promise that one capture will establish the root cause. Intermittent faults may require several bounded observations under comparable conditions. Record what the evidence can and cannot prove, such as whether collection occurred upstream of a gateway rather than on the actual serial segment. That limitation is central to interpreting the result.<\/p>\n

Identify the observation point and protocol<\/h2>\n

Modbus RTU and Modbus TCP provide different evidence. A serial frame includes an error-checking field appropriate to the serial protocol. Modbus TCP uses its own application header and runs over TCP. A gateway may translate between them, so an upstream TCP trace does not necessarily show the complete downstream serial exchange or its timing.<\/p>\n

The Modbus serial line specification and implementation guide<\/a> explains serial addressing, frame handling and the request-response transaction model. Use it to classify the exchange, then use the exact meter manual for implemented registers and supported operations. Protocol documentation alone cannot establish a particular device’s register layout or tell you which optional features are fitted.<\/p>\n

Record the collection location in plain terms: gateway diagnostic export, application log, managed network capture or approved serial diagnostic facility. Include whether the source records original frames, decoded summaries or only application events. A decoded log may omit bytes needed to resolve an endianness dispute; a raw packet capture may omit the application quality decision that caused a dashboard alarm.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n
Evidence field<\/th>\nWhy it matters<\/th>\nCommon omission<\/th>\nAcceptance check<\/th>\n<\/tr>\n<\/thead>\n
Asset and full route<\/td>\nDistinguishes repeated addresses on different segments<\/td>\nAddress recorded without gateway port<\/td>\nRoute matches maintained configuration<\/td>\n<\/tr>\n
Measurement timestamp and clock basis<\/td>\nSupports event correlation<\/td>\nArrival time mistaken for sample time<\/td>\nTime zone and clock uncertainty documented<\/td>\n<\/tr>\n
Request and response or timeout<\/td>\nSeparates protocol outcomes<\/td>\nOnly the final error message saved<\/td>\nBoth sides linked where available<\/td>\n<\/tr>\n
Register-map revision<\/td>\nSupports decoding<\/td>\nGeneric family manual attached<\/td>\nExact variant documentation identified<\/td>\n<\/tr>\n
Application point and quality<\/td>\nExplains the displayed result<\/td>\nValid frame assumed to mean valid data<\/td>\nRaw exchange traced to reporting behavior<\/td>\n<\/tr>\n
Collection method and limitations<\/td>\nDefines what was observed<\/td>\nUpstream trace treated as downstream proof<\/td>\nObservation boundary stated explicitly<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Save a minimal configuration baseline<\/h2>\n

Before collection, export or record the relevant connection settings using authorized tools. Include destination, serial settings where relevant, function code, start address, quantity, timeout and retry policy. Record the software version or configuration revision if it affects decoding. Avoid exporting credentials into the evidence package; redact or exclude secrets using an approved process.<\/p>\n

Preserve the distinction between displayed register numbers and protocol offsets. An application may label a holding register with a human-oriented number while transmitting a different offset representation. Save both the configured field and the transmitted request when available. The article on Modbus address offsets<\/a> treats this interpretation problem separately.<\/p>\n

If a change occurred just before the symptom, retain both versions. A record saying \u201ctimeout increased\u201d is less useful than a controlled before-and-after configuration export. Do not make several trial changes before saving the initial state: that destroys the ability to connect observations with a specific configuration. Use a small approved test sequence with a rollback plan.<\/p>\n

\"BY194
Product-reference illustration of a disconnected BY194 front beside external modbus diagnostic logs review records. Surrounding records illustrate an engineering workflow; installed functions depend on exact variant documentation.<\/figcaption><\/figure>\n<\/p>\n

Collect without disturbing the operating bus<\/h2>\n

Prefer existing gateway or application diagnostics when they provide sufficient evidence. If a separate tool would initiate requests, verify that it will not become a competing controller on a serial segment. Connecting a laptop and polling alongside an operating controller can create the very faults being investigated. A monitoring tool is only passive if its actual configuration and connection method make it passive.<\/p>\n

Set a bounded collection period and a storage location with appropriate access. Include normal exchanges before and after a failure when practical. Stop according to the agreed limit rather than leaving indefinite collection running on production equipment. Note any loss of packets, dropped log entries or sampling limitations reported by the collection tool.<\/p>\n

The NIST OT security guide<\/a> provides a basis for managing operational constraints, monitoring and controlled changes. Diagnostic convenience does not override availability requirements. Work with the system owner when a capture needs a mirror port, physical access or a change to logging verbosity.<\/p>\n

Classify what the exchange actually shows<\/h2>\n

A timeout means that the expected response was not accepted within the defined window at the observed layer. It does not by itself prove a defective meter. Possible boundaries include a wrong route, unavailable device, serial contention, gateway behavior or an application timeout shorter than the actual transaction path. The capture should narrow these possibilities rather than label all of them \u201cno communication.\u201d<\/p>\n

An exception response is different: a device or intermediary returned a protocol-defined exception. Save the original function and exception code, then interpret them against the protocol and installed device documentation. The article on Modbus exception codes<\/a> explains why an exception is evidence of a particular exchange outcome, not a generic permission to try arbitrary writes.<\/p>\n

A valid response with an implausible value requires a decoding review. Retain raw register values and the application’s data-type interpretation. Compare units, scaling, word order and measurement scope. Do not edit the log to show only the corrected value. Keep the original evidence, the proposed interpretation and the acceptance observation together so another reviewer can repeat the reasoning.<\/p>\n

Prepare a package another engineer can use<\/h2>\n

Create a short index linking the symptom statement, route diagram, configuration revision, raw capture and decoded examples. Provide a small number of annotated exchanges rather than hundreds of unexplained screenshots. For each example, state the expected request, observed outcome and unresolved question. Include a normal exchange for comparison when one is available.<\/p>\n

Keep original files unchanged and create working copies for annotation. A file hash can help detect later changes to the saved package, but it does not prove the measurement was correct or that collection was complete. Record who collected the evidence, when it was exported and which system supplied it. Apply the site’s retention and access policy.<\/p>\n

\"BY194
Product-reference illustration of a disconnected BY194 front beside external modbus diagnostic logs review records. Surrounding records illustrate an engineering workflow; installed functions depend on exact variant documentation.<\/figcaption><\/figure>\n<\/p>\n

Request exact product support information<\/h2>\n

When investigating an installation from the BY194 multifunctional power instrument family<\/a>, provide the exact model, fitted communications option and relevant manual revision. Do not infer a diagnostic logging function, supported register or firmware identification command from a product-family photograph. Gateway logging and packet capture may be external capabilities.<\/p>\n

Include the bounded evidence package, the last known working configuration and the operational constraint on further testing. For the general connection workflow, consult power meter Modbus communication setup<\/a>. A precise support request helps separate product questions from route, software and interpretation issues without claiming that every symptom has the same cause.<\/p>\n

Check the handover package on a separate approved workstation before sending it for review. Confirm that file formats open, timestamps remain readable and redactions have not removed the route information needed to interpret the exchange. Keep sensitive connection details within the authorized support channel.<\/p>\n

Educational background<\/h2>\n

The following neutral lesson explains endianness. It supports the decoding part of a diagnostic review; it is not a Modbus implementation manual or a BY194 register reference.<\/p>\n