Modbus message length?

Hi experts,

I'm doing some tests right now with a Modbus Master connected to a Modbus Slave (RS485 communication). In the Modbus Master it's possible to select the maximum message length (default value is 32 bytes). When using the default value (message length = 32 bytes) everything works fine. However - if the message length is increased to 64 bytes there are time-outs every now and the.

I've been at www.modbus.org, reading the Modbus specification but I can not find any information on how long telegrams a Modbus Slave should support. Do you have any information or experiences regarding this kind of problem?

Thanks for your time...

This is not an answer to your question, I'm just very curious as to why would you increase the query to 64 bytes?

I normally deal with the low end Modbus functions: 01, 02, 03, 04 where the request messages are a total of 16 bytes in length.

Are you doing something like function 20 read file records, or 23 read/write multiple registers, where the requests can be longer than 16 bytes?

The only thing I can find in relation to length of queries is in section 4.1 of my copy (June 2004, Modbus Application Protocol Specification V1.1a), where it notes that the Modbus frame size maxes out at 253 bytes.

----- V1.1a -------
The size of the Modbus PDU [Protocol Data Unit] is limited by the size constraint inherited from the first Modbus implementation on serial line network. (max RS-485 ADU = 256 bytes)
Therefore:
Modbus PDU for serial line communication = 256 minus Server address (1 byte) minus CRC (2 bytes) = 253 bytes
--------

Do you know if changing the max msg length value actually changes the master's query message format or content? Since the Modbus frame is specific to the function used, it isn't clear why changing a potential maximum value would alter a typical Modbus msg.

Dan

My Modbus RTU calls are always 4 words (8 bytes).

When you say "message length", are you refering to the number of registers read with a function code 3 or 4?

It's probably taking the slave a little longer to assemble the response to a request to read 64 bytes of data than for a request to read 32 bytes. The master is probably not waiting long enough for the response before jumping to its timeout response. Do you have any control of that when you set up the master's parameters?

I thought danw's answer is good. ... Why I hate Modbus RTU.

I know the data is on www.modbus.org.

Supporter, have you looked at the timing specifications for Modbus RTU? Are you aware that slave and master devices must measure the time between characters. How do your devices measure character times?

There are few devices that meet the character timing specifications. We use DMA to send data so there are no gaps between the characters. Detecting the gaps between characters when receiving is more difficult. It takes special dedicated hardware to count the time betweeen characters accurately. How is the modbus driver going to know when a character arrives? Usually the serial chips have buffers that buffer 16,32 or 64 characters before generating an interrupt. There could be gaps between the arriving characters and the software will never know. The software only knows when the buffer is full and an interrupt is generated.

It is possible that your smaller transfer fits in one buffer and the larger transfer requires that the this buffer is emptied and the buffer is filled up again. How long does it take to fill up the buffer the second time? Is is more than 3.5 character times. You know it is. That is why we don't use buffers and use DMA. Every interrupt we check to see the characters are still arriving. If not we timeout but we can only measure 3.5 character times down to the closest interrupt which is 500us or 1ms. For best results, slow down the bit rate or fit fit the packets into one buffer. Transfer of 16 bytes or less should always work. 16 bytes is the size of a 16550 buffer.

Modbus Ascii doesn't have the timing requirements. Neither does DF1. That is one of many reason why we prefer DF1. I HATE tech support calls from customers that can't make their Modbus masters talk to our product because their Modbus masters have a lame implementation of Modbus RTU. I don't see why people keep abusing themselves with this protocol and sharing their pain with us. Use DF1 or Ethernet.

Those that have used our software know we have a small buffer mode where all the transfer are broken down into 16 byte blocks at the most.