Hi everyone, I’ve been diving into the implementation of connection pooling within the Modbus binding and wanted to share my findings and thoughts. My setup involves a PLC that can only handle a single connection at a time, which has posed some challenges with the current binding configuration.
Currently, I have multiple Modbus slaves configured to read different data types, like so:
modbus:tcp.slave1reals.connection=192.168.1.100:502
modbus:tcp.slave1reals.id=1
modbus:tcp.slave1reals.type=holding
modbus:tcp.slave1reals.start=1
modbus:tcp.slave1reals.length=6
modbus:tcp.slave1reals.valuetype=float32
modbus:tcp.slave1modes.connection=192.168.1.100:502
modbus:tcp.slave1modes.id=1
modbus:tcp.slave1modes.type=holding
modbus:tcp.slave1modes.start=6
modbus:tcp.slave1modes.length=1
modbus:tcp.slave1modes.valuetype=bit
Ideally, I’d like to establish a single connection to 192.168.1.100:502 to streamline the process. According to the MODBUS messaging on TCP/IP implementation guide, it’s recommended to minimize the number of TCP connections, with one per application being a good practice.
I’m considering refactoring the Connection creation using a connection factory. For TCP connections, the same connection would be returned if the InetAddress and port match. Similarly, InetAddress and SerialParameters would be used for UDP and serial connections, respectively. Locking access to the connection might not be necessary for TCP/UDP, but if needed, synchronized(connection) scopes in getModbusData and executeCommand could ensure single read/write operations.
Currently, I’m working on some fixes for connection closing in my pull request #3512. Additionally, I’ve started testing in a separate branch modbus-binding-tests to detect regressions and bugs.
I’m curious if this approach seems reasonable to others. Any insights or suggestions would be greatly appreciated! Best, ssalonen