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.
Chris
Am 01.04.19, 12:54 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
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 does.
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 ;-)
Chris
Am 01.04.19, 12:29 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>:
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.
Julian
Von meinem Mobiltelefon gesendet
-------- Ursprüngliche Nachricht --------
Betreff: Re: Some of the latest changes
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:
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.
Chris
Am 01.04.19, 10:48 schrieb "Christofer Dutz"
<christofer.d...@c-ware.de>:
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.
Chris
Am 01.04.19, 10:31 schrieb "Strljic, Matthias Milan"
<matthias.strl...@isw.uni-stuttgart.de>:
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.
Greetings
Matthias Strljic, M.Sc.
Universität Stuttgart
Institut für Steuerungstechnik der Werkzeugmaschinen und
Fertigungseinrichtungen (ISW)
Seidenstraße 36
70174 Stuttgart
GERMANY
Tel: +49 711 685-84530
Fax: +49 711 685-74530
E-Mail: matthias.strl...@isw.uni-stuttgart.de
Web: http://www.isw.uni-stuttgart.de
-----Original Message-----
From: Christofer Dutz <christofer.d...@c-ware.de>
Sent: Monday, April 1, 2019 10:06 AM
To: dev@plc4x.apache.org
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 ...
Chris
