plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: Some of the latest changes
Date Mon, 01 Apr 2019 08:47:53 GMT
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.strljic@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.strljic@isw.uni-stuttgart.de
    Web: http://www.isw.uni-stuttgart.de
    
    -----Original Message-----
    From: Christofer Dutz <christofer.dutz@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
    

Mime
View raw message