You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2019/04/01 08:05:45 UTC

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

Re: Some of the latest changes

Posted by Julian Feinauer <j....@pragmaticminds.de>.

Hey Chris,

I agree and I disagree with you at the same time : )
For specific drivers one should always override the isConnected method (I also updated  the Javadoc there).
But I see it a bit pragmatic and conclude that "most" of the drivers are tcp / udp based so I decided that this is "okay".

But of course, it is not absolutely clean, so I agree with a "cleaner" implementation although I would like to encapsulate it as much as possible to have changes locally.
Perhaps a subclass of the NettyConnection for TCP / UDP?

Julian

Am 01.04.19, 10:16 schrieb "Christofer Dutz" <ch...@c-ware.de>:

    The thing is:
    
    If we start implementing the functionality of a "ping" for other protocol types such as RawIp, RawEthernet, Can, Serial, do we then start also adding "getSocketAddress", getCanIdentifier, getSerialPortId and stuff like that?
    I think that's a pretty unpretty way to do it.
    
    I'll try to whip up a cleaner implementation ...
    
    Chris
    
    
    Am 01.04.19, 10:11 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:
    
        Hi Chris,
        
        this was a decidion I made (and therefore exposed as PR).
        I think this is a good compromise between many protocols being on TCP / UDP and the fact that we want to have the "ping" for most drivers.
        In fact, I intentionally implemented it as an Optional and stated in the JDoc that a non TCP / UDP Driver should return Optional.empty().
        
        Do you agree with that?
        Otherwise, we can of course plan to implement it differently but then it gets more and more tedious and perhaps we are missing something in driver implementations.
        
        Julian
        
        Am 01.04.19, 10:06 schrieb "Christofer Dutz" <ch...@c-ware.de>:
        
            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

Re: Some of the latest changes

Posted by Christofer Dutz <ch...@c-ware.de>.

The thing is:

If we start implementing the functionality of a "ping" for other protocol types such as RawIp, RawEthernet, Can, Serial, do we then start also adding "getSocketAddress", getCanIdentifier, getSerialPortId and stuff like that?
I think that's a pretty unpretty way to do it.

I'll try to whip up a cleaner implementation ...

Chris


Am 01.04.19, 10:11 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:

    Hi Chris,
    
    this was a decidion I made (and therefore exposed as PR).
    I think this is a good compromise between many protocols being on TCP / UDP and the fact that we want to have the "ping" for most drivers.
    In fact, I intentionally implemented it as an Optional and stated in the JDoc that a non TCP / UDP Driver should return Optional.empty().
    
    Do you agree with that?
    Otherwise, we can of course plan to implement it differently but then it gets more and more tedious and perhaps we are missing something in driver implementations.
    
    Julian
    
    Am 01.04.19, 10:06 schrieb "Christofer Dutz" <ch...@c-ware.de>:
    
        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

Re: Some of the latest changes

Posted by Julian Feinauer <j....@pragmaticminds.de>.

Hi Chris,

this was a decidion I made (and therefore exposed as PR).
I think this is a good compromise between many protocols being on TCP / UDP and the fact that we want to have the "ping" for most drivers.
In fact, I intentionally implemented it as an Optional and stated in the JDoc that a non TCP / UDP Driver should return Optional.empty().

Do you agree with that?
Otherwise, we can of course plan to implement it differently but then it gets more and more tedious and perhaps we are missing something in driver implementations.

Julian

Am 01.04.19, 10:06 schrieb "Christofer Dutz" <ch...@c-ware.de>:

    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

Re: Some of the latest changes

Posted by Christofer Dutz <ch...@c-ware.de>.

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" <ch...@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....@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" <ch...@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" <ma...@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 <ch...@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

Re: Some of the latest changes

Posted by Christofer Dutz <ch...@c-ware.de>.

But it turns out you have to explicitly activate it. Perhaps reading the metadata (serial number etc.) As we do it in the connection process is the way to go. However I have to find out how to do this without making LOGO PLCs angry and hanging up.

Chris

Outlook für Android<https://aka.ms/ghei36> herunterladen

________________________________
From: Christofer Dutz <ch...@c-ware.de>
Sent: Monday, April 8, 2019 3:09:57 PM
To: dev@plc4x.apache.org
Subject: Re: Some of the latest changes

Hi all,

And for S7 it seems that the address: MB0 usually contains the Clock byte which is located in the memory block (the one we just recently fixed)
So maybe that should work as a ping operation: read "MB0:Byte"

Chris

Am 01.04.19, 12:54 schrieb "Christofer Dutz" <ch...@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....@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" <ch...@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" <ma...@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 <ch...@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

Re: Some of the latest changes

Posted by Christofer Dutz <ch...@c-ware.de>.

Hi all,

And for S7 it seems that the address: MB0 usually contains the Clock byte which is located in the memory block (the one we just recently fixed)
So maybe that should work as a ping operation: read "MB0:Byte"

Chris

Am 01.04.19, 12:54 schrieb "Christofer Dutz" <ch...@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'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....@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.

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.

Chris

Am 01.04.19, 10:48 schrieb "Christofer Dutz" <ch...@c-ware.de>:

Hi Matthias and all others,

Chris

Am 01.04.19, 10:31 schrieb "Strljic, Matthias Milan" <ma...@isw.uni-stuttgart.de>:

Hi Chris,

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 <ch...@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?

... continuing to evaluate ...

Chris

Re: Some of the latest changes

Posted by Christofer Dutz <ch...@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'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....@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.

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.

Chris

Am 01.04.19, 10:48 schrieb "Christofer Dutz" <ch...@c-ware.de>:

Hi Matthias and all others,

Chris

Am 01.04.19, 10:31 schrieb "Strljic, Matthias Milan" <ma...@isw.uni-stuttgart.de>:

Hi Chris,

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 <ch...@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?

... continuing to evaluate ...

Chris

AW: Some of the latest changes

Posted by Julian Feinauer <j....@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.

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.

Chris

Am 01.04.19, 10:48 schrieb "Christofer Dutz" <ch...@c-ware.de>:

Hi Matthias and all others,

Chris

Am 01.04.19, 10:31 schrieb "Strljic, Matthias Milan" <ma...@isw.uni-stuttgart.de>:

Hi Chris,

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 <ch...@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?

... continuing to evaluate ...

Chris

Re: Some of the latest changes

Posted by Christofer Dutz <ch...@c-ware.de>.

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.

Chris

Am 01.04.19, 10:48 schrieb "Christofer Dutz" <ch...@c-ware.de>:

Hi Matthias and all others,

Chris

Am 01.04.19, 10:31 schrieb "Strljic, Matthias Milan" <ma...@isw.uni-stuttgart.de>:

Hi Chris,

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 <ch...@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?

... continuing to evaluate ...

Chris

AW: Some of the latest changes

Posted by Julian Feinauer <j....@pragmaticminds.de>.

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,

Chris

Am 01.04.19, 10:31 schrieb "Strljic, Matthias Milan" <ma...@isw.uni-stuttgart.de>:

Hi Chris,

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 <ch...@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?

... continuing to evaluate ...

Chris

Re: Some of the latest changes

Posted by Christofer Dutz <ch...@c-ware.de>.

Hi Matthias and all others,

Chris

Am 01.04.19, 10:31 schrieb "Strljic, Matthias Milan" <ma...@isw.uni-stuttgart.de>:

Hi Chris,

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 <ch...@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?

... continuing to evaluate ...

Chris

RE: Some of the latest changes

Posted by "Strljic, Matthias Milan" <ma...@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 <ch...@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