Hi,
Earlier, when I worked with CAN devices I had troubles with some
operations failing due to bus utilization, prioritization and so on.
Both read and write. It wasn't connection related, rather device
related, but in order to solve issue I wrote decorators on top of PLC4X
API. So I got a decorated connection which transiently handled failed
read/write attempts. It didn't require any changes in driver itself,
because decorator is a wrapper on top of it. So driver logic remained
mostly the same.
Having said above, we are 3 or 4 years ahead since I done decorators. We
gained some more complex scenarios which actually affect driver logic
and may require a second thought on it.
The end user API is asynchronous, thus if we make inner operations of
driver asynchronous (in fact they are asynchronous in many cases), then
all the application interactions could end up in some coordinated way to
the wire. If we do that, then may be able to silently handle
reconnection attempts, without driver knowing a lot about details.
Problem is - in case of ADS driver we have fairly long handshake which
affects driver internal state. This means that even trivial read
operation may not be fully idempotent, as its handling may depend on i.e
changed type mapping or re-resolving of symbolic name to memory address.
I think such cases can't be solved in a generic way, it requires a
driver level design update where type mapping is i.e separate from
connection. However the TCP/UDP sockets and most basic re-wiring of
these can be done in a portable way by controlling
"ConversationContext". Maybe this context could have an internal
callback to notify driver about stale connection?
I do not have a recipe yet, as its up to us how we deal with it. We have
for example ping/pong api to confirm state of connection, but I don't
think it very extensively used as.. it depends on the driver and
availability of "do nothing, but answer me" operation.
Best,
Łukasz
On 1/27/26 12:23, 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]>*
