Today is...
Saturday, September 23, 2017
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
A tutorial introduction to programming using the QuickBuilder Programming Environment.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Multiple Connect Request from Same MBTCP Master
Can same master/Client establish multiple Modbus TCP connections to same slave/server???

Currently we have Modbus TCP server which is getting restarted when there are Continuous Connect and disconnect from same master.

To restrict this we did a change such that If there is any available connections from master already then new connection will not be accpeted till old connection is deleted .

But this will restrict allowing Multiple connects from same master. Hence Is this valid use case? DO we need to support multiple connections between same master and same slave?

Have someone came across such scenarios where single master establishing multiple connect with same slave? Does any company products (MBTCP SERVER) allow this?

It sounds like you're attempting to solve your issue by trying to use an easy workaround instead of investigating the root cause of why your Modbus TCP server is getting restarted.

In general, it is good for a Modbus TCP server to support multiple, simultaneous connections regardless of whether they're coming from the same client or not. We do this in our products and allow up to 8 simultaneous connections.

There are two scenarios that come to mind where there could be multiple connections between the same client and server.

Some clients open and close a connection for every request. Although this is very inefficient, there are devices out there that do this. However, with devices like this, they could attempt to open a new connection before fully closing the last one. By restricting this, your device may only receive half the requests from the client.

The other scenario would be for efficiency tuning reasons where a client could open multiple connections in parallel to receive data faster than with a single connection. Another reason for doing this could be to split up high priority and low priority data into different connections using different poll rates or other tuning parameters.

While the above two scenarios are likely not that common, they are worth considering when making design decisions.