How Strictly Should the MODBUS Addressing and Data Models Be Followed?

M

Thread Starter

MikeAtCalidus

Would a MODBUS server device with some of the 'Registers' defined as being greater than 16 bits be useable? For example, could I document my device memory map as follows:<pre>
Register # Type Useage
30001 1 U16 Current (mA)
30002 2 U32 Run time (ms)
30003 1 U16 Event Count
30004 8 OSTR Correllation Table
30005 1 U16 Distance (mm)</pre>

Where the number in the # column indicates the length of the register (in 16 bit WORDs).

Scenario 1
----------
The Client still reads registers using the common interpretation of the standard functions. I.e.

Read 'Current' Input Register: 01H,04H,00H,00H,00H,01H,CAH,31H
Read 'Run Time' Input Register: 01H,04H,00H,01H,00H,02H,0BH,20H

Note that in the second read the Number of Registers to read is still 2, in this case the 'Number of Registers' field is being interpreted as the expected data length in WORDs. The issue here is that the Client would be restricted to reading only one data object at a time.

Scenario 2
----------
A further extension of my stretching of the specification would be to interpret the 'Number of Registers' field to be exactly that, in which case multiple objects could be read at a time, but the length of the returned data would not always be exactly double the Number of Registers' requested. The Client would need to know the size of each 'Register' (of course, it already does or it wouldn't be able to unpack standard multi-register reads) to unpack the returned data.

Summary
-------

The specification is open to interpretation in many areas, with lots of manufacturers putting their own spin on how their devices implement it. If my product implements one or both of the proposed 'interpretations' above, would existing Clients (such as PLCs or OPC servers) be able to handle it or is it more likely to make people reject the product as being utterly incompatible?
 
> Would a Modbus server with register greater than 16 bits be useable?

No, It would be a mis-representation to call your addressing scheme 'Modbus'.

In answer to the thread title, "How Strictly Should the MODBUS Addressing and Data Models Be Followed?" my answer is to the letter.

Some aspects of Modbus are no longer followed to the letter, like two stop bits for no parity in RTU.

But 16 bit registers is written in stone. The clint/masters/OPC servers out there expect 3xxxx or 4xxxx registers to be 16 bit registers. Period. (yeah, there's Daniels)

Scenario 2 seems to be concerned with a client/master reading 'multiple objects' at one time, when the objects are not all the same register size. That's not a huge deal - either Function Code 03 reads multiple holding registers (4xxxx) or FC 40 reads multiple input registers (3xxxx). It is up you to define and document which register is what format and for the client/master to interpret the received registers appropriately. But neither FC 03 or 04 care if the data is a single register integer or a 2 register Floating Point, either function code is just a mule; it carries data bits back and forth and doesn't care what the data bits mean.

If you want to invent a protocol with sequential registers of different sizes have a go at it. But please don't call it Modbus.

For instance, lots of devices just have a spec 'RS-485' or RS-232 (transport layer only, no protocol) and the customer uses the proprietary Windows app that comes with the device, or writes (or hires someone to write) an app to talk to the device.

But please, don't call it Modbus if it isn't, and it isn't when it has sequentially numbered registers of different sizes.
 
M

MikeAtCalidus

Considering the answers above, would it be acceptable for the server to respond with an ILLEGAL DATA VALUE exception (EC = 03h) in the event that the client attempted to:

- Read only one 'register' of a 32 bit value?

- Read multiple registers with a start address that is not on an object boundary, i.e. starting at the least significant register in a 32 bit object?

The root problem is that the microcontroller being used stores integers in little-endian format and these have to be inserted in big-endian format into the PDU. Using a table to map MODBUS register addresses onto database entity ID's is fine for whole entities, but would require considerable additional processing to deconstruct partial entities. If I can require that multi-register values are always read in their entirety I can avoid the additional processing. This would be particularly helpful when the underlying objects are arrays of values.
 
L

Lynn August Linse

I have seen small products demand a read starts at 'beginning' (offset 0). I've also seen products which return a data error if one reads only 1 word of a 2 register pair, or 2nd of one & 1st of another. Such products tend to be annoying as the error response is not very helpful. For example, I had a meter which rejected a 125 word read, but not a 124 word read, despite it have 170+ registers. It turned out the words 125+126 made a 32-bit pair & could not be split. But with the error only being 'illegal data', one's left to puzzle the cause and solution.

What I do with smaller systems is ALWAYS create the full register data buffer regardless of the request size, but only use the simple Modbus calcs to return the ask for data. So if I have 18 registers, any read which begins in the 18-register space causes ALL 18 data words to be rewritten to the buffer. But if this is just a read of 3rd and 4th word, I just return those 2 words. In general, a small micro has nothing better to do than calc the worse-case response always anyway. If this somehow breaks the device (too much work), its not a valid design anyway.
 
Hello,

What if the master uses two reads and the combination of two reads fetches the complete 32 bit value? Why would you want to mess up what is legal per the specification?

MODBUS is a simple protocol.

KISS.

Good luck,

Mark
http://www.peakhmi.com/
 
L

Lynn August Linse

Mark,

I can only shrug, reporting what I've seen. As I said, I find it annoying, and do as I said, build the full memory map and return what is asked for.

Of course, it is highly likely the 2 reads would splice together garbage, as the 32-bit value has likely changed between reads and Modbus has no 'freeze' command like AB/DF1.

So one can try to protect people from themselves (annoying & confusing them), or trust they know what they are doing.
 
Top