We are having an issue with the way how MODBUS request fields are written to the DataOutputStream when using Modbus TCP.
In the library code:
if (!isHeadless()) { dout.writeShort(getTransactionID()); dout.writeShort(getProtocolID()); dout.writeShort(getDataLength()); } dout.writeByte(getUnitID()); dout.writeByte(getFunctionCode()); writeData(dout);
The issue is that sometimes output stream buffer contents are sent over TCP before the final "flush()" is called, and request is delivered to the Modbus Server in multiple TCP frames, and it is causing problems in the server.
Because of problems in the server no Modbus response is generated, and transaction is never finalized.
Can anyone please comment on this issue?
Is it allowed for the client to send Modbus request in chunks?
Is it only mandatory for the server to receive/handle Modbus request delivered in a single TCP frame ignoring other?
I could not find any specific rules in the MODBUS documentation that say client/server is correct/incorrect in this case.
Janek
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
TCP is a stream protocol, unlike UDP which uses datagrams. What this means, in practice, is that there is nothing wrong with a TCP client sending the bytes one at a time. It would be slow as can be, but it would be correct.
Where it can be a problem is if you are communicating with a Modbus/RTU device and the fragementation is violating the 3.5T timer. For for straight-up Modbus/TCP the correct behavior is to read the 6 byte header, verify the protocol is correct (2nd 16-bit word in the header), the use the length (3rd 16-bit word) to read the remainder.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
We are having an issue with the way how MODBUS request fields are written to the DataOutputStream when using Modbus TCP.
In the library code:
if (!isHeadless()) {
dout.writeShort(getTransactionID());
dout.writeShort(getProtocolID());
dout.writeShort(getDataLength());
}
dout.writeByte(getUnitID());
dout.writeByte(getFunctionCode());
writeData(dout);
The issue is that sometimes output stream buffer contents are sent over TCP before the final "flush()" is called, and request is delivered to the Modbus Server in multiple TCP frames, and it is causing problems in the server.
Because of problems in the server no Modbus response is generated, and transaction is never finalized.
Can anyone please comment on this issue?
Is it allowed for the client to send Modbus request in chunks?
Is it only mandatory for the server to receive/handle Modbus request delivered in a single TCP frame ignoring other?
I could not find any specific rules in the MODBUS documentation that say client/server is correct/incorrect in this case.
Janek
Janek -
TCP is a stream protocol, unlike UDP which uses datagrams. What this means, in practice, is that there is nothing wrong with a TCP client sending the bytes one at a time. It would be slow as can be, but it would be correct.
Where it can be a problem is if you are communicating with a Modbus/RTU device and the fragementation is violating the 3.5T timer. For for straight-up Modbus/TCP the correct behavior is to read the 6 byte header, verify the protocol is correct (2nd 16-bit word in the header), the use the length (3rd 16-bit word) to read the remainder.