Hi Chris,
I agree with that.
In fact most of these classes was pretty new to me so i did not find the
optimal way.
Julian
Von meinem Mobiltelefon gesendet
-------- Ursprüngliche Nachricht --------
Betreff: Re: Some of the latest changes
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:
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
