Modbus/TCP Conformance Test Policy

  • Thread starter philippe boudot
  • Start date
P

Thread Starter

philippe boudot

<p>See Conformance Test Policy Version 2.0

<p>Chapter 9.1.3
<pre>
9.1.3. Improper Message Length
9.1.3.1. A request is sent via TCP on port 502 with an improper message length, in the format
specified by [2] and [3] from the Laboratory PC.

9.1.3.2. The Modbus request will be of the form
00 00 00 00 00 FF XX 03 00 00 00 01
Corresponding to:
Transaction Identifier: 00 00
Protocol Identifier: 00 00
Message Length: 00 FF
Unit Identifier: XX
Function Code: 03
Register Offset: 00 00
Number of Registers: 00 01

9.1.3.3. The response must be of the form:
00 00 00 00 00 03 XX 83 03
Corresponding to:
Transaction Identifier: 00 00
Protocol Identifier: 00 00
Message Length: 00 03
Unit Identifier: XX
Function Code: 83
Exception Code: 03
</pre>
<p>Not agree with that :<br>
- according to "MODBUS Application Protocol Specification V1.1"
<pre>
"The size of the Modbus PDU is limited by the size constraint
inherited from the first Modbus implementation on Serial Line network
(max. RS485 ADU = 256 bytes).
Therefore, MODBUS PDU for serial line communication
= 256 - Server adress (1 byte) - CRC (2 bytes) = 253 bytes.
Consequently :
RS232 / RS485 ADU = 253 bytes + Server adress (1 byte) + CRC (2 bytes) = 256 bytes.
TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes."
</pre>
<p>so the maximum for "Message Length" is 254 bytes (Message length include Unit Identifier)

<p>- We can say in this case that the header is corrupt (not conform with Modbus spec.)

<p>- In this case we have to UNILATERALLY CLOSE THE CONNECTION according to Open MODBUS/TCP Specification
page 20 (I think we have to replace 256 with 254)

<p>"Analyze the header. If it appears corrupt, for example
the protocol field is non-zero or the length of message
is larger than 256, then UNILATERALLY CLOSE THE CONNECTION.
This is the correct response as a server to a situation
implying the TCP encoding is incorrect."
<pre>
Chapter 9.1.4
9.1.4. Illegal Number of Registers
9.1.4.1. A request is sent via TCP on port 502 with an illegal number of registers, in the
format specified by [2] and [3] from the Laboratory PC.

9.1.4.2. The Modbus request will be of the form
00 00 00 00 00 06 XX 03 00 00 FF FF
Corresponding to:
Transaction Identifier: 00 00
Protocol Identifier: 00 00
Message Length: 00 06
Unit Identifier: XX
Function Code: 03
Register Offset: 00 00
Number of Registers: FF FF

9.1.4.3. The response must be of the form:
00 00 00 00 00 03 XX 83 02
Corresponding to:
Transaction Identifier: 00 00
Protocol Identifier: 00 00
Message Length: 00 03
Unit Identifier: XX
Function Code: 83
Exception Code: 02
</pre>
<p>Not agree with that :

<p>- It is not possible in modbus to ask for #FFFF registers, I think that in this
case an Exception Code : 03 is better than 02
<pre>
03 Illegal Data Value
A value contained in the query data field is not an allowable value
for the slave. This indicates a fault in the structure of the remainder
of a complex request, such as that the implied length is incorrect. It
specifically does NOT mean that a data item submitted for storage in a
register has a value outside the expectation of the application program,
since the MODBUS protocol is unaware of the significance of any
particular value of any particular register.

02 Illegal Data Address
The data address received in the query is not an allowable address for the
slave. More specifically, the combination of reference number and transfer
length is invalid. For a controller with 100 registers, a request with offset
96 and length 4 would succeed, a request with offset 96 and length 5 will generate
exception 02.
</pre>
<p>Another problem with the request 00 00 00 00 00 FF XX 03 00 00 00 01 (see chapter 9.1.3.2),
We have seen that the maximum is FE so if we just change the request in :
00 00 00 00 00 FE XX 03 00 00 00 01<br>
I think we have to reject this request too, and UNILATERALLY CLOSE THE CONNECTION, because
the real length of the request we received is not the same of "Message Length". So we have to
consider that the MBAP is corrupt..

<p>Philippe Boudot<br>
Electronic Research & Development<br>
CP Industrial Business Unit

<p>Email: [email protected]<br>
http://www.chicagopneumatic.com
 
L

Lynn at Alist

Thanks for the effort in this email. It's a bit hard to identify your exact question/comments. I think you have 2 questions/comments? Here are my own views on these:

1) Max length: I agree the spec is too vague here. Correct max length should be limited to 253 - whatever fits within a Modbus/RTU packet since large numbers of Modbus/TCP to Modbus/RTU bridges are used. So no one should be sending Modbus/TCP messages that cannot be mapped to RTU.

Trying to squeeze 1 more word in a MB/TCP packet is not worth the problems it will cause bridges. At some point I hope a recommended "vendor extension" comes out of modbus-ida.org which permits a 2nd MB/TCP protocol (version 1?) that supports larger packets suitable for
Ethernet and TCP/IP. This is far better than some goofy "fragmentation" mechanism that lets a master read a dozen blocks of 125 words by "freezing" all the data in advance.

2) Exception codes: this will ALWAYS be a problem. Past Modbus standards just listed exceptions almost as-if an after thought, so vendors selected exception codes per their own opinion. The current standard is better since it defines the exception per the situation. I'm not much into debating "correct codes" - ultimately the spec should define a situation AND a code and products follow this. ODVA/Ethernet/IP is a perfect example of this - they have SO MANY codes that there are often 2 or more codes that are arguably valid. But ultimately 1 is selected and defined as the "correct code".

Many thanks
- LynnL, www.digi.com
 
Top