Chinese
Spanish
Russian
Portuguese
French
German
Indonesian
Thai
Vietnamese
Arabic
Italian
Turkish
Polish
Japanese
A PLC can receive a valid response from a radar while requesting the wrong register. Before changing byte order or applying a scale factor, check how the software converts the documented Modbus radar register addresses into the address sent in the request. An off-by-one request can return a neighbouring item without producing a communication timeout.
Keep three versions of the address visible
Record the reference printed in the device map, the number entered in the PLC driver and the resulting request address. They are not necessarily written the same way. A driver may expect a zero-based offset, a one-based item number or a register reference with a table designation. Its configuration and documentation determine the required entry.
The Modbus application protocol uses zero-based addresses in the request PDU. As a numbering illustration, the first register in a one-based sequence corresponds to request offset 0, the second to offset 1. This does not mean that an MV-RD12 level value is stored at either offset. The delivered device map must identify the actual item.
Do not subtract one twice. If the driver already converts a one-based entry into the protocol offset, manually reducing that entry changes the requested item. Likewise, a document that already supplies protocol offsets needs no additional conversion merely because another manual uses one-based references.
Check Modbus radar register addresses with the supplied electronics
The METRAVON MV-RD12 requires the corresponding RS485 electronics for Modbus communication. A two-wire 4-20 mA/HART configuration is a different interface. Obtain the map for the supplied electrical version and identify its revision and applicable firmware where available.
| Request detail | What to confirm |
|---|---|
| Device identity | The intended instrument and network address, not a copied tag from another tank. |
| Register table | The documented function and item; an equal numeric offset in another table need not refer to the same data. |
| Driver notation | The address convention accepted by that driver and the conversion it performs. |
| Start and count | The actual first requested address and the number of registers required by the documented item. |
| Returned meaning | The assigned variable, representation, units and validity information for that item. |
Inspect a read request before interpreting its response
Use an approved read-only commissioning method. Where the driver, gateway or diagnostic tool can show the request, retain its device address, function, starting offset and quantity with the configuration entry. Distinguish decimal and hexadecimal notation in the record. For example, hexadecimal 0x0010 represents decimal 16; it does not represent decimal 10.
Compare those fields with the actual map before changing the decoding. A wrong function or starting offset is an addressing problem. Once the request is correct, use the documented data type, word order and conversion. The separate radar value-decoding checks address those representation errors; changing word order cannot select a different register.
If a live request capture is unavailable, retain the driver name/version, its address-mode setting and the configuration screen. Ask the integrator or supplier to confirm the resulting request. A guessed offset supported by one plausible display remains unverified.
Validate the selected item before copying it to other tags
Compare the requested quantity with a known local value at matching times and at distinct conditions that can be obtained safely. A changing value may still be distance rather than level. A near-zero test can conceal a wrong scale or an unrelated register whose value happens to be zero. Keep the raw response with each comparison.
After approval, record both the human-readable map reference and the actual request fields in the integration sheet. Recheck them when moving to a different PLC driver or gateway: copying the same typed number does not prove that the new software sends the same address. Keep supported status and communication-loss handling in the acceptance scope as well.
Questions when a register response looks plausible
Q1. Does no Modbus exception mean the correct item was requested?
No. It can mean that the requested location is valid, while still being the wrong location for this tag. Confirm the request against the supplied map and verify the returned variable independently of the display label.
Q2. Should every driver entry be reduced by one?
No. Establish whether the source map and the driver use offsets or numbered references, and whether the driver translates the entry. Apply only the conversion required by that documented combination.
Q3. Can an address be found by trying parameter writes?
Do not use writes as a discovery method. An unintended successful write may change the instrument. Establish the documented read mapping first, and restrict any required configuration write to the authorised procedure for the supplied version.
Summary
Verify the requested item before interpreting its bytes. Send the MV-RD12 electronics identity, map revision, PLC driver details and request fields with an integration enquiry. Include the local value and raw response so the review can separate addressing from data conversion.
