.png)
Modbus Device Identification: Follow the Next Object Before Signing Off the Asset Record
A commissioning utility returns a product name, but the equipment inventory is still missing identification fields. Before assuming the device has no further information, check whether the response says more objects follow. The complete result may require several transactions, and support must be confirmed for the exact device.
Key takeaways |
Read Device Identification is function 43 with MEI type 14. Stream responses can span transactions. Follow the returned continuation information and retain object IDs with their values. |
1. Separate identification from process registers
Modbus application specification V1.1b3 describes Read Device Identification under function 43 decimal, hexadecimal 0x2B, with MEI type 14 decimal, hexadecimal 0x0E. The identification objects are not a consecutive block of ordinary holding registers.
The service distinguishes basic, regular and extended stream access, and individual object access. Confirm which form and conformity level the server supports. A useful asset record should state how each field was obtained rather than presenting an unsuccessful unsupported request as evidence that a device has no identity.
For an architecture using the BG200 industrial IIoT gateway, ask whether the planned discovery tool can access this exact service through the chosen path. General Modbus compatibility does not prove support for this function or its multi-response workflow.
2. Treat each response as a page of objects
In stream access, the specification provides More Follows and Next Object Id fields. More Follows 0xFF indicates further objects are available; 0x00 indicates that no more are available. When continuation is required, the next request uses the returned object identifier under the documented service rules.
Store each returned object ID, its length and value alongside the request context. Do not treat the response’s object count as the total number of identification fields the device can ever supply. Equally, do not assume every numeric object ID between two returned IDs must exist.
3. Test the client’s continuation logic
Consider a hypothetical simulator whose first response has More Follows 0xFF and Next Object Id 0x05. A client that records only that first reply can look successful while retaining an incomplete inventory. The acceptance test should require a subsequent request starting from the returned 0x05 and should retain its response.
Complete the sequence until the server indicates no more objects. Keep the read-device-ID code and target identity consistent across the operation. If the device or route changes mid-read, mark the inventory as incomplete rather than combining responses from different targets.
Add a bounded guard against repeated continuation values or an excessive number of pages. A malformed or inconsistent endpoint must not leave an unattended discovery task looping indefinitely. Report the last request and response context so the issue can be reproduced without guessing at missing fields.
Diagnostic checks
Reply condition | Client action |
More Follows = FF | Continue at returned Next Object Id |
More Follows = 00 | Finish this stream read |
Repeated continuation or failed reply | Stop with an explicit incomplete result |
4. Reconcile the result with physical documentation
Compare relevant returned vendor, product and revision information with the actual nameplate, asset record and current device documentation. A returned firmware string may help select the right manual, but it does not prove that a particular option, regional variant or accessory is installed.
An unsupported service may require another documented identification method. Keep that limitation visible in the handover. Do not scan arbitrary register ranges looking for plausible text or turn a read-only inventory task into a configuration write.
Identification strings are also not authentication. A plausible vendor label does not establish that an endpoint is trusted or that its communications are protected. Use the project’s separately verified network and access controls; the inventory service does not replace them.
5. Make completeness observable in the report
Record the device address or endpoint, route, function and MEI type, requested access form, returned conformity level and all continuation steps. Include the time of the read and the tool version. Keep an explicit complete, unsupported or incomplete outcome for each asset.
For a replacement device, compare the relevant identity and revision evidence before restoring the agreed configuration. Differences need review against the project requirements. Neither a matching product name nor a completed protocol sequence proves that process scaling, I/O wiring or alarm behaviour is correct.
ProSense Solutions can discuss the asset-inventory and commissioning scope around the real equipment list. Bring the sanitised request sequence and the missing fields; that makes it easier to separate limited server support from an incomplete client implementation.
Practical handover checklist
Confirm the exact server supports the identification service and required access form.
Save returned object IDs and continuation fields for each transaction.
Follow Next Object Id while More Follows requires continuation.
Reconcile the completed record with nameplate and documented revision evidence.
Recommended equipment / related solutions
BG200 industrial IIoT gateway — Assess the communications route and verify the required identification service with the exact tool and endpoint.
ProSense RTU Monitoring Kit — Discuss an asset-based monitoring and handover scope, including documented identity fields and acceptance evidence.
Frequently asked question
Can identification results prove the correct firmware functions are enabled?
No. They provide identification evidence. Confirm actual firmware documentation, configured options and required application functions separately.
Technical reference
Need help with your application?
Discuss this application and request a project assessment. Send the exact equipment models, interface documentation and a sanitised example. Confirm compatibility, supported functions and acceptance scope before purchase or deployment.
