Test 2

[Christofer Dutz]

As more emails seem to be going through ... Another test (sorry for the noise)

Outlook für Android herunterladen

Problems with emails

[Christofer Dutz]

Hi all,

It seems that Apache had a major mail server problem and are now running a new 
mail server. Unfortunately this new server seems to be blocked or rate limited 
by some services.

So if I don't respond to questions ... You are not being ignored and maybe you 
are not getting responses.

I'll try to work with lists.apache.org till that's sorted out.

Chris

Outlook für Android herunterladen

Test

[Christofer Dutz]

Test to check email sending ...

Outlook für Android herunterladen

Integration of other Languages / Daffodil

[Bjoern Hoeper]

Hi everyone,
I got in touch with Chris and Julian during the buildingIoT Conference in 
Cologne and I would like to participate in the further development of PLC4X. 
Our main interest is to extend PLC4X to make it usable with .NET / C#.

So after looking at the sources and the discussions in the mailing list I was 
wondering what would be the best move forward regarding the integration of 
other languages in general and the decoupling of the protocol definition from 
the actual API implementation in a particular language. As far as I understand 
the current status Apache Daffodil is  a candidate technology for generating 
the adapter code. But at the current moment Daffodil does not support 
templating of classes. Furthermore there are existing APIs for Java and Scala 
but no implementation for languages not executed on the JVM so we would need to 
have an implementation of the Daffodil APIs in every language we want to 
support in the future.
Are there any Ideas existing already about an Architecture to support languages 
besides Java? If not I would like to encourage a discussion about this topic 
because I think it will get quite fundamental as soon as the adoption of 
further languages gains some traction.
Best Regards
Björn

=
Dipl.-Ing. B. Höper
Geschäftsführer

LTSoft - Agentur für Leittechnik-Software GmbH
Veilchenweg 37a
51107 Köln

Telefon:   +49 (0) 221 - 79 00 35 31
Telefax:   +49 (0) 221 - 79 00 35 35
Mobil:  +49 (0) 173 - 28 36 904
Email:  hoe...@ltsoft.de
=

Re: Some of the latest changes

[Christofer Dutz]

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" :

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" :

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" 
:

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" 
:

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 

Re: Some of the latest changes

[Christofer Dutz]

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" :

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" :

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" 
:

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
 

Re: Documentation for Kafka integration

[Christofer Dutz]

Oh Hi Andreas,

sorry for not replying ... when I'm travelling I tend to get distracted by 
stuff ;-)

I guess that in this case documentation will require digging into the code and 
writing up how to start a Kafka-Connect node ... if you have experience with 
that, feel free to document that, but I guess probably not ... I too am not 
that deep into it and will do exactly that as I do need to understand this for 
a call tomorrow evening ;-)

Chris



Am 04.04.19, 06:35 schrieb "Andreas Oswald" :

Hi Chris,

let me know if I can be of help with this documentation issue?

Take care

Andreas

Andreas Oswald
Marienstraße 12
52223 Stolberg

++49 2402 905 3852
++49 162   259 8005



Von: Christofer Dutz 
Gesendet: Mittwoch, 3. April 2019 14:00
An: dev@plc4x.apache.org
Betreff: Re: Documentation for Kafka integration

Hi all,

Guess I'll use the trip home from building IoT to extract some form of 
documentation from the code. Should be possible. The original author send to be 
drowned in paid work at the moment :-(

So please be patient ... We really, really, really need to work on 
documentation.

Chris

Outlook für Android herunterladen


From: Julian Feinauer 
Sent: Wednesday, April 3, 2019 1:03:00 PM
To: dev@plc4x.apache.org
Subject: AW: Documentation for Kafka integration

Hi Stefan,

Indeed you are right.
Perhaps, we should also modify it to be based on the scraper.

But there is an example in the example folder, perhaps you should check 
that out first?

Julian

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: Documentation for Kafka integration
Von: Stefan Schulze
An: dev@plc4x.apache.org
Cc:

Hi,

I just attended a great talk of Christofer at „building IoT“ and I‘m  
interested to try out the Kafka integration with kafka-connect.
Sadly, there is rather no documentation of this plugin regarding the 
configuration or something. Do you have any ressources available I haven‘t 
found?

Thank you,
  Stefan