Hi Cesar, I think from your email, that you would agree to not put reconnection logic into the operations themselves. If the connection fails for whatever reason: Fail fast, report this to the client in a clear way and have the client deal with it. I just mentioned the connection cache, as I’m personally using that for all of my polling operations and it generally takes care of the reconnect automatically.
I think the only driver that has some sort of auto-connect functionality (even if it’s a bit broken) is the ADS driver. When I update that as part of my SPI3 migration, I would like to update it in a way that if the connection is lost, it doesn’t try to reconnect. Chris Von: Cesar Garcia <[email protected]> Datum: Montag, 26. Januar 2026 um 21:31 An: [email protected] <[email protected]> Betreff: Re: How to handle disconnects? Hello, In our particular case, control over the driver is important. In the case of the S7 driver, the "ConnectionStateListener" interface is implemented on the client, which we use if we actually experience a driver disconnection. For the "Modbus" driver, we must verify the connection based on whether an exception is generated during the read/write process. Specifically, I would focus on the first case: active notification from the driver to the client regarding the connection status. >From what I've seen, other drivers don't support the "ConnectionStateListener" interface, even though it's available. Our use case doesn't require a connection cache. My two cents. El lun, 26 ene 2026 a las 11:59, Christofer Dutz (<[email protected]>) escribió: > Hi all, > > As I’m currently fine tuning with my new drivers, I wanted to take this > discussion here as I think it has value to the project. > Unfortunately many reported issues are related to connection losses, plc > updates and connectivity issues. > > In my current case I was making my ADS driver more stable. Like ours this > generally supports online and offline version changes. > During an online change the PLC remains online and we can instantly start > re-loading the datatype and symbol tables. > With an offline change, the PLC usually reboots and is firstly just flat > offline, then it comes online again, but is not yet able to handle > connections. > > While with the online changes it’s not an issue to transparently reload > the tables and continue running, with offline changes this becomes more > complex. > Initial Claude wanted to update the read logic, to do automatic reconnects > with exponential backoff. > > I however intervened. > > As all of my use-cases generally use the connection cache and follow a > pattern of „get a connection -> do stuff -> put the connection back“, I > think it would be better to fail the operation in case of an offline change > and to have the tool then move the re-connect to the normal connection > establishing code. > > This should greatly simplify the driver logic … what do you think? Should > we make our operations more complex to handle connection losses or should > we fail fast and keep the logic simpler? > > Chris > > -- *CEOS Automatización, C.A.* *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César García* *Cel: +58 414-760.98.95* *Hotline Técnica SIEMENS: 0800 1005080* *Email: [email protected] <[email protected]>*
