I was wondering why there is a byte count field in the packet format when there is "Number of Registers" information is available?

Below shows the Query format
(Ref. PI-MBUS-300 Rev. J)

byte 0 Slave Address
byte 1 Function
byte 2 Starting Address Hi
byte 3 Starting Address Lo
byte 4 No. of Registers Hi
byte 5 No. of Registers Lo
byte 6 Byte Count
byte 7 Data Hi
byte 8 Data Lo
byte 9 Data Hi
byte 10 Data Lo
byte .. Error Check (LRC or CRC)

Does it intended to tell that there can be data length which might not be 2 * Number of Registers?

 

You could also calculate the expected message length for coils and discrete inputs based on the number of coils or discrete inputs, although that calculation is a bit more complicated.

I suspect the byte count has something to do with keeping the real time computational overhead low while receiving messages on simple devices. The functions with variable length messages appear to have a byte count, while the ones with fixed length messages don't.

 

> Does it intended to tell that there can be data length which might not be 2 * Number of Registers? <

Exactly. You may check specs for function code 01 (read coils) and 02 (read discrete inputs), the specific functions response data are byte-oriented rather than register-oriented.

 

The best answer is ... "Why do Americans drive on the right side of the road?" ... because that's the way it is.

Some vendors use the byte count to over-ride the data size - for example many flow computers allow one to write 10 registers and 40 bytes to imply that these are 32-bit registers. Micro-motion used to have an 128-byte register for use with ASCII printer output.

This is rather a gray area in the spec because although Modbus says registers are 16-bits, it does not (or at least did not for most of history) say they MUST be exactly & only 16-bit.

Just be aware that many client/hosts mis-behave when register sizes are not 16-bit.

 

Thanks all for your attention to this query.

I was working on developing a ModbusTCP client to support the communication with some third party IO modules. These IOs are attached to a ModbusTCP adaptor with 8 IO slots.

The specification said that these IOs will be mapped on to holding registers with first slot addressed as 40000. The possible IO modules types are 8/16/32 bit Digital Input / Outputs, and 16 bit Analog Input / Output.

We made an assumption that the module address will be word aligned and developed the client module. Everything works fine but, when we connected 8 bit modules to the adaptor and tried to communicate, was getting exception. Then we modified the code by making above assumption false but got different exception.

We are talking to the vendor about this. I will update the developments soon.