plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <>
Subject Re: Some of the latest changes
Date Mon, 08 Apr 2019 12:58:05 GMT
So has anyone had the chance to have a look at my alternate proposal for the ping() method?

It's in "feature/alternalte-PLC4X-108" branch.

As I think I mentioned what I don't quite like with the current ping to Julian at Building
IoT, maybe a summary for you guys here.

PLCs are pretty stupid pieces of machinery when it comes to network connectivity.
- The "Open a TCP connection and see if someone picks up" is not that ideal. The reason for
this is that it blocks resources on the PLC ... cause the PLC will definitely be waiting for
something to come through the line (which will never come) I would not expect all PLCs to
handle this case gracefully.
- Every PLC can only support a limited amount of connections ... this ping might be draining
the pool of connections available
- It doesn't really check if there's something alive at the end (Is the PLC halted, is it
actually a PLC that is able to talk using a given protocol)
- For S7 for example S7-STEP7 and S7-TIA will use the same TCP port ... but probably not all
PLCs will support both protocols. So a ping might be successful, but a connect will fail
- Not all protocols use TCP ... with UDP protocols this check will not succeed.

So I would opt for implementing a default operation used to ping using the protocol at hand.
I bet there are defaults that should work for all PLC types using the same protocol .. sort
of a "SELECT 1" in MySQL.


Am 01.04.19, 12:54 schrieb "Christofer Dutz" <>:

    Yeah ... 
    I guess we have to distinguish between 3 things:
    1) The physical connection itself
    2) The logical connection in the protocol
    3) Testing if the logical connection is practically usable
    I guess for 1) and 2) that's what we already have and what the "isConnected" in the NettyPlcDriver
    I agree, we need something for 3) .. but I wouldn't call the current solution "the best
approach" ...
    I'll try to whip up an alternate proposal in a feature branch ...
    Got plenty of time anyway ;-)
    Am 01.04.19, 12:29 schrieb "Julian Feinauer" <>:
        Hi Chris,
        Please keep in mind how this came to life.
        We always discussed a sensible and driver specific ping method, like in the S7 case
do a query against the slz or so.
        This is the best approach.
        The current approach works very inoptinal as observed in many applications from us
and also Gunter. Thus, I see this as a first step from not so good to a bit better.
        But ideally we implement something really good for each protocol.
        At least now we observe disconnects way faster as before which is important in many
use cases.
        Von meinem Mobiltelefon gesendet
        -------- Ursprüngliche Nachricht --------
        Betreff: Re: Some of the latest changes
        Von: Christofer Dutz
        Another problem I am seeing is that there is a great difference between ping and isConnected.
        Ping simply checks if there is someone answering at the other side. While isConnected
also gives an answer to the current state of the protocol connection.
        So it is for example possible to still have a valid TCP connection but the protocol
has already said goodbye and therefore the connection is disconnected. Or which is much more
likely, the TCP connection has just been established, however the handshake has not yet been
successful. Especially with protocols like S7 and EthernetIp where the connection requires
multiple interactions with the remote and there is a goodbye in the protocol,
        This is important.
        Am 01.04.19, 10:48 schrieb "Christofer Dutz" <>:
            Hi Matthias and all others,
            Well actually, prior to these changes, the AbstractPlcConnection didn't have any
code that was somehow related to the way communication is done. It sort of just provides the
default implementations for all of our APIs functions:
            - readRequestBuilder
            - writeRequestBuilder
            - subscribeRequestBuilder
            - unsubscribeRequestBuilder
            So implementations only need to implement the methods it actually supports and
for all others the default PlcUnsupportedOperationException throwing versions are used.
            Currently the part where the underlying connection-media comes in is in NettyPlcConection
but here it's still agnostic to the type of connection ... So both serial and ip based connections
use the same base-class.
            The type of connection is here passed in via the ChannelFactory where currently
the following flavors are available:
            - TcpSocketChannelFactory
            - SerialChannelFactory
            - RawSocketChannelFactory
            - UdpSocketChannelFactory (Doesn't exist but would need to implement this for
KNX protocol)
            So instead I would suggest to move the ping method into the ChannelFactory instead
and to implement the isConnected method in the NettyPlcConnection class, which then uses the
ChannelFactory's implementation to actually do the check.
            Am 01.04.19, 10:31 schrieb "Strljic, Matthias Milan" <>:
                Hi Chris,
                There I would throw in a counter-question, namely whether it would be important
at this level to distinguish between automation protocols and fieldbus systems as AbstracConnectors?
Because Profinet and EtherCat are protocols that differ a bit from the data handling of an
OPC UA, ADS or S7 and are also quite sensitive regarding the deterministic real-time (EtherCat
is a bit looser). Those types need a bit more configuration information like message structure,
pull rate and master node.
                Then, of course, it would have to be evaluated whether these two communication
systems should be separated and whether automation protocols exist on a basis other than TCP/UDP?
                Just take it as creative discussion point.
                Matthias Strljic, M.Sc.
                Universität Stuttgart
                Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen
                Seidenstraße 36
                70174 Stuttgart
                Tel: +49 711 685-84530
                Fax: +49 711 685-74530
                -----Original Message-----
                From: Christofer Dutz <>
                Sent: Monday, April 1, 2019 10:06 AM
                Subject: Some of the latest changes
                Hi all,
                today I simply have a little time to inspect the latest changes as I was travelling
for 5 days ... I do have a few questions:
                Why is AbstractPlcConnection been extended by a getInetSocketAddress method?
                PlcConnections are not bound exclusively to TCP/UDP ... we currently already
have Serial port based connections and when going into protocols like Profinet and EtherCat
in the future we'll be going down to IP or even Ethernet level.
                I don't like TCP/UDP details in the base abstract class for all drivers.
                ... continuing to evaluate ...

View raw message