An option would be to add a auto-reconnect option. At least that is what I've seen on gopcua.
- Sebastian On 2026/01/27 08:23:28 Christofer Dutz wrote: > 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]>* >
