Retry is unnecessary in ModbusTCP
Brought to you by:
wimpi
Menu
▾
▴
#44 Retry is unnecessary in ModbusTCP
Retry is unnecessary in ModbusTCP
If you implement retry processing, it's necessary to close a TCP connection before retry or you check a response to have the same transaction ID.
When a response is delayed more than 3000 msec after the query's sent, you receive an illigal response.
An easy way to resolve this is to stop retry query in ModbusTCP
Not sure why the OP says that "retry" isn't needed in Modbus/TCP. It is possible for the master and slave to get out of sync, particularly if there is any significant delay on the line.
The problem I've had with Modbus/TCP is related to short timeouts and slow slaves. A retry may result in a "stale" packet left in the input, which causes a transaction ID mismatch in ModbusTCPTransaction. That error condition isn't checked in execute() -- execute() just reads the response and returns it, unchecked, to the caller.
Not putting a transaction ID check in execute() means that any synchronization problems caused by a timeout have to be resolved by closing the connection, which doesn't strike me as the best approach.
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
Just check the validity of the transactionID at the moment of the read in the execute()
there the way I fix it :
(...)
//3. write request, and read response
m_IO.writeMessage(m_Request);
//read response message
do{
m_Response = m_IO.readResponse();
}while(m_Request.getTransactionID() != m_Response.getTransactionID());
break;
(...)
I also disconnect after retry reach max count in upper code layer based on catch of the ModbusIOException
I have pretty much given up on jamod and created a fork, j2mod, that is based on jamod 1.2 plus all of my fixes. I am going to allow professional software engineers to work on the project so we don't wind up with another dead open source Modbus implementation.
I had looked at some of the other Modbus projects and they were either too difference from jamod (the port will only require that the package names be changed) or they are released under the GPL, which is not commercial application friendly.
A quick followup on having execute() handle transaction ID re-synchronization. I ran some benchmarks on the fix I described and I was seeing 2ms turnarounds on requests on localhost.
I ran a 600 transaction test and only lost two transactions.
Transaction retries can be configured and do not necessarily have to take place:
/**
* Sets the flag that controls whether a
* connection is openend and closed for
* <b>each</b> execution or not.
* <p/>
*
* @param b true if reconnecting, false otherwise.
*/
public void setReconnecting(boolean b);
and:
public void setRetries(int num)
Maybe jamod doesn't do validity checking out of the box, but actually, there is a hook in the code that would allow to achieve it, extending the ModbusTCPTransaction:
/**
* Checks the validity of the transaction, by
* checking if the values of the response correspond
* to the values of the request.
* Use an override to provide some checks, this method will only return.
*
* @throws ModbusException if this transaction has not been valid.
*/
protected void checkValidity() throws ModbusException {
}//checkValidity
public void setCheckingValidity(boolean b) ;