1. Home
  2. ⧑ Industrial Control Group
  3. MODBUS Read/Write File Command

MODBUS Read/Write File Command

Hi all,

I have a query regarding the MODBUS Read/Write File commands and how they should be interpreted. (I am implementing a MODBUS RTU slave device).

The MODBUS spec is a bit vague and confusing in this matter, and the few MODBUS implementations I have found do not seem to bother with this type of command.

Here are the two possible interpretations as I see it. Anyone who could clear this up for me would be great.

Interpretation 1: 10,000 records per file, records of any length.

File n [0] -> [0.. record length] [1] -> [0.. record length] [2] -> [0.. record length] [3] -> [0.. record length] ... [9999] -> [0.. record length]

In this interpretation, there are 10,000 records per file and these records can be of any length. When requested, the request has the file number (eg 0), the records number (eg 3) and the length of the record (eg 60 registers).

Interpretation 2: 10,000 registers per file, variable number of records per file

File n [0] -\ [1] | Record 0 [2] -/ [3] -\ [4] | Record 1 [5] -/ ... [9999]

In this interpretation, there are 10,000 registers per file, and the size of the records determine how many records there are per file. For example, a single file could fit 50 records of size 200.

Which is it? Or is it something else again? Not very helpfully, the spec has examples where the record size is 1 register, making the above two cases the same....

Anyone?

Thanks, Andrew

Reply to
andrerev
Loading thread data ...

Just to clarify, I am referring to commands 0x14 and 0x15

Reply to
andrerev

Where do you get the idea of "records" from? I can't see any use of the word or concept in the manual:

formatting link
There are just "files" of 10,000 registers each (except that depending on the hardware, the last file is short). You give the file number, start address, and register count. Perhaps you are confused by the possibility of having more than one "sub-request" of data in a single message, but their contents are in no way related and do not imply records in the sense of a disk file -- that is not what the word "file" means here.

Caveat: I have implemented read/write general reference in both master and slave interfaces, but none of our customers has ever used them, so I could be wrong.

Chris Communications interface developer, ABB Switzerland (but in no way representing the company etc. etc.)

Reply to
chris_doran

The idea of a "record" really came from the MODBUS spec itself - the "MODBUS Application Protocol Specification" (V1.1) found on

formatting link

To quote a few sections...

"Each file contains 10000 records, addressed 0000 to 9999..." "For example record 12 is addressed as 12"

Now I can see how they could be using the term "record" interchangably with register - unnecessarily confusing really.

What you are saying is my option 2, and is as firm as anything I have found so far. So I will go with that.

Thanks, Andrew

Reply to
Andrew Revell

interchangably

Yes, I see what you mean -- very confusing. The original printed spec from which I worked many years ago doesn't use the mystery word "record", just "register" throughout, so I didn't suffer this quandary.

An e-mail to modbus.org is probably due.

Chris, ABB

Reply to
chris_doran

My experience with modbus sniff the serial connection between the master and slave or master and master devices to see what is required on each side. Rarely is the entire modbus protocol fully implemented. Even rarer is the modbus (or modbusTCP) protocol fully implemented in a robust fashion for heterogeneous devices. This is evidences by missed poll/response pairs and all sorts of timing issues.

Test, test and test some more between all of the devices, after your code is written. Some PLC/RTOS do not service the interrupt(vectors) quickly enough for modbus to be use for timing critical applications.... It's not a problem with modbus, just the (executive/statemachine/rtos) and or the software developer's code....

Good luck,

James

Reply to
James

In microprocessor/microcontroller speak (embedded firmware) A register is hardware. A record is a logic abstraction.

For example, a register, say 64 bits, might contain 4 records each 16 bits. When a programe reads the record, the embedded firmware most likely will read the contents of the entire register, and mask-off the bits not of interest or part of the record.

A record's specific details depends on the architectural details of the chip and the executive/statemachine/rtos that is implement on top of the hardware.

Hope this helps.

James

Reply to
James

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.