.png)
Modbus File Records Are Not Holding Registers: Specify Both Address Dimensions
A working holding-register connection does not prove access to a device’s file records. Specify the file number, record position and length together, then validate each returned group against the requested map.
Original conceptual illustration; not a live software screen, specific product or customer installation.
Key takeaways
Confirm function 20 support on both ends.
Record file, record and quantity independently.
Retain raw replies and the accepted map.
1. Use the correct address model
Modbus function 20 reads file records through grouped subrequests identifying a file and a starting record. It is distinct from a conventional holding-register read. The protocol response contains a separate subresponse for each requested group.
When assessing the BG200 industrial IIoT gateway for a recorder integration, confirm the exact function, driver and firmware requirements with ProSense. Do not infer file-record support from a catalogue statement about Modbus TCP or RTU alone.
2. Request a complete supplier map
Obtain the equipment model, firmware, supported file numbers, permitted record ranges and decoding rules. Ask whether record contents are live values, historical blocks or another vendor-defined structure. The word file does not establish a downloadable operating-system file.
Keep the vendor document’s notation beside the actual encoded request. Separately record file number, first record and quantity. Avoid putting these three independent choices into a single ambiguous spreadsheet address column.
3. Make the acceptance example unambiguous
Consider a hypothetical simulator in which file 2, record 3 contains value 100, while file 3, record 2 contains 200. Requesting the first combination must not return the second simply because both contain the same two numbers in different positions.
Use recognisable, non-production test values and record the request alongside the raw reply. If several groups are requested, give every group a distinct expected pattern. Checking the total reply length alone will not detect a client that assigns one valid group to the wrong destination.
Original explanatory infographic. Values and test cases are hypothetical; equipment selection and implementation require project-specific verification.
Diagnostic comparison
Observation | Check next |
Right connection, wrong records | Check file number and starting record separately. |
First group correct, second incorrect | Inspect per-group boundaries and association. |
Basic reads work, file reads fail | Verify explicit function support. |
4. Validate grouped replies
Commission one supported group first. Then add a second group and verify the association, decoded value and error handling. Include an unavailable file, an out-of-range record and a truncated simulator reply. Treat malformed data as a failed acquisition rather than filling the destination with the last good value without a quality indication.
Plan request sizes from the documented protocol and product limits; do not keep increasing quantities until the device stops replying. The response framing includes both overall and per-group length information. Validate the complete structure before assigning engineering values.
Confirm function 20 support on both ends.
Record file, record and quantity independently.
Prove one group with a known pattern.
Add groups and test incorrect mappings.
Retain raw replies and the accepted map.
5. Define the operational boundary
The final handover should show the accepted map, examples, retrieval interval and storage destination. State how stale records and missing ranges are reported. Historical retrieval may need different operational ownership from live monitoring, especially when operators use the same device locally.
Do not introduce write-file operations while investigating a read failure. Preserve the original device configuration and archived data. If the required access is unsupported, compare an authorised export or alternative acquisition path instead of describing a basic gateway as universally compatible.
Recommended equipment / related solutions
For a Modbus integration enquiry, assess the BG200 industrial IIoT gateway. Its catalogue lists Modbus TCP and RTU support; confirm the exact firmware, device map and required acceptance tests.
For a broader remote-asset monitoring scope, review the ProSense RTU Monitoring Kit. Confirm the supplied interfaces and whether a kit is appropriate; it is not a substitute for checking the connected device or an authorisation for control writes.
Related practical guide: Modbus TCP Replies Crossed? Match Transactions Before Trusting the Register Value
Frequently asked question
Does a file-record interface replace a USB export?
Not automatically. The equipment documentation must identify what records are exposed and how they relate to exported history. Do not assume every stored file is available through Modbus.
Technical references
Need help with your application?
Send the equipment models, current documentation and a sanitised test example. Discuss this integration and equipment requirement with ProSense; confirm the actual functions, interfaces and acceptance scope before purchase or deployment.
