Re: PLC4X support

[Christofer Dutz]

I Chen,

Great hearing from you.
I would be happy to help you with your suport needs via Timecho. Timecho is a 
China based commercial support entity around apache iotdb, but since me joining 
them last year also offering support for plc4x.

Fun fact: I used to work for Dematic Germany. So I at least already know part 
of your business :-)

I'm currently on PTO, but will be happy to follow up with you next week.

Chris

Gesendet von Outlook für Android

From: Chen Shuyi (Shayne) 
Sent: Thursday, May 9, 2024 2:29:02 PM
To: dev@plc4x.apache.org 
Cc: Li Shuo (Shawn) 
Subject: PLC4X support


Hi,





I’m from Dematic China which is a intralogisitic solution supplier, our 
equipment includes PLC which have many interaction with other IT application.

We are developping an application which is for Autonomous Mobile Robot system 
work together with automation.



PLC4X maybe is a right choice for communication suite for PLC and IT 
integration.



Our system scale is around 1000 PLC tags communicating with a software called 
DCS.



The PLCs are OPC, Modbus-TCP, Profinet(S7) and Ethernet/IP and PLC4x will be 
deployed on Redhat or SUSE.



Is that possible PLC4x support such application?



Our engineer Shawn Li do a demo POC, but it isn’t so successful, PLC4X showed 
too many session error and it read OPC tag around 28s.



I wonder if there is any manual or instructions can give our development some 
direction.



We are willing to use PLC4x as a formal suite in our software in forture(could 
be public on your customer list).



If it is possible, we develop a communication driver, I wonder if we buy a 
commercial support

1. what kind of support we can get by commercial support?
2. What is the price?
3. How you charge the support fee, by a company?
4. We will get some manuals or documents?
5. If any issues happened, how you support us to solve those issues?





Shuyi Chen
AMR RCOE - Senior Operation Manager
Dematic Global Robotics


[KionDematic1]
We Optimize Your Supply Chain  www.dematic.com

CONFIDENTIALITY NOTICE: This email message and any attachments to it, is 
intended only for the individual or entity to which it is addressed and may 
contain confidential material. If you are not the intended recipient, or the 
employee or agent responsible for delivering it to the intended recipient, 
please do not disclose, copy, forward, or retain. If you have received this in 
error, please contact the sender by reply email and destroy all copies of the 
original message. ​​​

Re: PLC4X - 0.11.0 - Issue writing value to a Beckhoff PLC using ads driver

[Łukasz Dywicki]

Hey Chris and Patrick,
I've had a look on ADS driver in context of TC2 and I found that i.e. 
subscriptions do not work when initial symbol discovery is disabled 
(load-symbol-and-data-type-tables=false).


Subscriptions did fail due to missing data type mapping, even for most 
basic types. I suppose that it could be same for writing where a proper 
write buffer needs to be allocated.


Best,
Łukasz

On 17.10.2023 13:40, Patrick Boisclair wrote:

Hi Chris,

I will continue to investigate and test today and I'll share what I can find.

The PLC type is a "CX8190 / Standard"

I really appreciate your help on this.



Patrick Boisclair
Email: pboiscl...@noovelia.com
-Original Message-
From: Christofer Dutz 
Sent: Tuesday, October 17, 2023 3:14 AM
To: dev@plc4x.apache.org
Subject: AW: PLC4X - 0.11.0 - Issue writing value to a Beckhoff PLC using ads 
driver

Attention: Courriel provenant de l'externe. Veuillez valider la source et le 
contenu avant de cliquer sur un lien ou d'ouvrir un document.


Hi Patrick,

that’s odd … I think I didn’t change anything with respect to the decoding of 
datatypes. A quick look showed me that it has been mostly unchanged since 
before the last release.
The only changes I did there were fixing some character and string handling 
issues.  So, I guess your problem must have a different source.

Next to the automated tests, we also have the “ManualTests”, which can only be 
executed if you possess an ADS device and declare a pre-defined datastructure 
and values.
One of the tests is this:
test.addTestCase("MAIN.hurz_DINT", new PlcDINT(-242442424)); So, this test 
reads the variable hurz_DINT from the plc and compares it with the expected value, then 
it writes it back.
If the writing wouldn’t be working, I probably couldn’t execute the test more 
than once. However, I am perfectly able to do that.

Do you have an idea what could else be causing this problem you are having? 
Could you please share with us, the exact type of your PLC?
I could ask my folks at Beckhoff to what the problem could be.

Chris

Von: Patrick Boisclair 
Datum: Dienstag, 17. Oktober 2023 um 03:03
An: dev@plc4x.apache.org 
Betreff: PLC4X - 0.11.0 - Issue writing value to a Beckhoff PLC using ads 
driver Hi all,

I upgraded from version 0.9.1 to 0.11.0 and I cannot write to my Beckhoff PLC 
anymore.

When I write 1 to a DINT, 16777216 is stored.

Is it a BIG-ENDIAN vs LITTLE-ENDIAN issue ?
Is it possible to specify the “endianness” of the PLC ?

According to the TWINCat doc, it seems they use LITTLE-ENDIAN.

Any information would be grateful.

Thank you very much and best regards.



Patrick Boisclair
Analyste Programmeur Sénior, Automatisation ‑ IoT Senior Analyst Programmer, Automation ‑ IoT 
noovelia.com
[Facebook]
[LinkedIn]
[Vimeo]

Re: PLC4X Community Call today 19:00 CET

[Lukas Ott]

+1

Am Di., 6. Sept. 2022 um 13:38 Uhr schrieb Christofer Dutz <
christofer.d...@c-ware.de>:

> Hi all,
>
> I just wanted to remind you, that it’s the first Tuesday of the month
> again and therefore it’s time for another community call.
>
> You can join, with this link:
> https://us06web.zoom.us/j/91591629512?pwd=Z3A1WTdNbXRmMnZIZ2c3SVdYaHo3QT09
>
> If you plan to attend, please reply to this email thread.
>
> Chris
>
>

Re: PLC4X Error

[Lukas Ott]

Hi Zap,

Welcome to our mailing list :-)

Can you give us a little bit more details.
What version of PLC4X are you running and is this a Kafka related error or
does the error occur from the modbus driver and then which Modbus driver.
(Does the error also occur when connecting to the Modbus Device without
Kafka)

Thank you!

Best regards,
otluk

Am Fr., 1. Apr. 2022 um 09:27 Uhr schrieb Zap Tashkilot :

>
> Hi
>
> I want to implement PLC4X and Kafka in some of our projects but it seems
> to be some errors that I can't get rid of, I hope you can help with that.
>
> ERROR [plc-modbus-source|task-0] WorkerSourceTask{id=plc-modbus-source-0}
> Task threw an uncaught and unrecoverable exception. Task is being killed
> and will not recover until manually restarted
> (org.apache.kafka.connect.runtime.WorkerTask:195)
> java.lang.NoClassDefFoundError:
> com/fasterxml/jackson/dataformat/yaml/YAMLFactory
>
> thanks in advanced
>
>
> Best Regards/Med venlig hilsen
> Zap Tashkilot
> Project Engineer/Projektingeniør
>
> +45 61812840
> Kontakt mig på Teams<
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fteams.microsoft.com%2Fl%2Fchat%2F0%2F0%3Fusers%3DZap.Tashkilot%40Logimatic.dk&data=04%7C01%7Czap%40logimatic.dk%7C4498ba7211824a56b08408d9c54fde26%7C42712bb734fd467d9467b16fff25db5d%7C1%7C0%7C637757769284141272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=Aq1VsyZjSQ8iPyuyLzztLLSYO%2B1xP%2FrlpVq0BAjj6Vo%3D&reserved=0
> >
>
> LOGIMATIC Find Logimatic på LinkedIn<
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Flogimatic&data=04%7C01%7Czap%40logimatic.dk%7C4498ba7211824a56b08408d9c54fde26%7C42712bb734fd467d9467b16fff25db5d%7C1%7C0%7C637757769284141272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=wxvosODhPe2n%2F5gOVcq%2FDi%2Bxirm2Spl9xJzqC061hpc%3D&reserved=0>
> eller Facebook<
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2FLogimatic.dk&data=04%7C01%7Czap%40logimatic.dk%7C4498ba7211824a56b08408d9c54fde26%7C42712bb734fd467d9467b16fff25db5d%7C1%7C0%7C637757769284151273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=iuT9LFAuq6kZ7j4DZuu03bAd1ycI9KduoX8WIOEkF%2B4%3D&reserved=0
> >
> Besøg logimatic.dk<
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.logimatic.dk%2F&data=04%7C01%7Czap%40logimatic.dk%7C4498ba7211824a56b08408d9c54fde26%7C42712bb734fd467d9467b16fff25db5d%7C1%7C0%7C637757769284151273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=QYrA80IgHTQxkT%2BqHFcqEh7a1i9EMRD64HE38E29GHY%3D&reserved=0
> >
>
>

RE: PLC4X Adoption Listing

[Christofer Dutz]

Hi Cole,

thanks for your feedback and kind words … that’s the fuel that keeps us going 
;-)

Unfortunately, file attachments get stripped off the emails to this list … if 
you send it to me in a direct email I can take care of that.

Chris

From: Cole Snyder 
Sent: Freitag, 19. November 2021 19:28
To: dev 
Subject: PLC4X Adoption Listing

Hello there!

I saw your adopters page and I wanted to provide some information in case you 
would like to list us amongst your adopters.

Company: Gmork Tech LLC

Website: https://www.gmork.tech

Market: IIoT / Software / Cloud

Description: We are currently refactoring our enterprise SCADA application to 
make use of PLC4X for data acquisition. Our application is focused on being 
audit-friendly and providing accountability via a robust notification and 
acknowledgment system.

Location: We're based out of Hagerstown, Maryland in the United States.

And I've attached (an absolutely massive version of) our logo/banner

We appreciate everything you've done. PLC4X has made our job a thousand times 
easier already and we can't wait to see what you do with it next.

As we grow we hope to do our part and contribute to your code, but for right 
now we're still fairly small and just getting started.


Many thanks,
Cole Snyder
Gmork Tech LLC

Re: plc4x summary from 1bd132a to f97d36f (buffer changes and test framework)

[Sebastian Rühl]

Somehow the mailing list removed all the bullet points (apparently it doesn’t 
like html mails). Here again hopefully readable as plain text:

TLDR: changes in plc4x which help developing drivers across languages that have 
no effect how plc4x send/receiver data or how you use the API

As of the last mail `Progress on plc4go` from 15.03.2021 I want to give another 
overview what has happened between 1bd132a to f97d36f

1. Changes on read/write buffers In plc4go and plc4j
a. Note the below changes don’t have any impact on the API on 
plc4x nor on the way data is written onto the wire
b. Existing buffers (which were byte base [writing and reading 
bytes to a underlying reader/writer]) had an interface introduced which 
abstracted the interaction from plc4x from the representation (reason for that 
described in point 5).
c. Write buffer
i. 2 New methods added
1. PushContext: Indicates that the model is 
about to write data which is enclosed by a logical context
2. PopContext: Indicates that the model is done 
writing data which is enclosed by a logical context
ii. Every method got a logicalName and a 
varargs/variadic writerArguments added
1. LogicalName: indicates the logical name of 
the data which is about to be written (e.g. checksum flag, address)
2. WriterArguments: are optional hints about 
the data being written (e.g. name of the enum [e.g.ADS_READ] being written, or 
if a logical context is a list)
iii. The above points are completely ignored by the 
byte based writers (which got renamed with the introduction of the interface to 
*ByteBased) as the above changes don’t have any impact on byte based writing 
(They could be used for log tracing for better debugging in the future)
d. Read buffer
i. 2 New methods added
1. PullContext: indicates that the model is 
about to read data which is enclosed by a logical context
2. CloseContext: Indicates that the model is 
done reading data which is enclosed by a logical context
ii. Every method got a logicalName and a 
varargs/variadic readerArguments added
1. LogicalName: indicates the logical name of 
the data which is about to be read (e.g. checksum flag, address)
2. ReaderArguments: are optional hints about 
the data being read (e.g. name of the enum [e.g.ADS_READ] being written, or if 
a logical context is a list)
iii. The above points are completely ignored by the 
byte based readers (which got renamed with the introduction of the interface to 
*ByteBased) as the above changes don’t have any impact on byte based writing 
(They could be used for log tracing for better debugging in the future)
e. On plc4j the old methods are still available as default 
methods but will be deprecated in the future (The buffers are meant to be used 
in the context of the generated models which uses the new interfaces)
f. In the future I plan on adding new byte/byte[] based methods 
to better encapsulate logical context on byte/byte[] fields which can then be 
better rendered by implementors of the buffer interfaces (mostly required by 
non byte based buffers). See my other mail on the mailing list about bytes 
(https://lists.apache.org/thread.html/r5285838fd0b53d50fca34c2539b2d12ac275361d4faf5df36f3ec804@%3Cdev.plc4x.apache.org%3E).
2. Refactoring in golang SPI
a. Added default implementations for connection and codec
i. Moved default implementation into a spi/default 
package
1. These can be configured with variadic 
WithOption calls
ii. Moved duplicated codes into commons classes
iii. At the moment these a realized with a cycling 
dependency for callback which get refactored to a non cyclic approach in the 
future
b. Added default implementations for request and response
c. Removed cyclic dependency from request interceptor
cd Ported the request transaction manager from java
i At the moment this is a 1:1 port from java and 
doesn’t make full use of the native golang features. The TM was required by the 
s7 driver to prevent clients from overloading a plc4x (which could lead to a 
huge RL crash ;) )
e. Added Ascii/Xml/Json buffers described in point 4 and 5
f. Updated goDocs
3. S7 Driver in plc4go
a. Implemented the S7 driver into plc4go
b. In the course of this I fixed several bugs and initially 
with the ads driv

Re: PLC4x integration for Profinet

[Łukasz Dywicki]

Kudos should go primarily to Adrian who cleaned up mspec, tested it
against real hardware and added missing parts. My role was limited to
assistance in few places.

Looking forward to work with him and others on next steps.

Best,
Łukasz

On 19.04.2021 19:56, Lukas Ott wrote:
> +1 Lukasz you are awesome!
> 
> Am Mo., 19. Apr. 2021 um 19:33 Uhr schrieb Łukasz Dywicki <
> l...@code-house.org>:
> 
>> I've pushed few additional changes to features/profinet2 branch.
>>
>> Now it is possible to interact through PLC4X api. At least for
>> identification calls.
>> Sample client code:
>> https://gist.github.com/splatch/f1554f0775b2b20df072f51a98ad280b
>>
>> Best,
>> Łukasz
>>
>> On 19.04.2021 11:34, Łukasz Dywicki wrote:
>>> Hey Mehta,
>>> Our progress on profinet so far is limited just to one section - namely
>> DCP.
>>> Adrian Lazar (in CC) and I work together in two places:
>>> https://github.com/Adito5393/plc4x/tree/feature/profinet2-setConfigs/
>>> https://github.com/apache/plc4x/tree/feature/profinet2
>>>
>>> So far we been able to cover tagged/untaged frames, DCP broadcasts, DCP
>>> answers. Next things include implementation of actual protocol
>>> logic/structure mapping and attempt to interact with DCP GET/SET calls.
>>> I plan to work on first parts of logic this week.
>>> Please be aware that profinet protocol currently java only and rely on
>>> pcap4j transport which is quite slow. It is listening at very top of
>>> operating system network stack hence its not intended for control
>>> scenarios. Libpcap is also known of having some issues with Windows
>>> which Adrian tried to address.
>>>
>>> Feel free to attach your sample PCAPs/GSDML here:
>>> https://issues.apache.org/jira/browse/PLC4X-8
>>> We won't be able to build full profinet stack anytime soon but we'll
>>> definitely be able to do data acquisition. Any help is welcome.
>>>
>>> Kind regards,
>>> Łukasz
>>>
>>>
>>> On 19.04.2021 10:18, Mehta Vineet wrote:

 I came across Apache PLC4x while researching for a way to read sensor
>> data over Profinet. How far along is the integration? Any idea when it will
>> be made available?

 Mit freundlichen Grüßen / With best regards

 Vineet Mehta
 Praktikant

 ruhlamat GmbH
 Sonnenacker 2, 99834 Gerstungen OT Marksuhl
 phone:

 +49 (0)36925 929-

 v.me...@ruhlamat.de

 fax:

 +49 (0)36925 929-501

 http://www.ruhlamat.de


 [https://www.ruhlamat.com/sites/all/themes/ruhlamat/logo1.png]

 [GF/Management: Thomas Mack, Karl Mack] - [Amtsgericht Jena/Local Court
>> Jena: HRB 401145]
 [Firmensitz/Registered Office: Marksuhl] - [Ust-ID Nr.: DE 150382006]



>>
> 

Re: PLC4x integration for Profinet

[Lukas Ott]

+1 Lukasz you are awesome!

Am Mo., 19. Apr. 2021 um 19:33 Uhr schrieb Łukasz Dywicki <
l...@code-house.org>:

> I've pushed few additional changes to features/profinet2 branch.
>
> Now it is possible to interact through PLC4X api. At least for
> identification calls.
> Sample client code:
> https://gist.github.com/splatch/f1554f0775b2b20df072f51a98ad280b
>
> Best,
> Łukasz
>
> On 19.04.2021 11:34, Łukasz Dywicki wrote:
> > Hey Mehta,
> > Our progress on profinet so far is limited just to one section - namely
> DCP.
> > Adrian Lazar (in CC) and I work together in two places:
> > https://github.com/Adito5393/plc4x/tree/feature/profinet2-setConfigs/
> > https://github.com/apache/plc4x/tree/feature/profinet2
> >
> > So far we been able to cover tagged/untaged frames, DCP broadcasts, DCP
> > answers. Next things include implementation of actual protocol
> > logic/structure mapping and attempt to interact with DCP GET/SET calls.
> > I plan to work on first parts of logic this week.
> > Please be aware that profinet protocol currently java only and rely on
> > pcap4j transport which is quite slow. It is listening at very top of
> > operating system network stack hence its not intended for control
> > scenarios. Libpcap is also known of having some issues with Windows
> > which Adrian tried to address.
> >
> > Feel free to attach your sample PCAPs/GSDML here:
> > https://issues.apache.org/jira/browse/PLC4X-8
> > We won't be able to build full profinet stack anytime soon but we'll
> > definitely be able to do data acquisition. Any help is welcome.
> >
> > Kind regards,
> > Łukasz
> >
> >
> > On 19.04.2021 10:18, Mehta Vineet wrote:
> >>
> >> I came across Apache PLC4x while researching for a way to read sensor
> data over Profinet. How far along is the integration? Any idea when it will
> be made available?
> >>
> >> Mit freundlichen Grüßen / With best regards
> >>
> >> Vineet Mehta
> >> Praktikant
> >>
> >> ruhlamat GmbH
> >> Sonnenacker 2, 99834 Gerstungen OT Marksuhl
> >> phone:
> >>
> >> +49 (0)36925 929-
> >>
> >> v.me...@ruhlamat.de
> >>
> >> fax:
> >>
> >> +49 (0)36925 929-501
> >>
> >> http://www.ruhlamat.de
> >>
> >>
> >> [https://www.ruhlamat.com/sites/all/themes/ruhlamat/logo1.png]
> >>
> >> [GF/Management: Thomas Mack, Karl Mack] - [Amtsgericht Jena/Local Court
> Jena: HRB 401145]
> >> [Firmensitz/Registered Office: Marksuhl] - [Ust-ID Nr.: DE 150382006]
> >>
> >>
> >>
>

Re: PLC4x integration for Profinet

[Łukasz Dywicki]

I've pushed few additional changes to features/profinet2 branch.

Now it is possible to interact through PLC4X api. At least for
identification calls.
Sample client code:
https://gist.github.com/splatch/f1554f0775b2b20df072f51a98ad280b

Best,
Łukasz

On 19.04.2021 11:34, Łukasz Dywicki wrote:
> Hey Mehta,
> Our progress on profinet so far is limited just to one section - namely DCP.
> Adrian Lazar (in CC) and I work together in two places:
> https://github.com/Adito5393/plc4x/tree/feature/profinet2-setConfigs/
> https://github.com/apache/plc4x/tree/feature/profinet2
> 
> So far we been able to cover tagged/untaged frames, DCP broadcasts, DCP
> answers. Next things include implementation of actual protocol
> logic/structure mapping and attempt to interact with DCP GET/SET calls.
> I plan to work on first parts of logic this week.
> Please be aware that profinet protocol currently java only and rely on
> pcap4j transport which is quite slow. It is listening at very top of
> operating system network stack hence its not intended for control
> scenarios. Libpcap is also known of having some issues with Windows
> which Adrian tried to address.
> 
> Feel free to attach your sample PCAPs/GSDML here:
> https://issues.apache.org/jira/browse/PLC4X-8
> We won't be able to build full profinet stack anytime soon but we'll
> definitely be able to do data acquisition. Any help is welcome.
> 
> Kind regards,
> Łukasz
> 
> 
> On 19.04.2021 10:18, Mehta Vineet wrote:
>>
>> I came across Apache PLC4x while researching for a way to read sensor data 
>> over Profinet. How far along is the integration? Any idea when it will be 
>> made available?
>>
>> Mit freundlichen Grüßen / With best regards
>>
>> Vineet Mehta
>> Praktikant
>>
>> ruhlamat GmbH
>> Sonnenacker 2, 99834 Gerstungen OT Marksuhl
>> phone:
>>
>> +49 (0)36925 929-
>>
>> v.me...@ruhlamat.de
>>
>> fax:
>>
>> +49 (0)36925 929-501
>>
>> http://www.ruhlamat.de
>>
>>
>> [https://www.ruhlamat.com/sites/all/themes/ruhlamat/logo1.png]
>>
>> [GF/Management: Thomas Mack, Karl Mack] - [Amtsgericht Jena/Local Court 
>> Jena: HRB 401145]
>> [Firmensitz/Registered Office: Marksuhl] - [Ust-ID Nr.: DE 150382006]
>>
>>
>>

Re: PLC4x integration for Profinet

[Łukasz Dywicki]

Hey Mehta,
Our progress on profinet so far is limited just to one section - namely DCP.
Adrian Lazar (in CC) and I work together in two places:
https://github.com/Adito5393/plc4x/tree/feature/profinet2-setConfigs/
https://github.com/apache/plc4x/tree/feature/profinet2

So far we been able to cover tagged/untaged frames, DCP broadcasts, DCP
answers. Next things include implementation of actual protocol
logic/structure mapping and attempt to interact with DCP GET/SET calls.
I plan to work on first parts of logic this week.
Please be aware that profinet protocol currently java only and rely on
pcap4j transport which is quite slow. It is listening at very top of
operating system network stack hence its not intended for control
scenarios. Libpcap is also known of having some issues with Windows
which Adrian tried to address.

Feel free to attach your sample PCAPs/GSDML here:
https://issues.apache.org/jira/browse/PLC4X-8
We won't be able to build full profinet stack anytime soon but we'll
definitely be able to do data acquisition. Any help is welcome.

Kind regards,
Łukasz


On 19.04.2021 10:18, Mehta Vineet wrote:
> 
> I came across Apache PLC4x while researching for a way to read sensor data 
> over Profinet. How far along is the integration? Any idea when it will be 
> made available?
> 
> Mit freundlichen Grüßen / With best regards
> 
> Vineet Mehta
> Praktikant
> 
> ruhlamat GmbH
> Sonnenacker 2, 99834 Gerstungen OT Marksuhl
> phone:
> 
> +49 (0)36925 929-
> 
> v.me...@ruhlamat.de
> 
> fax:
> 
> +49 (0)36925 929-501
> 
> http://www.ruhlamat.de
> 
> 
> [https://www.ruhlamat.com/sites/all/themes/ruhlamat/logo1.png]
> 
> [GF/Management: Thomas Mack, Karl Mack] - [Amtsgericht Jena/Local Court Jena: 
> HRB 401145]
> [Firmensitz/Registered Office: Marksuhl] - [Ust-ID Nr.: DE 150382006]
> 
> 
> 

Re: Plc4x connection reset by peer exception uncaught

[Stefano Bossi]

Hi Vlad,

just a last advise, I have tried once to open more than one connection
to a Siemens 1200 PLC with a multithread application and I got a problem
of disconnection similat to your.
In my code the disconnection was systematic when the second thread try
to enstablish a connection.

My suggestion is to ensure that your code use just a single connection
to the PLC, in this way you should reach a more stable solution.

Regards,
S.
 

On 17/09/2020 13:01, Vladyslav Milutin wrote:
> Hi Christofer,
>
> I can't access this machine where I got this exception, that's the problem,
> I just got logs from the machine.
>
> Kind regards,
> Vlad
>
> чт, 17 сент. 2020 г. в 13:38, Christofer Dutz :
>
>> Hi Vlad,
>>
>> Your code says TCP ... so it should work, if you use WireShark on the
>> machine that is
>> trying to connect to the remote you won't even need the promiscuous mode.
>>
>>
>> Chris
>>
>>
>> Am 17.09.20, 12:26 schrieb "Vladyslav Milutin" :
>>
>> Hi Christofer,
>>
>> Thanks for your advice, I'm not sure that I can use wireshark in my
>> case :(
>> Thanks for your answers, I'll try to create a watchdog for it and look
>> for
>> the connection statuses.
>>
>> Kind regards,
>> Vlad
>>
>> чт, 17 сент. 2020 г. в 13:02, Christofer Dutz <
>> christofer.d...@c-ware.de>:
>>
>> > Hi Vlad,
>> >
>> > I didn't miss the email, but for me it's almost impossible to give
>> you an
>> > advice to what might be going wrong.
>> > The error you are getting I usually got in the past as soon as I
>> send out
>> > something the PLC doesn't like.
>> > Just recently when we didn't reset the message-id counters and they
>> > overflowed, some PLCs just hung up.
>> >
>> > So what I would do, would be to use WireShark to check what's
>> actually
>> > going over the wire and to check if this is ok.
>> > If it's not, well you know what to fix.
>> >
>> > Chris
>> >
>> >
>> > Am 17.09.20, 11:56 schrieb "Vladyslav Milutin" :
>> >
>> > Hi guys,
>> >
>> > I just will resend this message in case you missed it.
>> >
>> > Hi guys,
>> >
>> > I can send you this code, which doesn't have much business
>> logic, and
>> > all
>> > params are renamed.
>> >
>> > public abstract class LalelDriver extends
>> > GeneratedDriverBase {
>> >
>> > private final ChannelHandler handler;
>> >
>> > @Override
>> > public String getProtocolName() {
>> > return "Lalel";
>> > }
>> >
>> > @Override
>> > protected Class
>> getConfigurationType() {
>> > return LalelConfiguration.class;
>> > }
>> >
>> > @Override
>> > protected String getDefaultTransport() {
>> > return "tcp";
>> > }
>> >
>> > @Override
>> > protected boolean canSubscribe() {
>> > return true;
>> > }
>> >
>> > @Override
>> > protected LalelFieldHandler getFieldHandler() {
>> > return new LalelFieldHandler();
>> > }
>> >
>> > @Override
>> > protected void initializePipeline(ChannelFactory
>> channelFactory) {
>> > try {
>> > final Channel channel =
>> > channelFactory.createChannel(this.handler);
>> >
>>  channelFactory.initializePipeline(channel.pipeline());
>> >
>> > } catch (PlcConnectionException e) {
>> > log.error("Failed to create channel");
>> > }
>> > }
>> > }
>> >
>> > public classLalelDriverTcp extends LalelDriver {
>> >
>> > public LalelDriverTcp(final ChannelHandler handler){
>> > super(handler);
>> > }
>> >
>> > @Override
>> > public String getProtocolCode() {
>> > return "lalel-tcp";
>> > }
>> >
>> > @Override
>> > protected ProtocolStackConfigurer
>> > getStackConfigurer()
>> > {
>> > return DriverUtils.buildStackConfigurer(
>> > EthernetMessage.class, EthernetMessageIO.class,
>> > LalelProtocolLogicTcp.class,
>> ByteLengthEstimator.class
>> > );
>> > }
>> >
>> > /**
>> >  * Estimate the Length of a Packet
>> >  */
>> > public static class ByteLengthEstimator implements
>> > ToIntFunction {
>> > @Override
>> > public int applyAsInt(ByteBuf byteBuf) {
>> > if (byteBuf.readableBytes() >= 2) {
>> > return
>> > byteBuf.getUnsignedShortLE(byteBuf.readerIndex());
>> > }
>> > 

Re: Plc4x connection reset by peer exception uncaught

[Vladyslav Milutin]

Hi Christofer,

I can't access this machine where I got this exception, that's the problem,
I just got logs from the machine.

Kind regards,
Vlad

чт, 17 сент. 2020 г. в 13:38, Christofer Dutz :

> Hi Vlad,
>
> Your code says TCP ... so it should work, if you use WireShark on the
> machine that is
> trying to connect to the remote you won't even need the promiscuous mode.
>
>
> Chris
>
>
> Am 17.09.20, 12:26 schrieb "Vladyslav Milutin" :
>
> Hi Christofer,
>
> Thanks for your advice, I'm not sure that I can use wireshark in my
> case :(
> Thanks for your answers, I'll try to create a watchdog for it and look
> for
> the connection statuses.
>
> Kind regards,
> Vlad
>
> чт, 17 сент. 2020 г. в 13:02, Christofer Dutz <
> christofer.d...@c-ware.de>:
>
> > Hi Vlad,
> >
> > I didn't miss the email, but for me it's almost impossible to give
> you an
> > advice to what might be going wrong.
> > The error you are getting I usually got in the past as soon as I
> send out
> > something the PLC doesn't like.
> > Just recently when we didn't reset the message-id counters and they
> > overflowed, some PLCs just hung up.
> >
> > So what I would do, would be to use WireShark to check what's
> actually
> > going over the wire and to check if this is ok.
> > If it's not, well you know what to fix.
> >
> > Chris
> >
> >
> > Am 17.09.20, 11:56 schrieb "Vladyslav Milutin" :
> >
> > Hi guys,
> >
> > I just will resend this message in case you missed it.
> >
> > Hi guys,
> >
> > I can send you this code, which doesn't have much business
> logic, and
> > all
> > params are renamed.
> >
> > public abstract class LalelDriver extends
> > GeneratedDriverBase {
> >
> > private final ChannelHandler handler;
> >
> > @Override
> > public String getProtocolName() {
> > return "Lalel";
> > }
> >
> > @Override
> > protected Class
> getConfigurationType() {
> > return LalelConfiguration.class;
> > }
> >
> > @Override
> > protected String getDefaultTransport() {
> > return "tcp";
> > }
> >
> > @Override
> > protected boolean canSubscribe() {
> > return true;
> > }
> >
> > @Override
> > protected LalelFieldHandler getFieldHandler() {
> > return new LalelFieldHandler();
> > }
> >
> > @Override
> > protected void initializePipeline(ChannelFactory
> channelFactory) {
> > try {
> > final Channel channel =
> > channelFactory.createChannel(this.handler);
> >
>  channelFactory.initializePipeline(channel.pipeline());
> >
> > } catch (PlcConnectionException e) {
> > log.error("Failed to create channel");
> > }
> > }
> > }
> >
> > public classLalelDriverTcp extends LalelDriver {
> >
> > public LalelDriverTcp(final ChannelHandler handler){
> > super(handler);
> > }
> >
> > @Override
> > public String getProtocolCode() {
> > return "lalel-tcp";
> > }
> >
> > @Override
> > protected ProtocolStackConfigurer
> > getStackConfigurer()
> > {
> > return DriverUtils.buildStackConfigurer(
> > EthernetMessage.class, EthernetMessageIO.class,
> > LalelProtocolLogicTcp.class,
> ByteLengthEstimator.class
> > );
> > }
> >
> > /**
> >  * Estimate the Length of a Packet
> >  */
> > public static class ByteLengthEstimator implements
> > ToIntFunction {
> > @Override
> > public int applyAsInt(ByteBuf byteBuf) {
> > if (byteBuf.readableBytes() >= 2) {
> > return
> > byteBuf.getUnsignedShortLE(byteBuf.readerIndex());
> > }
> > return -1;
> > }
> > }
> >
> > }
> >
> > And connection code:
> >
> > this.connection = driver.getConnection(connectionString);
> >
> > this.connection.connect();
> >
> >
> > Kind regards,
> > Vlad
> >
> >
> > Kind regards,
> > Vlad
> >
> > чт, 17 сент. 2020 г. в 12:09, Christofer Dutz <
> > christofer.d...@c-ware.de>:
> >
> > > Hi Vlad,
> > >
> > > 0.8.0-SNAPSHOT is the current development version ...
> > > we'll be releasing that as s

Re: Plc4x connection reset by peer exception uncaught

[Christofer Dutz]

Hi Vlad,

Your code says TCP ... so it should work, if you use WireShark on the machine 
that is 
trying to connect to the remote you won't even need the promiscuous mode.


Chris


Am 17.09.20, 12:26 schrieb "Vladyslav Milutin" :

Hi Christofer,

Thanks for your advice, I'm not sure that I can use wireshark in my case :(
Thanks for your answers, I'll try to create a watchdog for it and look for
the connection statuses.

Kind regards,
Vlad

чт, 17 сент. 2020 г. в 13:02, Christofer Dutz :

> Hi Vlad,
>
> I didn't miss the email, but for me it's almost impossible to give you an
> advice to what might be going wrong.
> The error you are getting I usually got in the past as soon as I send out
> something the PLC doesn't like.
> Just recently when we didn't reset the message-id counters and they
> overflowed, some PLCs just hung up.
>
> So what I would do, would be to use WireShark to check what's actually
> going over the wire and to check if this is ok.
> If it's not, well you know what to fix.
>
> Chris
>
>
> Am 17.09.20, 11:56 schrieb "Vladyslav Milutin" :
>
> Hi guys,
>
> I just will resend this message in case you missed it.
>
> Hi guys,
>
> I can send you this code, which doesn't have much business logic, and
> all
> params are renamed.
>
> public abstract class LalelDriver extends
> GeneratedDriverBase {
>
> private final ChannelHandler handler;
>
> @Override
> public String getProtocolName() {
> return "Lalel";
> }
>
> @Override
> protected Class getConfigurationType() {
> return LalelConfiguration.class;
> }
>
> @Override
> protected String getDefaultTransport() {
> return "tcp";
> }
>
> @Override
> protected boolean canSubscribe() {
> return true;
> }
>
> @Override
> protected LalelFieldHandler getFieldHandler() {
> return new LalelFieldHandler();
> }
>
> @Override
> protected void initializePipeline(ChannelFactory channelFactory) {
> try {
> final Channel channel =
> channelFactory.createChannel(this.handler);
> channelFactory.initializePipeline(channel.pipeline());
>
> } catch (PlcConnectionException e) {
> log.error("Failed to create channel");
> }
> }
> }
>
> public classLalelDriverTcp extends LalelDriver {
>
> public LalelDriverTcp(final ChannelHandler handler){
> super(handler);
> }
>
> @Override
> public String getProtocolCode() {
> return "lalel-tcp";
> }
>
> @Override
> protected ProtocolStackConfigurer
> getStackConfigurer()
> {
> return DriverUtils.buildStackConfigurer(
> EthernetMessage.class, EthernetMessageIO.class,
> LalelProtocolLogicTcp.class, ByteLengthEstimator.class
> );
> }
>
> /**
>  * Estimate the Length of a Packet
>  */
> public static class ByteLengthEstimator implements
> ToIntFunction {
> @Override
> public int applyAsInt(ByteBuf byteBuf) {
> if (byteBuf.readableBytes() >= 2) {
> return
> byteBuf.getUnsignedShortLE(byteBuf.readerIndex());
> }
> return -1;
> }
> }
>
> }
>
> And connection code:
>
> this.connection = driver.getConnection(connectionString);
>
> this.connection.connect();
>
>
> Kind regards,
> Vlad
>
>
> Kind regards,
> Vlad
>
> чт, 17 сент. 2020 г. в 12:09, Christofer Dutz <
> christofer.d...@c-ware.de>:
>
> > Hi Vlad,
> >
> > 0.8.0-SNAPSHOT is the current development version ...
> > we'll be releasing that as soon as we tied up some things we're
> currently
> > working on.
> >
> > Chris
> >
> >
> >
> > Am 17.09.20, 11:02 schrieb "Vladyslav Milutin" :
> >
> > Hi Stefano,
> >
> > I'm curious about the 0.8.0 version, where I can find it? Since
> maven
> > repo
> > contains the latest version 0.7.0.
> >
> > Kind regards,
> > Vlad
> >
> > ср, 16 сент. 2020 г

Re: Plc4x connection reset by peer exception uncaught

[Vladyslav Milutin]

Hi Christofer,

Thanks for your advice, I'm not sure that I can use wireshark in my case :(
Thanks for your answers, I'll try to create a watchdog for it and look for
the connection statuses.

Kind regards,
Vlad

чт, 17 сент. 2020 г. в 13:02, Christofer Dutz :

> Hi Vlad,
>
> I didn't miss the email, but for me it's almost impossible to give you an
> advice to what might be going wrong.
> The error you are getting I usually got in the past as soon as I send out
> something the PLC doesn't like.
> Just recently when we didn't reset the message-id counters and they
> overflowed, some PLCs just hung up.
>
> So what I would do, would be to use WireShark to check what's actually
> going over the wire and to check if this is ok.
> If it's not, well you know what to fix.
>
> Chris
>
>
> Am 17.09.20, 11:56 schrieb "Vladyslav Milutin" :
>
> Hi guys,
>
> I just will resend this message in case you missed it.
>
> Hi guys,
>
> I can send you this code, which doesn't have much business logic, and
> all
> params are renamed.
>
> public abstract class LalelDriver extends
> GeneratedDriverBase {
>
> private final ChannelHandler handler;
>
> @Override
> public String getProtocolName() {
> return "Lalel";
> }
>
> @Override
> protected Class getConfigurationType() {
> return LalelConfiguration.class;
> }
>
> @Override
> protected String getDefaultTransport() {
> return "tcp";
> }
>
> @Override
> protected boolean canSubscribe() {
> return true;
> }
>
> @Override
> protected LalelFieldHandler getFieldHandler() {
> return new LalelFieldHandler();
> }
>
> @Override
> protected void initializePipeline(ChannelFactory channelFactory) {
> try {
> final Channel channel =
> channelFactory.createChannel(this.handler);
> channelFactory.initializePipeline(channel.pipeline());
>
> } catch (PlcConnectionException e) {
> log.error("Failed to create channel");
> }
> }
> }
>
> public classLalelDriverTcp extends LalelDriver {
>
> public LalelDriverTcp(final ChannelHandler handler){
> super(handler);
> }
>
> @Override
> public String getProtocolCode() {
> return "lalel-tcp";
> }
>
> @Override
> protected ProtocolStackConfigurer
> getStackConfigurer()
> {
> return DriverUtils.buildStackConfigurer(
> EthernetMessage.class, EthernetMessageIO.class,
> LalelProtocolLogicTcp.class, ByteLengthEstimator.class
> );
> }
>
> /**
>  * Estimate the Length of a Packet
>  */
> public static class ByteLengthEstimator implements
> ToIntFunction {
> @Override
> public int applyAsInt(ByteBuf byteBuf) {
> if (byteBuf.readableBytes() >= 2) {
> return
> byteBuf.getUnsignedShortLE(byteBuf.readerIndex());
> }
> return -1;
> }
> }
>
> }
>
> And connection code:
>
> this.connection = driver.getConnection(connectionString);
>
> this.connection.connect();
>
>
> Kind regards,
> Vlad
>
>
> Kind regards,
> Vlad
>
> чт, 17 сент. 2020 г. в 12:09, Christofer Dutz <
> christofer.d...@c-ware.de>:
>
> > Hi Vlad,
> >
> > 0.8.0-SNAPSHOT is the current development version ...
> > we'll be releasing that as soon as we tied up some things we're
> currently
> > working on.
> >
> > Chris
> >
> >
> >
> > Am 17.09.20, 11:02 schrieb "Vladyslav Milutin" :
> >
> > Hi Stefano,
> >
> > I'm curious about the 0.8.0 version, where I can find it? Since
> maven
> > repo
> > contains the latest version 0.7.0.
> >
> > Kind regards,
> > Vlad
> >
> > ср, 16 сент. 2020 г. в 17:30, Stefano Bossi <
> stefano.bo...@gmail.com>:
> >
> > > Hi Vlad,
> > >
> > > this seems similar to a bug fixed some time ago, I am not
> really
> > sure but
> > > it worth to try to use the 0.8.0 version where this fix is
> present.
> > >
> > > You should try to build the version and here you could fine
> some
> > help:
> > > https://plc4x.apache.org/developers/index.html
> > >
> > > Regards,
> > > Stefano
> > >
> > > On 16/09/2020 14:32, Vladyslav Milutin wrote:
> > >
> > > Hello guys,
> > >
> > > I'm writing to you with a hope that you can help me with
> exception
> > > handling.
> > > Currently after a long time connection can be reset by peer.
> See
> > stacktrace
> > > 

Re: Plc4x connection reset by peer exception uncaught

[Christofer Dutz]

Hi Vlad,

I didn't miss the email, but for me it's almost impossible to give you an 
advice to what might be going wrong.
The error you are getting I usually got in the past as soon as I send out 
something the PLC doesn't like.
Just recently when we didn't reset the message-id counters and they overflowed, 
some PLCs just hung up.

So what I would do, would be to use WireShark to check what's actually going 
over the wire and to check if this is ok.
If it's not, well you know what to fix.

Chris


Am 17.09.20, 11:56 schrieb "Vladyslav Milutin" :

Hi guys,

I just will resend this message in case you missed it.

Hi guys,

I can send you this code, which doesn't have much business logic, and all
params are renamed.

public abstract class LalelDriver extends
GeneratedDriverBase {

private final ChannelHandler handler;

@Override
public String getProtocolName() {
return "Lalel";
}

@Override
protected Class getConfigurationType() {
return LalelConfiguration.class;
}

@Override
protected String getDefaultTransport() {
return "tcp";
}

@Override
protected boolean canSubscribe() {
return true;
}

@Override
protected LalelFieldHandler getFieldHandler() {
return new LalelFieldHandler();
}

@Override
protected void initializePipeline(ChannelFactory channelFactory) {
try {
final Channel channel =
channelFactory.createChannel(this.handler);
channelFactory.initializePipeline(channel.pipeline());

} catch (PlcConnectionException e) {
log.error("Failed to create channel");
}
}
}

public classLalelDriverTcp extends LalelDriver {

public LalelDriverTcp(final ChannelHandler handler){
super(handler);
}

@Override
public String getProtocolCode() {
return "lalel-tcp";
}

@Override
protected ProtocolStackConfigurer getStackConfigurer()
{
return DriverUtils.buildStackConfigurer(
EthernetMessage.class, EthernetMessageIO.class,
LalelProtocolLogicTcp.class, ByteLengthEstimator.class
);
}

/**
 * Estimate the Length of a Packet
 */
public static class ByteLengthEstimator implements
ToIntFunction {
@Override
public int applyAsInt(ByteBuf byteBuf) {
if (byteBuf.readableBytes() >= 2) {
return byteBuf.getUnsignedShortLE(byteBuf.readerIndex());
}
return -1;
}
}

}

And connection code:

this.connection = driver.getConnection(connectionString);

this.connection.connect();


Kind regards,
Vlad


Kind regards,
Vlad

чт, 17 сент. 2020 г. в 12:09, Christofer Dutz :

> Hi Vlad,
>
> 0.8.0-SNAPSHOT is the current development version ...
> we'll be releasing that as soon as we tied up some things we're currently
> working on.
>
> Chris
>
>
>
> Am 17.09.20, 11:02 schrieb "Vladyslav Milutin" :
>
> Hi Stefano,
>
> I'm curious about the 0.8.0 version, where I can find it? Since maven
> repo
> contains the latest version 0.7.0.
>
> Kind regards,
> Vlad
>
> ср, 16 сент. 2020 г. в 17:30, Stefano Bossi :
>
> > Hi Vlad,
> >
> > this seems similar to a bug fixed some time ago, I am not really
> sure but
> > it worth to try to use the 0.8.0 version where this fix is present.
> >
> > You should try to build the version and here you could fine some
> help:
> > https://plc4x.apache.org/developers/index.html
> >
> > Regards,
> > Stefano
> >
> > On 16/09/2020 14:32, Vladyslav Milutin wrote:
> >
> > Hello guys,
> >
> > I'm writing to you with a hope that you can help me with exception
> > handling.
> > Currently after a long time connection can be reset by peer. See
> stacktrace
> > below.
> >
> > I've tried to add a custom ChannelHandler which Overrides
> exceptionCaught()
> > and add it in Driver#initializePipeline() see code below. Also has
> tried to
> > add a channel that can be obtained from DefaultNettyPlcConnection.
> And none
> > of them actualy was added to the pipeline where this exception was
> thrown.
> >
> > plc4x version: 0.7.0
> >
> > StatckTrace:
> > 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
> > [io.netty.channel.DefaultChannelPipeline]
> onUnhandledInboundException - An
 

Re: Plc4x connection reset by peer exception uncaught

[Vladyslav Milutin]

Hi guys,

I just will resend this message in case you missed it.

Hi guys,

I can send you this code, which doesn't have much business logic, and all
params are renamed.

public abstract class LalelDriver extends
GeneratedDriverBase {

private final ChannelHandler handler;

@Override
public String getProtocolName() {
return "Lalel";
}

@Override
protected Class getConfigurationType() {
return LalelConfiguration.class;
}

@Override
protected String getDefaultTransport() {
return "tcp";
}

@Override
protected boolean canSubscribe() {
return true;
}

@Override
protected LalelFieldHandler getFieldHandler() {
return new LalelFieldHandler();
}

@Override
protected void initializePipeline(ChannelFactory channelFactory) {
try {
final Channel channel =
channelFactory.createChannel(this.handler);
channelFactory.initializePipeline(channel.pipeline());

} catch (PlcConnectionException e) {
log.error("Failed to create channel");
}
}
}

public classLalelDriverTcp extends LalelDriver {

public LalelDriverTcp(final ChannelHandler handler){
super(handler);
}

@Override
public String getProtocolCode() {
return "lalel-tcp";
}

@Override
protected ProtocolStackConfigurer getStackConfigurer()
{
return DriverUtils.buildStackConfigurer(
EthernetMessage.class, EthernetMessageIO.class,
LalelProtocolLogicTcp.class, ByteLengthEstimator.class
);
}

/**
 * Estimate the Length of a Packet
 */
public static class ByteLengthEstimator implements
ToIntFunction {
@Override
public int applyAsInt(ByteBuf byteBuf) {
if (byteBuf.readableBytes() >= 2) {
return byteBuf.getUnsignedShortLE(byteBuf.readerIndex());
}
return -1;
}
}

}

And connection code:

this.connection = driver.getConnection(connectionString);

this.connection.connect();


Kind regards,
Vlad


Kind regards,
Vlad

чт, 17 сент. 2020 г. в 12:09, Christofer Dutz :

> Hi Vlad,
>
> 0.8.0-SNAPSHOT is the current development version ...
> we'll be releasing that as soon as we tied up some things we're currently
> working on.
>
> Chris
>
>
>
> Am 17.09.20, 11:02 schrieb "Vladyslav Milutin" :
>
> Hi Stefano,
>
> I'm curious about the 0.8.0 version, where I can find it? Since maven
> repo
> contains the latest version 0.7.0.
>
> Kind regards,
> Vlad
>
> ср, 16 сент. 2020 г. в 17:30, Stefano Bossi :
>
> > Hi Vlad,
> >
> > this seems similar to a bug fixed some time ago, I am not really
> sure but
> > it worth to try to use the 0.8.0 version where this fix is present.
> >
> > You should try to build the version and here you could fine some
> help:
> > https://plc4x.apache.org/developers/index.html
> >
> > Regards,
> > Stefano
> >
> > On 16/09/2020 14:32, Vladyslav Milutin wrote:
> >
> > Hello guys,
> >
> > I'm writing to you with a hope that you can help me with exception
> > handling.
> > Currently after a long time connection can be reset by peer. See
> stacktrace
> > below.
> >
> > I've tried to add a custom ChannelHandler which Overrides
> exceptionCaught()
> > and add it in Driver#initializePipeline() see code below. Also has
> tried to
> > add a channel that can be obtained from DefaultNettyPlcConnection.
> And none
> > of them actualy was added to the pipeline where this exception was
> thrown.
> >
> > plc4x version: 0.7.0
> >
> > StatckTrace:
> > 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
> > [io.netty.channel.DefaultChannelPipeline]
> onUnhandledInboundException - An
> > exceptionCaught() event was fired, and it reached at the tail of the
> > pipeline. It usually means the last handler in the pipeline did not
> handle
> > the exception.
> > java.io.IOException: Connection reset by peer
> >   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> >   at java.base/sun.nio.ch
> .SocketDispatcher.read(SocketDispatcher.java:39)
> >   at
> java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
> >   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
> >   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
> >   at java.base/sun.nio.ch
> .SocketChannelImpl.read(SocketChannelImpl.java:358)
> >   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
> >   at
> io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
> >   at
> >
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
> >   at
> >
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
> >   at
> >
> io.n

Re: Plc4x connection reset by peer exception uncaught

[Christofer Dutz]

Hi Vlad,

0.8.0-SNAPSHOT is the current development version ... 
we'll be releasing that as soon as we tied up some things we're currently 
working on.

Chris



Am 17.09.20, 11:02 schrieb "Vladyslav Milutin" :

Hi Stefano,

I'm curious about the 0.8.0 version, where I can find it? Since maven repo
contains the latest version 0.7.0.

Kind regards,
Vlad

ср, 16 сент. 2020 г. в 17:30, Stefano Bossi :

> Hi Vlad,
>
> this seems similar to a bug fixed some time ago, I am not really sure but
> it worth to try to use the 0.8.0 version where this fix is present.
>
> You should try to build the version and here you could fine some help:
> https://plc4x.apache.org/developers/index.html
>
> Regards,
> Stefano
>
> On 16/09/2020 14:32, Vladyslav Milutin wrote:
>
> Hello guys,
>
> I'm writing to you with a hope that you can help me with exception
> handling.
> Currently after a long time connection can be reset by peer. See 
stacktrace
> below.
>
> I've tried to add a custom ChannelHandler which Overrides 
exceptionCaught()
> and add it in Driver#initializePipeline() see code below. Also has tried 
to
> add a channel that can be obtained from DefaultNettyPlcConnection. And 
none
> of them actualy was added to the pipeline where this exception was thrown.
>
> plc4x version: 0.7.0
>
> StatckTrace:
> 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
> [io.netty.channel.DefaultChannelPipeline] onUnhandledInboundException - An
> exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> java.io.IOException: Connection reset by peer
>   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
>   at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
>   at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
>   at 
java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:358)
>   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
>   at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
>   at
> 
io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
>   at
> 
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
>   at
> 
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
>   at
> 
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
>   at
> 
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>   at
> 
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>   at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>   at
> 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:834)
>
> Driver#initializePipeline:
> try {
> final Channel channel =
> channelFactory.createChannel(this.handler);
> channelFactory.initializePipeline(channel.pipeline());
>
> } catch (PlcConnectionException e) {
> log.error("Failed to create channel");
> }
>
> ChannelHandler:
> @Override
> public void exceptionCaught(ChannelHandlerContext ctx, Throwable 
cause)
> {
> log.warn("ExceptionCaught in worker: ctx = [{}], cause = [{}, {}],
> workerName = [{}]",
> ctx, cause.getClass(), cause.getMessage(), workerName);
> if (cause instanceof ConnectTimeoutException) {
> log.warn("ConnectionTimeout caught: workerName = [{}]",
> workerName);
> }
> if ((cause instanceof IOException) &&
> cause.getMessage().contains("Connection reset by peer")) {
> log.warn("Connection reset by peer caught: workerName = [{}]",
> workerName);
> } else {
> log.info("Unexpected exception caught: workerName = [{}]",
> workerName);
> }
>
> this.callback.accept(cause);
> }
>
> DefaultNettyPlcConnection#channel:log.info("Trying to get connection 
channel: worker name = [{}]",
> this.workerName);
> final Channel channel = ((DefaultNettyPlcConnection)
> this.connection).getChannel();
> log.info("Channel obtained successfully. Adding custom
> channelHandler to it: channel = [{}], workerName = [{}]", channel,
> t

Re: Plc4x connection reset by peer exception uncaught

[Vladyslav Milutin]

Hi Stefano,

I'm curious about the 0.8.0 version, where I can find it? Since maven repo
contains the latest version 0.7.0.

Kind regards,
Vlad

ср, 16 сент. 2020 г. в 17:30, Stefano Bossi :

> Hi Vlad,
>
> this seems similar to a bug fixed some time ago, I am not really sure but
> it worth to try to use the 0.8.0 version where this fix is present.
>
> You should try to build the version and here you could fine some help:
> https://plc4x.apache.org/developers/index.html
>
> Regards,
> Stefano
>
> On 16/09/2020 14:32, Vladyslav Milutin wrote:
>
> Hello guys,
>
> I'm writing to you with a hope that you can help me with exception
> handling.
> Currently after a long time connection can be reset by peer. See stacktrace
> below.
>
> I've tried to add a custom ChannelHandler which Overrides exceptionCaught()
> and add it in Driver#initializePipeline() see code below. Also has tried to
> add a channel that can be obtained from DefaultNettyPlcConnection. And none
> of them actualy was added to the pipeline where this exception was thrown.
>
> plc4x version: 0.7.0
>
> StatckTrace:
> 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
> [io.netty.channel.DefaultChannelPipeline] onUnhandledInboundException - An
> exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> java.io.IOException: Connection reset by peer
>   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
>   at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
>   at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
>   at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:358)
>   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
>   at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
>   at
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
>   at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
>   at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
>   at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
>   at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>   at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>   at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>   at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:834)
>
> Driver#initializePipeline:
> try {
> final Channel channel =
> channelFactory.createChannel(this.handler);
> channelFactory.initializePipeline(channel.pipeline());
>
> } catch (PlcConnectionException e) {
> log.error("Failed to create channel");
> }
>
> ChannelHandler:
> @Override
> public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause)
> {
> log.warn("ExceptionCaught in worker: ctx = [{}], cause = [{}, {}],
> workerName = [{}]",
> ctx, cause.getClass(), cause.getMessage(), workerName);
> if (cause instanceof ConnectTimeoutException) {
> log.warn("ConnectionTimeout caught: workerName = [{}]",
> workerName);
> }
> if ((cause instanceof IOException) &&
> cause.getMessage().contains("Connection reset by peer")) {
> log.warn("Connection reset by peer caught: workerName = [{}]",
> workerName);
> } else {
> log.info("Unexpected exception caught: workerName = [{}]",
> workerName);
> }
>
> this.callback.accept(cause);
> }
>
> DefaultNettyPlcConnection#channel:log.info("Trying to get connection channel: 
> worker name = [{}]",
> this.workerName);
> final Channel channel = ((DefaultNettyPlcConnection)
> this.connection).getChannel();
> log.info("Channel obtained successfully. Adding custom
> channelHandler to it: channel = [{}], workerName = [{}]", channel,
> this.workerName);
> channel.pipeline().addLast(this.channelHandler);
> log.info("ChannelHandler added: channel = [{}], channelHandler =
> [{}], workerName = [{}]", channel, this.channelHandler, this.workerName);
>
> Kind regards,
> Vlad
>
>
>
>

Re: Plc4x connection reset by peer exception uncaught

[Vladyslav Milutin]

Hi guys,

I can send you this code, which doesn't have much business logic, and all
params are renamed.

public abstract class LalelDriver extends
GeneratedDriverBase {

private final ChannelHandler handler;

@Override
public String getProtocolName() {
return "Lalel";
}

@Override
protected Class getConfigurationType() {
return LalelConfiguration.class;
}

@Override
protected String getDefaultTransport() {
return "tcp";
}

@Override
protected boolean canSubscribe() {
return true;
}

@Override
protected LalelFieldHandler getFieldHandler() {
return new LalelFieldHandler();
}

@Override
protected void initializePipeline(ChannelFactory channelFactory) {
try {
final Channel channel =
channelFactory.createChannel(this.handler);
channelFactory.initializePipeline(channel.pipeline());

} catch (PlcConnectionException e) {
log.error("Failed to create channel");
}
}
}

public classLalelDriverTcp extends LalelDriver {

public LalelDriverTcp(final ChannelHandler handler){
super(handler);
}

@Override
public String getProtocolCode() {
return "lalel-tcp";
}

@Override
protected ProtocolStackConfigurer getStackConfigurer()
{
return DriverUtils.buildStackConfigurer(
EthernetMessage.class, EthernetMessageIO.class,
LalelProtocolLogicTcp.class, ByteLengthEstimator.class
);
}

/**
 * Estimate the Length of a Packet
 */
public static class ByteLengthEstimator implements
ToIntFunction {
@Override
public int applyAsInt(ByteBuf byteBuf) {
if (byteBuf.readableBytes() >= 2) {
return byteBuf.getUnsignedShortLE(byteBuf.readerIndex());
}
return -1;
}
}

}

And connection code:

this.connection = driver.getConnection(connectionString);

this.connection.connect();


Kind regards,
Vlad

ср, 16 сент. 2020 г. в 22:01, Łukasz Dywicki :

> I can't say more than others, but based on my own experiences I can tell
> you that some exceptions are swallowed by Netty or surrounding classes
> resulting in dead connections.
> When I was working on socketcan transport its initialization failures lead
> to connections which were allowing writes but never actually emitted
> anything to the wire.
>
> Based on stack trace - are you using TCP? Is connection initialized
> properly? Some devices could refuse more than one connection at the time.
> Also as far I know generated drivers must register message kinds to be
> initialized properly. Netty pipeline is then configured with plc4x codec
> handler.
>
> Best,
> Łukasz
>
> śr., 16 wrz 2020 o 18:23 Vladyslav Milutin 
> napisał(a):
>
> > Hi Stefano,
> >
> > Driver designed for custom IoT devices, driver itself just overrides
> > abstract methods like protocol(), canWrite(), canRead(),
> > getConfiguration().  It's not doing any logic.
> >
> > I think PooledDriverManager can help, but will it check the connection
> > itself, not just when the getConnection() method is called?
> >
> >
> > On 16 Sep 2020, at 19:07, Stefano Bossi  wrote:
> >
> >  Hi Vladyslav,
> >
> > just because a I am a curious guy, why did you choose to build a custom
> > driver?
> >
> > Do you need something special ?
> >
> > Regards,
> > Stefano
> >
> > P.S. feel free to answer: it's not your business  As said is just a
> > curiosity, anyone has the right to choose it's road.
> >
> >
> >
> > On 16/09/2020 17:54, Christofer Dutz wrote:
> >
> > Hi Vladyslav,
> >
> > oh ... a custom driver. In that case it will definitely be tricky to
> > help you unless we can have a look at the code.
> >
> > Is this something you consider bringing into the PLC4X project, or
> > something that's meant to stay outside of the project?
> >
> > I guess this is the first time such a question has come up ;-)
> >
> > With integrations, I was referring to: Camel, Kafka, Edgent, NiFi, ...
> > integrations that the PLC4X provides. But I guess you answered the
> > question and you're not using any of them.
> >
> > The connection pool does a little more. Before returning a connection
> > it checks if it's still alive and if it's not, it creates a new one.
> >
> > Chris
> >
> >
> >
> > Am 16.09.20, 17:39 schrieb "Vladyslav Milutin" 
> > :
> >
> > Hi Christofer,
> >
> > Thanks for your quick response.
> > I'm using a custom driver which extends GeneratedDriverBase, for
> > connection
> > I use a simple call to .connect, I know that you have
> > PooledDriverManager,
> > but it won't have the same issue if connection was reset by peer,
> since
> > it's just look up for the specific connection?
> > As
> > integrations: plc4j-transport-tcp, plc4j-api, plc4j-spi,
> > plc4j-connection-pool
> > and other code generation and build utils. Or by integration you mean

Re: Plc4x connection reset by peer exception uncaught

[Łukasz Dywicki]

I can't say more than others, but based on my own experiences I can tell
you that some exceptions are swallowed by Netty or surrounding classes
resulting in dead connections.
When I was working on socketcan transport its initialization failures lead
to connections which were allowing writes but never actually emitted
anything to the wire.

Based on stack trace - are you using TCP? Is connection initialized
properly? Some devices could refuse more than one connection at the time.
Also as far I know generated drivers must register message kinds to be
initialized properly. Netty pipeline is then configured with plc4x codec
handler.

Best,
Łukasz

śr., 16 wrz 2020 o 18:23 Vladyslav Milutin  napisał(a):

> Hi Stefano,
>
> Driver designed for custom IoT devices, driver itself just overrides
> abstract methods like protocol(), canWrite(), canRead(),
> getConfiguration().  It's not doing any logic.
>
> I think PooledDriverManager can help, but will it check the connection
> itself, not just when the getConnection() method is called?
>
>
> On 16 Sep 2020, at 19:07, Stefano Bossi  wrote:
>
>  Hi Vladyslav,
>
> just because a I am a curious guy, why did you choose to build a custom
> driver?
>
> Do you need something special ?
>
> Regards,
> Stefano
>
> P.S. feel free to answer: it's not your business  As said is just a
> curiosity, anyone has the right to choose it's road.
>
>
>
> On 16/09/2020 17:54, Christofer Dutz wrote:
>
> Hi Vladyslav,
>
> oh ... a custom driver. In that case it will definitely be tricky to
> help you unless we can have a look at the code.
>
> Is this something you consider bringing into the PLC4X project, or
> something that's meant to stay outside of the project?
>
> I guess this is the first time such a question has come up ;-)
>
> With integrations, I was referring to: Camel, Kafka, Edgent, NiFi, ...
> integrations that the PLC4X provides. But I guess you answered the
> question and you're not using any of them.
>
> The connection pool does a little more. Before returning a connection
> it checks if it's still alive and if it's not, it creates a new one.
>
> Chris
>
>
>
> Am 16.09.20, 17:39 schrieb "Vladyslav Milutin" 
> :
>
> Hi Christofer,
>
> Thanks for your quick response.
> I'm using a custom driver which extends GeneratedDriverBase, for
> connection
> I use a simple call to .connect, I know that you have
> PooledDriverManager,
> but it won't have the same issue if connection was reset by peer, since
> it's just look up for the specific connection?
> As
> integrations: plc4j-transport-tcp, plc4j-api, plc4j-spi,
> plc4j-connection-pool
> and other code generation and build utils. Or by integration you mean
> frameworks? If yes, Spring Frameworks.
>
> Kind regards,
> Vlad
>
> ср, 16 сент. 2020 г. в 17:28, Christofer Dutz
>  :
>
> > Hi Vladyslav,
> >
> > could you please tell us which driver and which version you are
> using?
> > Also it would be interesting if you are using any integration
> modules?
> >
> > Chris
> >
> > Am 16.09.20, 14:36 schrieb "Vladyslav Milutin"
>  :
> >
> > Hello guys,
> >
> > I'm writing to you with a hope that you can help me with
> exception
> > handling.
> > Currently after a long time connection can be reset by peer. See
> > stacktrace
> > below.
> >
> > I've tried to add a custom ChannelHandler which Overrides
> > exceptionCaught()
> > and add it in Driver#initializePipeline() see code below. Also
> has
> > tried to
> > add a channel that can be obtained from
> DefaultNettyPlcConnection. And
> > none
> > of them actualy was added to the pipeline where this exception
> was
> > thrown.
> >
> > plc4x version: 0.7.0
> >
> > StatckTrace:
> > 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
> > [io.netty.channel.DefaultChannelPipeline]
> onUnhandledInboundException
> > - An
> > exceptionCaught() event was fired, and it reached at the tail of
> the
> > pipeline. It usually means the last handler in the pipeline did
> not
> > handle
> > the exception.
> > java.io.IOException: Connection reset by peer
> >   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native
> Method)
> >   at java.base/sun.nio.ch
> > .SocketDispatcher.read(SocketDispatcher.java:39)
> >   at
> java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
> >   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
> >   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
> >   at java.base/sun.nio.ch
> > .SocketChannelImpl.read(SocketChannelImpl.java:358)
> >   at
> io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
> >   at
> > io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
> >   at
> >
> >
>

Re: Plc4x connection reset by peer exception uncaught

[Vladyslav Milutin]

Hi Stefano,

Driver designed for custom IoT devices, driver itself just overrides
abstract methods like protocol(), canWrite(), canRead(),
getConfiguration().  It's not doing any logic.

I think PooledDriverManager can help, but will it check the connection
itself, not just when the getConnection() method is called?


On 16 Sep 2020, at 19:07, Stefano Bossi  wrote:

 Hi Vladyslav,

just because a I am a curious guy, why did you choose to build a custom
driver?

Do you need something special ?

Regards,
Stefano

P.S. feel free to answer: it's not your business  As said is just a
curiosity, anyone has the right to choose it's road.



On 16/09/2020 17:54, Christofer Dutz wrote:

Hi Vladyslav,

oh ... a custom driver. In that case it will definitely be tricky to
help you unless we can have a look at the code.

Is this something you consider bringing into the PLC4X project, or
something that's meant to stay outside of the project?

I guess this is the first time such a question has come up ;-)

With integrations, I was referring to: Camel, Kafka, Edgent, NiFi, ...
integrations that the PLC4X provides. But I guess you answered the
question and you're not using any of them.

The connection pool does a little more. Before returning a connection
it checks if it's still alive and if it's not, it creates a new one.

Chris



Am 16.09.20, 17:39 schrieb "Vladyslav Milutin" 
:

Hi Christofer,

Thanks for your quick response.
I'm using a custom driver which extends GeneratedDriverBase, for connection
I use a simple call to .connect, I know that you have PooledDriverManager,
but it won't have the same issue if connection was reset by peer, since
it's just look up for the specific connection?
As
integrations: plc4j-transport-tcp, plc4j-api, plc4j-spi,
plc4j-connection-pool
and other code generation and build utils. Or by integration you mean
frameworks? If yes, Spring Frameworks.

Kind regards,
Vlad

ср, 16 сент. 2020 г. в 17:28, Christofer Dutz
 :

> Hi Vladyslav,
>
> could you please tell us which driver and which version you are using?
> Also it would be interesting if you are using any integration modules?
>
> Chris
>
> Am 16.09.20, 14:36 schrieb "Vladyslav Milutin"
 :
>
> Hello guys,
>
> I'm writing to you with a hope that you can help me with exception
> handling.
> Currently after a long time connection can be reset by peer. See
> stacktrace
> below.
>
> I've tried to add a custom ChannelHandler which Overrides
> exceptionCaught()
> and add it in Driver#initializePipeline() see code below. Also has
> tried to
> add a channel that can be obtained from DefaultNettyPlcConnection. And
> none
> of them actualy was added to the pipeline where this exception was
> thrown.
>
> plc4x version: 0.7.0
>
> StatckTrace:
> 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
> [io.netty.channel.DefaultChannelPipeline] onUnhandledInboundException
> - An
> exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not
> handle
> the exception.
> java.io.IOException: Connection reset by peer
>   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
>   at java.base/sun.nio.ch
> .SocketDispatcher.read(SocketDispatcher.java:39)
>   at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
>   at java.base/sun.nio.ch
> .SocketChannelImpl.read(SocketChannelImpl.java:358)
>   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
>   at
> io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
>   at
>
> 
io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
>   at
>
> 
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
>   at
>
> 
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
>   at
>
> 
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
>   at
>
> 
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>   at
>
> 
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>   at
>
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>   at
>
> 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at 

Re: Plc4x connection reset by peer exception uncaught

[Stefano Bossi]

Hi Vladyslav,

just because a I am a curious guy, why did you choose to build a custom
driver?

Do you need something special ?

Regards,
Stefano

P.S. feel free to answer: it's not your business  As said is just a
curiosity, anyone has the right to choose it's road.



On 16/09/2020 17:54, Christofer Dutz wrote:
> Hi Vladyslav,
>
> oh ... a custom driver. In that case it will definitely be tricky to help you 
> unless we can have a look at the code.
>
> Is this something you consider bringing into the PLC4X project, or something 
> that's meant to stay outside of the project?
>
> I guess this is the first time such a question has come up ;-)
>
> With integrations, I was referring to: Camel, Kafka, Edgent, NiFi, ... 
> integrations that the PLC4X provides. But I guess you answered the question 
> and you're not using any of them.
>
> The connection pool does a little more. Before returning a connection it 
> checks if it's still alive and if it's not, it creates a new one. 
>
> Chris
>
>
>
> Am 16.09.20, 17:39 schrieb "Vladyslav Milutin" :
>
> Hi Christofer,
>
> Thanks for your quick response.
> I'm using a custom driver which extends GeneratedDriverBase, for 
> connection
> I use a simple call to .connect, I know that you have PooledDriverManager,
> but it won't have the same issue if connection was reset by peer, since
> it's just look up for the specific connection?
> As
> integrations: plc4j-transport-tcp, plc4j-api, plc4j-spi, 
> plc4j-connection-pool
> and other code generation and build utils. Or by integration you mean
> frameworks? If yes, Spring Frameworks.
>
> Kind regards,
> Vlad
>
> ср, 16 сент. 2020 г. в 17:28, Christofer Dutz :
>
> > Hi Vladyslav,
> >
> > could you please tell us which driver and which version you are using?
> > Also it would be interesting if you are using any integration modules?
> >
> > Chris
> >
> > Am 16.09.20, 14:36 schrieb "Vladyslav Milutin" :
> >
> > Hello guys,
> >
> > I'm writing to you with a hope that you can help me with exception
> > handling.
> > Currently after a long time connection can be reset by peer. See
> > stacktrace
> > below.
> >
> > I've tried to add a custom ChannelHandler which Overrides
> > exceptionCaught()
> > and add it in Driver#initializePipeline() see code below. Also has
> > tried to
> > add a channel that can be obtained from DefaultNettyPlcConnection. 
> And
> > none
> > of them actualy was added to the pipeline where this exception was
> > thrown.
> >
> > plc4x version: 0.7.0
> >
> > StatckTrace:
> > 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
> > [io.netty.channel.DefaultChannelPipeline] 
> onUnhandledInboundException
> > - An
> > exceptionCaught() event was fired, and it reached at the tail of the
> > pipeline. It usually means the last handler in the pipeline did not
> > handle
> > the exception.
> > java.io.IOException: Connection reset by peer
> >   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> >   at java.base/sun.nio.ch
> > .SocketDispatcher.read(SocketDispatcher.java:39)
> >   at 
> java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
> >   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
> >   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
> >   at java.base/sun.nio.ch
> > .SocketChannelImpl.read(SocketChannelImpl.java:358)
> >   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
> >   at
> > io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
> >   at
> >
> > 
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
> >   at
> >
> > 
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
> >   at
> >
> > 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
> >   at
> >
> > 
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
> >   at
> >
> > 
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
> >   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
> >   at
> >
> > 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> >   at
> >
> > 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> >   at
> >
> > 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> >   at java.base/java.lang.Thread.run(Thread.java:834)
> >
> > Driver#initializePipeline:
> > try {
> 

Re: Plc4x connection reset by peer exception uncaught

[Christofer Dutz]

Hi Vladyslav,

oh ... a custom driver. In that case it will definitely be tricky to help you 
unless we can have a look at the code.

Is this something you consider bringing into the PLC4X project, or something 
that's meant to stay outside of the project?

I guess this is the first time such a question has come up ;-)

With integrations, I was referring to: Camel, Kafka, Edgent, NiFi, ... 
integrations that the PLC4X provides. But I guess you answered the question and 
you're not using any of them.

The connection pool does a little more. Before returning a connection it checks 
if it's still alive and if it's not, it creates a new one. 

Chris



Am 16.09.20, 17:39 schrieb "Vladyslav Milutin" :

Hi Christofer,

Thanks for your quick response.
I'm using a custom driver which extends GeneratedDriverBase, for connection
I use a simple call to .connect, I know that you have PooledDriverManager,
but it won't have the same issue if connection was reset by peer, since
it's just look up for the specific connection?
As
integrations: plc4j-transport-tcp, plc4j-api, plc4j-spi, 
plc4j-connection-pool
and other code generation and build utils. Or by integration you mean
frameworks? If yes, Spring Frameworks.

Kind regards,
Vlad

ср, 16 сент. 2020 г. в 17:28, Christofer Dutz :

> Hi Vladyslav,
>
> could you please tell us which driver and which version you are using?
> Also it would be interesting if you are using any integration modules?
>
> Chris
>
> Am 16.09.20, 14:36 schrieb "Vladyslav Milutin" :
>
> Hello guys,
>
> I'm writing to you with a hope that you can help me with exception
> handling.
> Currently after a long time connection can be reset by peer. See
> stacktrace
> below.
>
> I've tried to add a custom ChannelHandler which Overrides
> exceptionCaught()
> and add it in Driver#initializePipeline() see code below. Also has
> tried to
> add a channel that can be obtained from DefaultNettyPlcConnection. And
> none
> of them actualy was added to the pipeline where this exception was
> thrown.
>
> plc4x version: 0.7.0
>
> StatckTrace:
> 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
> [io.netty.channel.DefaultChannelPipeline] onUnhandledInboundException
> - An
> exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not
> handle
> the exception.
> java.io.IOException: Connection reset by peer
>   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
>   at java.base/sun.nio.ch
> .SocketDispatcher.read(SocketDispatcher.java:39)
>   at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
>   at java.base/sun.nio.ch
> .SocketChannelImpl.read(SocketChannelImpl.java:358)
>   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
>   at
> io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
>   at
>
> 
io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
>   at
>
> 
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
>   at
>
> 
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
>   at
>
> 
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
>   at
>
> 
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>   at
>
> 
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>   at
>
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>   at
>
> 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:834)
>
> Driver#initializePipeline:
> try {
> final Channel channel =
> channelFactory.createChannel(this.handler);
> channelFactory.initializePipeline(channel.pipeline());
>
> } catch (PlcConnectionException e) {
> log.error("Failed to create channel");
> }
>
> ChannelHandler:
> @Override
> public void exceptionCaught(ChannelHandlerContext ctx, Throwable
> cause)
> {
> log.warn("ExceptionCaught in worker: ctx = [{}], cause = [{},
> {}],
  

Re: Plc4x connection reset by peer exception uncaught

[Vladyslav Milutin]

Hi Christofer,

Thanks for your quick response.
I'm using a custom driver which extends GeneratedDriverBase, for connection
I use a simple call to .connect, I know that you have PooledDriverManager,
but it won't have the same issue if connection was reset by peer, since
it's just look up for the specific connection?
As
integrations: plc4j-transport-tcp, plc4j-api, plc4j-spi, plc4j-connection-pool
and other code generation and build utils. Or by integration you mean
frameworks? If yes, Spring Frameworks.

Kind regards,
Vlad

ср, 16 сент. 2020 г. в 17:28, Christofer Dutz :

> Hi Vladyslav,
>
> could you please tell us which driver and which version you are using?
> Also it would be interesting if you are using any integration modules?
>
> Chris
>
> Am 16.09.20, 14:36 schrieb "Vladyslav Milutin" :
>
> Hello guys,
>
> I'm writing to you with a hope that you can help me with exception
> handling.
> Currently after a long time connection can be reset by peer. See
> stacktrace
> below.
>
> I've tried to add a custom ChannelHandler which Overrides
> exceptionCaught()
> and add it in Driver#initializePipeline() see code below. Also has
> tried to
> add a channel that can be obtained from DefaultNettyPlcConnection. And
> none
> of them actualy was added to the pipeline where this exception was
> thrown.
>
> plc4x version: 0.7.0
>
> StatckTrace:
> 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
> [io.netty.channel.DefaultChannelPipeline] onUnhandledInboundException
> - An
> exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not
> handle
> the exception.
> java.io.IOException: Connection reset by peer
>   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
>   at java.base/sun.nio.ch
> .SocketDispatcher.read(SocketDispatcher.java:39)
>   at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
>   at java.base/sun.nio.ch
> .SocketChannelImpl.read(SocketChannelImpl.java:358)
>   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
>   at
> io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
>   at
>
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
>   at
>
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
>   at
>
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
>   at
>
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
>   at
>
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>   at
>
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>   at
>
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>   at
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:834)
>
> Driver#initializePipeline:
> try {
> final Channel channel =
> channelFactory.createChannel(this.handler);
> channelFactory.initializePipeline(channel.pipeline());
>
> } catch (PlcConnectionException e) {
> log.error("Failed to create channel");
> }
>
> ChannelHandler:
> @Override
> public void exceptionCaught(ChannelHandlerContext ctx, Throwable
> cause)
> {
> log.warn("ExceptionCaught in worker: ctx = [{}], cause = [{},
> {}],
> workerName = [{}]",
> ctx, cause.getClass(), cause.getMessage(), workerName);
> if (cause instanceof ConnectTimeoutException) {
> log.warn("ConnectionTimeout caught: workerName = [{}]",
> workerName);
> }
> if ((cause instanceof IOException) &&
> cause.getMessage().contains("Connection reset by peer")) {
> log.warn("Connection reset by peer caught: workerName =
> [{}]",
> workerName);
> } else {
> log.info("Unexpected exception caught: workerName = [{}]",
> workerName);
> }
>
> this.callback.accept(cause);
> }
>
> DefaultNettyPlcConnection#channel:
> log.info("Trying to get connection channel: worker name = [{}]",
> this.workerName);
> final Channel channel = ((DefaultNettyPlcConnection)
> this.connection).getChannel();
> log.info("Channel obtained successfully. Adding custom
> channelHandler to it: channel = [{}], workerName = [{}]", channel,
> this.workerName);
> channel.pipeline().addLast(th

Re: Plc4x connection reset by peer exception uncaught

[Stefano Bossi]

Hi,

an another suggestion is to give a try to the pooled drive manager
instead of the simple dirve manager, here you could fine some more info:
https://plc4x.apache.org/users/tools/connection-pool.html

Regards,
Stefano


On 16/09/2020 16:30, Stefano Bossi wrote:
> Hi Vlad,
>
> this seems similar to a bug fixed some time ago, I am not really sure
> but it worth to try to use the 0.8.0 version where this fix is present.
>
> You should try to build the version and here you could fine some help:
> https://plc4x.apache.org/developers/index.html
>
> Regards,
> Stefano
>
> On 16/09/2020 14:32, Vladyslav Milutin wrote:
>> Hello guys,
>>
>> I'm writing to you with a hope that you can help me with exception
>> handling.
>> Currently after a long time connection can be reset by peer. See stacktrace
>> below.
>>
>> I've tried to add a custom ChannelHandler which Overrides exceptionCaught()
>> and add it in Driver#initializePipeline() see code below. Also has tried to
>> add a channel that can be obtained from DefaultNettyPlcConnection. And none
>> of them actualy was added to the pipeline where this exception was thrown.
>>
>> plc4x version: 0.7.0
>>
>> StatckTrace:
>> 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
>> [io.netty.channel.DefaultChannelPipeline] onUnhandledInboundException - An
>> exceptionCaught() event was fired, and it reached at the tail of the
>> pipeline. It usually means the last handler in the pipeline did not handle
>> the exception.
>> java.io.IOException: Connection reset by peer
>>   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
>>   at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
>>   at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
>>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
>>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
>>   at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:358)
>>   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
>>   at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
>>   at
>> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
>>   at
>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
>>   at
>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
>>   at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
>>   at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
>>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>>   at
>> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>>   at
>> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>>   at
>> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>>   at java.base/java.lang.Thread.run(Thread.java:834)
>>
>> Driver#initializePipeline:
>> try {
>> final Channel channel =
>> channelFactory.createChannel(this.handler);
>> channelFactory.initializePipeline(channel.pipeline());
>>
>> } catch (PlcConnectionException e) {
>> log.error("Failed to create channel");
>> }
>>
>> ChannelHandler:
>> @Override
>> public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause)
>> {
>> log.warn("ExceptionCaught in worker: ctx = [{}], cause = [{}, {}],
>> workerName = [{}]",
>> ctx, cause.getClass(), cause.getMessage(), workerName);
>> if (cause instanceof ConnectTimeoutException) {
>> log.warn("ConnectionTimeout caught: workerName = [{}]",
>> workerName);
>> }
>> if ((cause instanceof IOException) &&
>> cause.getMessage().contains("Connection reset by peer")) {
>> log.warn("Connection reset by peer caught: workerName = [{}]",
>> workerName);
>> } else {
>> log.info("Unexpected exception caught: workerName = [{}]",
>> workerName);
>> }
>>
>> this.callback.accept(cause);
>> }
>>
>> DefaultNettyPlcConnection#channel:
>> log.info("Trying to get connection channel: worker name = [{}]",
>> this.workerName);
>> final Channel channel = ((DefaultNettyPlcConnection)
>> this.connection).getChannel();
>> log.info("Channel obtained successfully. Adding custom
>> channelHandler to it: channel = [{}], workerName = [{}]", channel,
>> this.workerName);
>> channel.pipeline().addLast(this.channelHandler);
>> log.info("ChannelHandler added: channel = [{}], channelHandler =
>> [{}], workerName = [{}]", channel, this.channelHandler, this.workerName);
>>
>> Kind regards,
>> Vlad
>>
>



signature.asc
Description: OpenPGP digital signature

Re: Plc4x connection reset by peer exception uncaught

[Stefano Bossi]

Hi Vlad,

this seems similar to a bug fixed some time ago, I am not really sure
but it worth to try to use the 0.8.0 version where this fix is present.

You should try to build the version and here you could fine some help:
https://plc4x.apache.org/developers/index.html

Regards,
Stefano

On 16/09/2020 14:32, Vladyslav Milutin wrote:
> Hello guys,
>
> I'm writing to you with a hope that you can help me with exception
> handling.
> Currently after a long time connection can be reset by peer. See stacktrace
> below.
>
> I've tried to add a custom ChannelHandler which Overrides exceptionCaught()
> and add it in Driver#initializePipeline() see code below. Also has tried to
> add a channel that can be obtained from DefaultNettyPlcConnection. And none
> of them actualy was added to the pipeline where this exception was thrown.
>
> plc4x version: 0.7.0
>
> StatckTrace:
> 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
> [io.netty.channel.DefaultChannelPipeline] onUnhandledInboundException - An
> exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> java.io.IOException: Connection reset by peer
>   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
>   at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
>   at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
>   at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:358)
>   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
>   at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
>   at
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
>   at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
>   at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
>   at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
>   at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>   at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>   at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>   at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:834)
>
> Driver#initializePipeline:
> try {
> final Channel channel =
> channelFactory.createChannel(this.handler);
> channelFactory.initializePipeline(channel.pipeline());
>
> } catch (PlcConnectionException e) {
> log.error("Failed to create channel");
> }
>
> ChannelHandler:
> @Override
> public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause)
> {
> log.warn("ExceptionCaught in worker: ctx = [{}], cause = [{}, {}],
> workerName = [{}]",
> ctx, cause.getClass(), cause.getMessage(), workerName);
> if (cause instanceof ConnectTimeoutException) {
> log.warn("ConnectionTimeout caught: workerName = [{}]",
> workerName);
> }
> if ((cause instanceof IOException) &&
> cause.getMessage().contains("Connection reset by peer")) {
> log.warn("Connection reset by peer caught: workerName = [{}]",
> workerName);
> } else {
> log.info("Unexpected exception caught: workerName = [{}]",
> workerName);
> }
>
> this.callback.accept(cause);
> }
>
> DefaultNettyPlcConnection#channel:
> log.info("Trying to get connection channel: worker name = [{}]",
> this.workerName);
> final Channel channel = ((DefaultNettyPlcConnection)
> this.connection).getChannel();
> log.info("Channel obtained successfully. Adding custom
> channelHandler to it: channel = [{}], workerName = [{}]", channel,
> this.workerName);
> channel.pipeline().addLast(this.channelHandler);
> log.info("ChannelHandler added: channel = [{}], channelHandler =
> [{}], workerName = [{}]", channel, this.channelHandler, this.workerName);
>
> Kind regards,
> Vlad
>



signature.asc
Description: OpenPGP digital signature

Re: Plc4x connection reset by peer exception uncaught

[Christofer Dutz]

Hi Vladyslav,

could you please tell us which driver and which version you are using? Also it 
would be interesting if you are using any integration modules?

Chris

Am 16.09.20, 14:36 schrieb "Vladyslav Milutin" :

Hello guys,

I'm writing to you with a hope that you can help me with exception
handling.
Currently after a long time connection can be reset by peer. See stacktrace
below.

I've tried to add a custom ChannelHandler which Overrides exceptionCaught()
and add it in Driver#initializePipeline() see code below. Also has tried to
add a channel that can be obtained from DefaultNettyPlcConnection. And none
of them actualy was added to the pipeline where this exception was thrown.

plc4x version: 0.7.0

StatckTrace:
2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
[io.netty.channel.DefaultChannelPipeline] onUnhandledInboundException - An
exceptionCaught() event was fired, and it reached at the tail of the
pipeline. It usually means the last handler in the pipeline did not handle
the exception.
java.io.IOException: Connection reset by peer
  at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
  at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
  at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
  at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
  at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
  at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:358)
  at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
  at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
  at

io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
  at

io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
  at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
  at

io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
  at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
  at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
  at

io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
  at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
  at

io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
  at java.base/java.lang.Thread.run(Thread.java:834)

Driver#initializePipeline:
try {
final Channel channel =
channelFactory.createChannel(this.handler);
channelFactory.initializePipeline(channel.pipeline());

} catch (PlcConnectionException e) {
log.error("Failed to create channel");
}

ChannelHandler:
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause)
{
log.warn("ExceptionCaught in worker: ctx = [{}], cause = [{}, {}],
workerName = [{}]",
ctx, cause.getClass(), cause.getMessage(), workerName);
if (cause instanceof ConnectTimeoutException) {
log.warn("ConnectionTimeout caught: workerName = [{}]",
workerName);
}
if ((cause instanceof IOException) &&
cause.getMessage().contains("Connection reset by peer")) {
log.warn("Connection reset by peer caught: workerName = [{}]",
workerName);
} else {
log.info("Unexpected exception caught: workerName = [{}]",
workerName);
}

this.callback.accept(cause);
}

DefaultNettyPlcConnection#channel:
log.info("Trying to get connection channel: worker name = [{}]",
this.workerName);
final Channel channel = ((DefaultNettyPlcConnection)
this.connection).getChannel();
log.info("Channel obtained successfully. Adding custom
channelHandler to it: channel = [{}], workerName = [{}]", channel,
this.workerName);
channel.pipeline().addLast(this.channelHandler);
log.info("ChannelHandler added: channel = [{}], channelHandler =
[{}], workerName = [{}]", channel, this.channelHandler, this.workerName);

Kind regards,
Vlad

Re: PLC4X on Android?

[Niklas Merz]

Hi again,

Good news! I got the PlcDriverManager working with Dalvik classloading
in my Cordova plugin.

Turns out my previews finding took me to a wrong route:

> ClassLoader cl = ClassLoader.getSystemClassLoader();
> Thread.currentThread().setContextClassLoader(cl);

I was not really familiar with the Cordova thread concept. My code runs
in a different thread than the webview. The classloader I got this was
somehow was not able to properly load the PLC4X classes. Don't ask me
why :-).

I just see Dalvik has a different path:

dalvik.system.PathClassLoader[DexPathList[[directory "."],
dalvik.system.PathClassLoader[DexPathList[[zip file
"/data/app/io.cordova.hellocordova

If I run the PlcDriverManager in the Cordova UI thread via
"runOnUiThread", it works just fine.

The PLC4X Cordova plugin now works in general.

Thank you all for your help.

Kind regards
Niklas

Re: PLC4X on Android?

[Julian Feinauer]

Hi Niklas,

excellent findings!
I try to support you on that as good as I can.
One hint.. you can turn on DEBUG logging, than the DriverManager prints all 
Drivers that he registers at startup directly, perhaps this helps a bit...

Julian

Am 09.01.20, 23:07 schrieb "Niklas Merz" :

Hi Chris,

Thank you for your suggestions. That brought me a step further. I tried
using the S7 manually and it works!

I will try to work on finding more about the class loading issue again
soon. Just to keep you all updated and document my findings:

I have a new error now. The PlcDriverManager gets the Clasloader from
the current thread. I found out that you can set the Classloader like this:

 ClassLoader cl = ClassLoader.getSystemClassLoader();
 Thread.currentThread().setContextClassLoader(cl);

That results in a different log output
PlcDriverManager: Instantiating new PLC Driver Manager with class loader
dalvik.system.PathClassLoader[DexPathList[[directory
"."],nativeLibraryDirectories=[/system/lib, /system/lib]]]
PlcDriverManager: Registering available drivers...
Unable to find driver for protocol 's7'

Now the driver manager seems to a have Classloader but still cannot load
the driver classes. Like you said the Dalvik system seems to work
differently.

Let's see if I can find something new next time.

Kind regards
Niklas


Am 08.01.20 um 10:56 schrieb Christofer Dutz:
> Hi Niklas,
> 
> Herhaps you need to manually build a classloader? But I don't quite know 
how this is done. As far as I understood it, the Dalvik system is more a 
cross-compilation thing that compiles Java bytecode to something Android can 
run.
> You can probably just not use the DriverManager and instantiate the 
Driver classes manually as a first test. This way you would avoid all of our 
classloading-magic. 
> 
> Chris
> 
> 
> Am 07.01.20, 23:03 schrieb "Niklas Merz" :
> 
> Hello again,
> 
> Julian motivated me and I quickly cobbled together a PLC4X Cordova
> plugin to see if it works. I can now call PLC4X via Javascript in a 
web
> app bundled with Cordova for Android :-).
> 
> But I got the first problem. Seems like Cordova does class loading
> differently than my pure Android example. PLC4X cannot load the S7
> driver and fails at init.
> 
> Android Log:
> Instantiating new PLC Driver Manager with class loader
> dalvik.system.PathClassLoader
> 
> Cordova Log:
> org.apache.plc4x.java.PlcDriverManager: Instantiating new PLC Driver
> Manager with class loader null
> 
> I am not really a Java expert but you may know how to fix this.
> 
> Here is my plugin which is a PoC right now:
> https://github.com/NiklasMerz/cordova-plugin-plc4x
> 
> Niklas
> 
> Am 07.01.20 um 21:06 schrieb Julian Feinauer:
> > Whoop, whoop Niklas!
> > Thanks for your work!
> > 
> > Julian
> > 
> > Von meinem Mobiltelefon gesendet
> > 
    > > 
> >  Ursprüngliche Nachricht 
> > Von: Niklas Merz 
> > Datum: Di., 7. Jan. 2020, 20:56
> > An: dev@plc4x.apache.org
> > Betreff: Re: PLC4X on Android?
> > Hi all,
> > 
> > Turns out Netty seems to work just fine on Android, but we forgot to
> > give the app network permission. I just pushed the latest changes to
> > my example project and you can use for demos etc as you like.
> > 
> > https://github.com/NiklasMerz/plc4x-android-demo
> > 
> > The Android app project itself is not that special. I just added 
some
> > dependencies and config code to get log4j properly working and did 
the
> > permission requests.
> > 
> > Regards Niklas
> > 
> > Am 07.01.20 um 14:00 schrieb Christofer Dutz:
> >> Hi Julian,
> >>
> >> I'll trust on your judgement here ... just wanted to mention we're 
using OIO stuff ... so we keep it on the radar.
> >>
> >> Chris
> >>
> >> Am 07.01.20, 13:05 schrieb "Julian Feinauer" 
:
> >>
> >> Hi Chris,
> >>
> >> its not black and white.
> >> And Oio is deprecated for

Re: PLC4X on Android?

[Niklas Merz]

Hi Chris,

Thank you for your suggestions. That brought me a step further. I tried
using the S7 manually and it works!

I will try to work on finding more about the class loading issue again
soon. Just to keep you all updated and document my findings:

I have a new error now. The PlcDriverManager gets the Clasloader from
the current thread. I found out that you can set the Classloader like this:

 ClassLoader cl = ClassLoader.getSystemClassLoader();
 Thread.currentThread().setContextClassLoader(cl);

That results in a different log output
PlcDriverManager: Instantiating new PLC Driver Manager with class loader
dalvik.system.PathClassLoader[DexPathList[[directory
"."],nativeLibraryDirectories=[/system/lib, /system/lib]]]
PlcDriverManager: Registering available drivers...
Unable to find driver for protocol 's7'

Now the driver manager seems to a have Classloader but still cannot load
the driver classes. Like you said the Dalvik system seems to work
differently.

Let's see if I can find something new next time.

Kind regards
Niklas


Am 08.01.20 um 10:56 schrieb Christofer Dutz:
> Hi Niklas,
> 
> Herhaps you need to manually build a classloader? But I don't quite know how 
> this is done. As far as I understood it, the Dalvik system is more a 
> cross-compilation thing that compiles Java bytecode to something Android can 
> run.
> You can probably just not use the DriverManager and instantiate the Driver 
> classes manually as a first test. This way you would avoid all of our 
> classloading-magic. 
> 
> Chris
> 
> 
> Am 07.01.20, 23:03 schrieb "Niklas Merz" :
> 
> Hello again,
> 
> Julian motivated me and I quickly cobbled together a PLC4X Cordova
> plugin to see if it works. I can now call PLC4X via Javascript in a web
> app bundled with Cordova for Android :-).
> 
> But I got the first problem. Seems like Cordova does class loading
> differently than my pure Android example. PLC4X cannot load the S7
> driver and fails at init.
> 
> Android Log:
> Instantiating new PLC Driver Manager with class loader
> dalvik.system.PathClassLoader
> 
> Cordova Log:
> org.apache.plc4x.java.PlcDriverManager: Instantiating new PLC Driver
> Manager with class loader null
> 
> I am not really a Java expert but you may know how to fix this.
> 
> Here is my plugin which is a PoC right now:
> https://github.com/NiklasMerz/cordova-plugin-plc4x
> 
> Niklas
> 
> Am 07.01.20 um 21:06 schrieb Julian Feinauer:
> > Whoop, whoop Niklas!
> > Thanks for your work!
> > 
> > Julian
> > 
> > Von meinem Mobiltelefon gesendet
> > 
> > 
> >  Ursprüngliche Nachricht 
> > Von: Niklas Merz 
> > Datum: Di., 7. Jan. 2020, 20:56
> > An: dev@plc4x.apache.org
> > Betreff: Re: PLC4X on Android?
> > Hi all,
> > 
> > Turns out Netty seems to work just fine on Android, but we forgot to
> > give the app network permission. I just pushed the latest changes to
> > my example project and you can use for demos etc as you like.
> > 
> > https://github.com/NiklasMerz/plc4x-android-demo
> > 
> > The Android app project itself is not that special. I just added some
> > dependencies and config code to get log4j properly working and did the
> > permission requests.
> > 
> > Regards Niklas
> > 
> > Am 07.01.20 um 14:00 schrieb Christofer Dutz:
> >> Hi Julian,
> >>
> >> I'll trust on your judgement here ... just wanted to mention we're 
> using OIO stuff ... so we keep it on the radar.
> >>
> >> Chris
> >>
> >> Am 07.01.20, 13:05 schrieb "Julian Feinauer" 
> :
> >>
> >> Hi Chris,
> >>
> >> its not black and white.
> >> And Oio is deprecated for Netty 4.x but will be available till 
> Netty 5 comes out.
> >> And I discussed the RawSocket thing with Norman Maurer (Maintainer 
> of Netty) and he himself suggested/agreed to go with Oio for this use case as 
> the way Pcap works is more Oio-esque than Nio-esque so I did that.
> >> To Migrate it would mean 2 days of coding and whats really worse, 
> to hack a Nio-esque behavior for Pcap which would be pretty complex software 
> and hard to maintain.
> >> So I finally chose to go with Oio as its only deprecated to be 
> taken off maintenance and not because of stability or security or whatever.
> >>

Re: PLC4X on Android?

[Christofer Dutz]

Hi Niklas,

Herhaps you need to manually build a classloader? But I don't quite know how 
this is done. As far as I understood it, the Dalvik system is more a 
cross-compilation thing that compiles Java bytecode to something Android can 
run.
You can probably just not use the DriverManager and instantiate the Driver 
classes manually as a first test. This way you would avoid all of our 
classloading-magic. 

Chris


Am 07.01.20, 23:03 schrieb "Niklas Merz" :

Hello again,

Julian motivated me and I quickly cobbled together a PLC4X Cordova
plugin to see if it works. I can now call PLC4X via Javascript in a web
app bundled with Cordova for Android :-).

But I got the first problem. Seems like Cordova does class loading
differently than my pure Android example. PLC4X cannot load the S7
driver and fails at init.

Android Log:
Instantiating new PLC Driver Manager with class loader
dalvik.system.PathClassLoader

Cordova Log:
org.apache.plc4x.java.PlcDriverManager: Instantiating new PLC Driver
Manager with class loader null

I am not really a Java expert but you may know how to fix this.

Here is my plugin which is a PoC right now:
https://github.com/NiklasMerz/cordova-plugin-plc4x

Niklas

Am 07.01.20 um 21:06 schrieb Julian Feinauer:
> Whoop, whoop Niklas!
> Thanks for your work!
> 
> Julian
> 
> Von meinem Mobiltelefon gesendet
> 
> 
>  Ursprüngliche Nachricht 
> Von: Niklas Merz 
> Datum: Di., 7. Jan. 2020, 20:56
    > An: dev@plc4x.apache.org
> Betreff: Re: PLC4X on Android?
> Hi all,
> 
> Turns out Netty seems to work just fine on Android, but we forgot to
> give the app network permission. I just pushed the latest changes to
> my example project and you can use for demos etc as you like.
> 
> https://github.com/NiklasMerz/plc4x-android-demo
> 
> The Android app project itself is not that special. I just added some
> dependencies and config code to get log4j properly working and did the
> permission requests.
> 
> Regards Niklas
> 
> Am 07.01.20 um 14:00 schrieb Christofer Dutz:
>> Hi Julian,
>>
>> I'll trust on your judgement here ... just wanted to mention we're using 
OIO stuff ... so we keep it on the radar.
>>
>> Chris
>>
>> Am 07.01.20, 13:05 schrieb "Julian Feinauer" 
:
>>
>> Hi Chris,
>>
>> its not black and white.
>> And Oio is deprecated for Netty 4.x but will be available till Netty 
5 comes out.
>> And I discussed the RawSocket thing with Norman Maurer (Maintainer 
of Netty) and he himself suggested/agreed to go with Oio for this use case as 
the way Pcap works is more Oio-esque than Nio-esque so I did that.
>> To Migrate it would mean 2 days of coding and whats really worse, to 
hack a Nio-esque behavior for Pcap which would be pretty complex software and 
hard to maintain.
>> So I finally chose to go with Oio as its only deprecated to be taken 
off maintenance and not because of stability or security or whatever.
>>
>> Thus, it depends : )
>>
>> Julian
>>
>> Am 07.01.20, 12:53 schrieb "Christofer Dutz" 
:
>>
>> Hi Julian,
>>
>> Then we should update the RawSocketChannel as that is based on 
OIO ...
>> the PCAP Channel I don't really care as it's for testing and 
development only anyway.
>>
>> Chris
>>
>> Am 07.01.20, 12:46 schrieb "Julian Feinauer" 
:
>>
>> Hi Chris,
>>
>> I agree that we should never use Oio for Productive Code 
(instead of Serial where its fine, I think).
>> But, yes, we could add other transports for "edge" cases or 
something.
>> Currently that’s just a toy project we try to get running, 
but I see some interesting options there : )
>>
>> Julian
>>
>> Am 07.01.20, 12:39 schrieb "Christofer Dutz" 
:
>>
>> Hi all,
>>
>> I Think the OIO options are usually marked as deprecated 
in favor of NIO.
>>
>> But I think we could do one thing. The same way I can 
pass in a different ChannelFactory for testing or PCAP input or whatever we 
want to use, we could have additional TCP channel-factories that explicitly use 
OIO.
>>

Re: PLC4X on Android?

[Niklas Merz]

Hello again,

Julian motivated me and I quickly cobbled together a PLC4X Cordova
plugin to see if it works. I can now call PLC4X via Javascript in a web
app bundled with Cordova for Android :-).

But I got the first problem. Seems like Cordova does class loading
differently than my pure Android example. PLC4X cannot load the S7
driver and fails at init.

Android Log:
Instantiating new PLC Driver Manager with class loader
dalvik.system.PathClassLoader

Cordova Log:
org.apache.plc4x.java.PlcDriverManager: Instantiating new PLC Driver
Manager with class loader null

I am not really a Java expert but you may know how to fix this.

Here is my plugin which is a PoC right now:
https://github.com/NiklasMerz/cordova-plugin-plc4x

Niklas

Am 07.01.20 um 21:06 schrieb Julian Feinauer:
> Whoop, whoop Niklas!
> Thanks for your work!
> 
> Julian
> 
> Von meinem Mobiltelefon gesendet
> 
> 
>  Ursprüngliche Nachricht 
> Von: Niklas Merz 
> Datum: Di., 7. Jan. 2020, 20:56
> An: dev@plc4x.apache.org
> Betreff: Re: PLC4X on Android?
> Hi all,
> 
> Turns out Netty seems to work just fine on Android, but we forgot to
> give the app network permission. I just pushed the latest changes to
> my example project and you can use for demos etc as you like.
> 
> https://github.com/NiklasMerz/plc4x-android-demo
> 
> The Android app project itself is not that special. I just added some
> dependencies and config code to get log4j properly working and did the
> permission requests.
> 
> Regards Niklas
> 
> Am 07.01.20 um 14:00 schrieb Christofer Dutz:
>> Hi Julian,
>>
>> I'll trust on your judgement here ... just wanted to mention we're using OIO 
>> stuff ... so we keep it on the radar.
>>
>> Chris
>>
>> Am 07.01.20, 13:05 schrieb "Julian Feinauer" :
>>
>> Hi Chris,
>>
>> its not black and white.
>> And Oio is deprecated for Netty 4.x but will be available till Netty 5 
>> comes out.
>> And I discussed the RawSocket thing with Norman Maurer (Maintainer of 
>> Netty) and he himself suggested/agreed to go with Oio for this use case as 
>> the way Pcap works is more Oio-esque than Nio-esque so I did that.
>> To Migrate it would mean 2 days of coding and whats really worse, to 
>> hack a Nio-esque behavior for Pcap which would be pretty complex software 
>> and hard to maintain.
>> So I finally chose to go with Oio as its only deprecated to be taken off 
>> maintenance and not because of stability or security or whatever.
>>
>> Thus, it depends : )
>>
>> Julian
>>
>> Am 07.01.20, 12:53 schrieb "Christofer Dutz" :
>>
>> Hi Julian,
>>
>> Then we should update the RawSocketChannel as that is based on OIO 
>> ...
>> the PCAP Channel I don't really care as it's for testing and 
>> development only anyway.
>>
>> Chris
>>
>> Am 07.01.20, 12:46 schrieb "Julian Feinauer" 
>> :
>>
>> Hi Chris,
>>
>> I agree that we should never use Oio for Productive Code 
>> (instead of Serial where its fine, I think).
>> But, yes, we could add other transports for "edge" cases or 
>> something.
>> Currently that’s just a toy project we try to get running, but I 
>> see some interesting options there : )
>>
>> Julian
>>
>> Am 07.01.20, 12:39 schrieb "Christofer Dutz" 
>> :
>>
>> Hi all,
>>
>> I Think the OIO options are usually marked as deprecated in 
>> favor of NIO.
>>
>> But I think we could do one thing. The same way I can pass 
>> in a different ChannelFactory for testing or PCAP input or whatever we want 
>> to use, we could have additional TCP channel-factories that explicitly use 
>> OIO.
>> Then we could add a parameter such as 
>> "androidCompatability=true" to the string and use that instead?
>>
>> Would that be an option?
>>
>> Chris
>>
>>
>>
>> Am 07.01.20, 12:01 schrieb "Julian Feinauer" 
>> :
>>
>> Hi folks,
>>
>> yesterday our good friend @Niklas 
>> Merz<mailto:niklasm...@apache.org> did a little bit of Android Vodoo to make 
>> an Example of PLC4X for Android here: 
>> https://github.com/NiklasMerz/plc4x-android-demo
>> So does PLC4X work on And

Re: PLC4X on Android?

[Niklas Merz]

Hi all,

Turns out Netty seems to work just fine on Android, but we forgot to
give the app network permission. I just pushed the latest changes to
my example project and you can use for demos etc as you like.

https://github.com/NiklasMerz/plc4x-android-demo

The Android app project itself is not that special. I just added some
dependencies and config code to get log4j properly working and did the
permission requests.

Regards Niklas

Am 07.01.20 um 14:00 schrieb Christofer Dutz:
> Hi Julian,
> 
> I'll trust on your judgement here ... just wanted to mention we're using OIO 
> stuff ... so we keep it on the radar.
> 
> Chris
> 
> Am 07.01.20, 13:05 schrieb "Julian Feinauer" :
> 
> Hi Chris,
> 
> its not black and white.
> And Oio is deprecated for Netty 4.x but will be available till Netty 5 
> comes out.
> And I discussed the RawSocket thing with Norman Maurer (Maintainer of 
> Netty) and he himself suggested/agreed to go with Oio for this use case as 
> the way Pcap works is more Oio-esque than Nio-esque so I did that.
> To Migrate it would mean 2 days of coding and whats really worse, to hack 
> a Nio-esque behavior for Pcap which would be pretty complex software and hard 
> to maintain.
> So I finally chose to go with Oio as its only deprecated to be taken off 
> maintenance and not because of stability or security or whatever.
> 
> Thus, it depends : )
> 
> Julian
> 
> Am 07.01.20, 12:53 schrieb "Christofer Dutz" :
> 
> Hi Julian,
> 
> Then we should update the RawSocketChannel as that is based on OIO 
> ... 
> the PCAP Channel I don't really care as it's for testing and 
> development only anyway.
> 
> Chris
> 
> Am 07.01.20, 12:46 schrieb "Julian Feinauer" 
> :
> 
> Hi Chris,
> 
> I agree that we should never use Oio for Productive Code (instead 
> of Serial where its fine, I think).
> But, yes, we could add other transports for "edge" cases or 
> something.
> Currently that’s just a toy project we try to get running, but I 
> see some interesting options there : )
> 
> Julian
> 
> Am 07.01.20, 12:39 schrieb "Christofer Dutz" 
> :
> 
> Hi all,
> 
> I Think the OIO options are usually marked as deprecated in 
> favor of NIO.
> 
> But I think we could do one thing. The same way I can pass in 
> a different ChannelFactory for testing or PCAP input or whatever we want to 
> use, we could have additional TCP channel-factories that explicitly use OIO.
> Then we could add a parameter such as 
> "androidCompatability=true" to the string and use that instead?
> 
> Would that be an option? 
> 
> Chris
> 
> 
> 
> Am 07.01.20, 12:01 schrieb "Julian Feinauer" 
> :
> 
> Hi folks,
> 
> yesterday our good friend @Niklas 
> Merz did a little bit of Android Vodoo to make 
> an Example of PLC4X for Android here: 
> https://github.com/NiklasMerz/plc4x-android-demo
> So does PLC4X work on Android? No, not really…
> 
> It turns out, that Netty does not really work on Android 
> (well it does but not with our settings)…
> So we could see how far we’d like to push that.
> As it seems one way could be to use Oio Instead of Nio 
> (https://stackoverflow.com/questions/11007879/client-server-application-for-android-with-netty-integration).
> Currently I see no need for that, but I think its an 
> interesting Idea (not talking about if someone should really do it, but COULD 
> do it).
> If I find some time I will create a branch which builds 
> Netty on Oio instead of Nio and test it further with Niklas.
> 
> Best
> Julian
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: PLC4X on Android?

[Christofer Dutz]

Hi Julian,

I'll trust on your judgement here ... just wanted to mention we're using OIO 
stuff ... so we keep it on the radar.

Chris

Am 07.01.20, 13:05 schrieb "Julian Feinauer" :

Hi Chris,

its not black and white.
And Oio is deprecated for Netty 4.x but will be available till Netty 5 
comes out.
And I discussed the RawSocket thing with Norman Maurer (Maintainer of 
Netty) and he himself suggested/agreed to go with Oio for this use case as the 
way Pcap works is more Oio-esque than Nio-esque so I did that.
To Migrate it would mean 2 days of coding and whats really worse, to hack a 
Nio-esque behavior for Pcap which would be pretty complex software and hard to 
maintain.
So I finally chose to go with Oio as its only deprecated to be taken off 
maintenance and not because of stability or security or whatever.

Thus, it depends : )

Julian

Am 07.01.20, 12:53 schrieb "Christofer Dutz" :

Hi Julian,

Then we should update the RawSocketChannel as that is based on OIO ... 
the PCAP Channel I don't really care as it's for testing and 
development only anyway.

Chris

Am 07.01.20, 12:46 schrieb "Julian Feinauer" 
:

Hi Chris,

I agree that we should never use Oio for Productive Code (instead 
of Serial where its fine, I think).
But, yes, we could add other transports for "edge" cases or 
something.
Currently that’s just a toy project we try to get running, but I 
see some interesting options there : )

Julian

Am 07.01.20, 12:39 schrieb "Christofer Dutz" 
:

Hi all,

I Think the OIO options are usually marked as deprecated in 
favor of NIO.

But I think we could do one thing. The same way I can pass in a 
different ChannelFactory for testing or PCAP input or whatever we want to use, 
we could have additional TCP channel-factories that explicitly use OIO.
Then we could add a parameter such as 
"androidCompatability=true" to the string and use that instead?

Would that be an option? 

Chris



Am 07.01.20, 12:01 schrieb "Julian Feinauer" 
:

Hi folks,

yesterday our good friend @Niklas 
Merz did a little bit of Android Vodoo to make an 
Example of PLC4X for Android here: 
https://github.com/NiklasMerz/plc4x-android-demo
So does PLC4X work on Android? No, not really…

It turns out, that Netty does not really work on Android 
(well it does but not with our settings)…
So we could see how far we’d like to push that.
As it seems one way could be to use Oio Instead of Nio 
(https://stackoverflow.com/questions/11007879/client-server-application-for-android-with-netty-integration).
Currently I see no need for that, but I think its an 
interesting Idea (not talking about if someone should really do it, but COULD 
do it).
If I find some time I will create a branch which builds 
Netty on Oio instead of Nio and test it further with Niklas.

Best
Julian

Re: PLC4X on Android?

[Julian Feinauer]

Hi Chris,

its not black and white.
And Oio is deprecated for Netty 4.x but will be available till Netty 5 comes 
out.
And I discussed the RawSocket thing with Norman Maurer (Maintainer of Netty) 
and he himself suggested/agreed to go with Oio for this use case as the way 
Pcap works is more Oio-esque than Nio-esque so I did that.
To Migrate it would mean 2 days of coding and whats really worse, to hack a 
Nio-esque behavior for Pcap which would be pretty complex software and hard to 
maintain.
So I finally chose to go with Oio as its only deprecated to be taken off 
maintenance and not because of stability or security or whatever.

Thus, it depends : )

Julian

Am 07.01.20, 12:53 schrieb "Christofer Dutz" :

Hi Julian,

Then we should update the RawSocketChannel as that is based on OIO ... 
the PCAP Channel I don't really care as it's for testing and development 
only anyway.

Chris

Am 07.01.20, 12:46 schrieb "Julian Feinauer" :

Hi Chris,

I agree that we should never use Oio for Productive Code (instead of 
Serial where its fine, I think).
But, yes, we could add other transports for "edge" cases or something.
Currently that’s just a toy project we try to get running, but I see 
some interesting options there : )

Julian

Am 07.01.20, 12:39 schrieb "Christofer Dutz" 
:

Hi all,

I Think the OIO options are usually marked as deprecated in favor 
of NIO.

But I think we could do one thing. The same way I can pass in a 
different ChannelFactory for testing or PCAP input or whatever we want to use, 
we could have additional TCP channel-factories that explicitly use OIO.
Then we could add a parameter such as "androidCompatability=true" 
to the string and use that instead?

Would that be an option? 

Chris



Am 07.01.20, 12:01 schrieb "Julian Feinauer" 
:

Hi folks,

yesterday our good friend @Niklas 
Merz did a little bit of Android Vodoo to make an 
Example of PLC4X for Android here: 
https://github.com/NiklasMerz/plc4x-android-demo
So does PLC4X work on Android? No, not really…

It turns out, that Netty does not really work on Android (well 
it does but not with our settings)…
So we could see how far we’d like to push that.
As it seems one way could be to use Oio Instead of Nio 
(https://stackoverflow.com/questions/11007879/client-server-application-for-android-with-netty-integration).
Currently I see no need for that, but I think its an 
interesting Idea (not talking about if someone should really do it, but COULD 
do it).
If I find some time I will create a branch which builds Netty 
on Oio instead of Nio and test it further with Niklas.

Best
Julian

Re: PLC4X on Android?

[Christofer Dutz]

Hi Julian,

Then we should update the RawSocketChannel as that is based on OIO ... 
the PCAP Channel I don't really care as it's for testing and development only 
anyway.

Chris

Am 07.01.20, 12:46 schrieb "Julian Feinauer" :

Hi Chris,

I agree that we should never use Oio for Productive Code (instead of Serial 
where its fine, I think).
But, yes, we could add other transports for "edge" cases or something.
Currently that’s just a toy project we try to get running, but I see some 
interesting options there : )

Julian

Am 07.01.20, 12:39 schrieb "Christofer Dutz" :

Hi all,

I Think the OIO options are usually marked as deprecated in favor of 
NIO.

But I think we could do one thing. The same way I can pass in a 
different ChannelFactory for testing or PCAP input or whatever we want to use, 
we could have additional TCP channel-factories that explicitly use OIO.
Then we could add a parameter such as "androidCompatability=true" to 
the string and use that instead?

Would that be an option? 

Chris



Am 07.01.20, 12:01 schrieb "Julian Feinauer" 
:

Hi folks,

yesterday our good friend @Niklas 
Merz did a little bit of Android Vodoo to make an 
Example of PLC4X for Android here: 
https://github.com/NiklasMerz/plc4x-android-demo
So does PLC4X work on Android? No, not really…

It turns out, that Netty does not really work on Android (well it 
does but not with our settings)…
So we could see how far we’d like to push that.
As it seems one way could be to use Oio Instead of Nio 
(https://stackoverflow.com/questions/11007879/client-server-application-for-android-with-netty-integration).
Currently I see no need for that, but I think its an interesting 
Idea (not talking about if someone should really do it, but COULD do it).
If I find some time I will create a branch which builds Netty on 
Oio instead of Nio and test it further with Niklas.

Best
Julian

Re: PLC4X on Android?

[Julian Feinauer]

Hi Chris,

I agree that we should never use Oio for Productive Code (instead of Serial 
where its fine, I think).
But, yes, we could add other transports for "edge" cases or something.
Currently that’s just a toy project we try to get running, but I see some 
interesting options there : )

Julian

Am 07.01.20, 12:39 schrieb "Christofer Dutz" :

Hi all,

I Think the OIO options are usually marked as deprecated in favor of NIO.

But I think we could do one thing. The same way I can pass in a different 
ChannelFactory for testing or PCAP input or whatever we want to use, we could 
have additional TCP channel-factories that explicitly use OIO.
Then we could add a parameter such as "androidCompatability=true" to the 
string and use that instead?

Would that be an option? 

Chris



Am 07.01.20, 12:01 schrieb "Julian Feinauer" :

Hi folks,

yesterday our good friend @Niklas Merz 
did a little bit of Android Vodoo to make an Example of PLC4X for Android here: 
https://github.com/NiklasMerz/plc4x-android-demo
So does PLC4X work on Android? No, not really…

It turns out, that Netty does not really work on Android (well it does 
but not with our settings)…
So we could see how far we’d like to push that.
As it seems one way could be to use Oio Instead of Nio 
(https://stackoverflow.com/questions/11007879/client-server-application-for-android-with-netty-integration).
Currently I see no need for that, but I think its an interesting Idea 
(not talking about if someone should really do it, but COULD do it).
If I find some time I will create a branch which builds Netty on Oio 
instead of Nio and test it further with Niklas.

Best
Julian

Re: PLC4X on Android?

[Christofer Dutz]

Hi all,

I Think the OIO options are usually marked as deprecated in favor of NIO.

But I think we could do one thing. The same way I can pass in a different 
ChannelFactory for testing or PCAP input or whatever we want to use, we could 
have additional TCP channel-factories that explicitly use OIO.
Then we could add a parameter such as "androidCompatability=true" to the string 
and use that instead?

Would that be an option? 

Chris



Am 07.01.20, 12:01 schrieb "Julian Feinauer" :

Hi folks,

yesterday our good friend @Niklas Merz did a 
little bit of Android Vodoo to make an Example of PLC4X for Android here: 
https://github.com/NiklasMerz/plc4x-android-demo
So does PLC4X work on Android? No, not really…

It turns out, that Netty does not really work on Android (well it does but 
not with our settings)…
So we could see how far we’d like to push that.
As it seems one way could be to use Oio Instead of Nio 
(https://stackoverflow.com/questions/11007879/client-server-application-for-android-with-netty-integration).
Currently I see no need for that, but I think its an interesting Idea (not 
talking about if someone should really do it, but COULD do it).
If I find some time I will create a branch which builds Netty on Oio 
instead of Nio and test it further with Niklas.

Best
Julian

Re: PLC4X code retreat in December

[Christofer Dutz]

Hi all,

as we will be doing our working session next week I would need to know who will 
actually attend.
So far I know of:
- Julian
- Tim
- Me

Anyone else? I need to inform the Co-Working space how many people to expect.
If you are coming you should also handle your accommodation.

Chris



Am 22.11.19, 19:55 schrieb "Christofer Dutz" :

Hi all,

I just wanted to announce, that form 17.12.2019-19.12.2019 we’ll be doing a 
code-retreat in Weinheim (Germany).

This is not intended to be a normal community event where we will be 
onboarding new people, but more a hardcore working session.
We want to work on options for refactoring the PLC4X API and refactor the 
internal structure towards a 1.0.0 version of PLC4X.

Space is limited, and you will be asked to cover the costs for 
shared-office-rental as well as accommodation yourself.

So if you are already very familiar with PLC4X, the API and the project in 
general and want to participate in this session, you are more than welcome.

Also note that we will be requiring you to participate the full time in 
order to be productive.

We won’t be bringing anything back to develop without discussing this the 
community on this listwith. So no worries, if you are unable to participate.

Chris

Re: PLC4X

[Cesar Garcia]

Hi all,

1+, for the hangout,  I will be in touch

Best regards,


El vie., 15 nov. 2019 a las 4:48, Christofer Dutz (<
christofer.d...@c-ware.de>) escribió:

> Hi all,
>
> I contacted Bart via LinkedIn as I saw he's not subscribed to the list and
> the email was intentionally ... well ... incorrect
> (Don't know if removing the INVALID is enough)
>
> I offered a hangout net week ... will keep you informed and coordinate
> with you as soon as he responds.
>
> Chris
>
>
>
> Am 15.11.19, 09:27 schrieb "Julian Feinauer" <
> j.feina...@pragmaticminds.de>:
>
> Hi,
>
> Yes, why not a hangout as other projects do.
> We have multiple things to share and show and could do both, technical
> and user perspective sessions.
> If wanted I could invite on a two week schedule.
>
> What do others think?
>
> Julian
> 
>     From: Ott, Lukas 
> Sent: Friday, November 15, 2019 8:10:29 AM
> To: dev@plc4x.apache.org 
> Subject: RE: PLC4X
>
> +1 for a public Webinar-Session that is also announced via Twitter
> etc. So more people can participate. Maybe stream on Apache YT Channel?
>
> Lukas Ott
> Associate Consultant Business
> Industry Consulting Manufacturing - North and Central Europe
> DXC Technology
> Alfred-Herrhausen-Allee 3-5, 65760 Eschborn, Germany
> M: +49.173.705.2298 | lo...@dxc.com | LinkedIn | Twitter Me
> Notice of temporary leave
>
> DXC Technology Deutschland GmbH * This is a PRIVATE message. If you
> are not the intended recipient, please delete without copying and kindly
> advise us by e-mail of the mistake in delivery. NOTE: Regardless of
> content, this e-mail shall not operate to bind DXC to any order or other
> contract unless pursuant to explicit written agreement or government
> initiative expressly permitting the use of e-mail for such purpose*
> Registered Office: Alfred-Herrhausen-Allee 3-5, 65760 Eschborn, Germany *
> Registered in Germany: HRB 11307
>
> -Original Message-
> From: Christofer Dutz 
> Sent: Donnerstag, 14. November 2019 23:30
> To: dev@plc4x.apache.org
> Subject: AW: PLC4X
>
> Hi Bart,
>
> We're happy you found your way to us and of course we would be happy
> for any help you could offer. After all open source lives from this.
>
> Usually it's not the typical way Apache projects do it, as we usually
> do everything on the mailinglist, however I wold be happy to assist you
> with your request of a call, if we bring things back to the list after that.
>
> Perhaps a conference call would be a good idea, so others could attend
> and not only me.
>
> Would next week work for you, as I'm currently traveling in Brussels
> and will be back to normal business on Monday? Next week I just noticed
> that my calendar it pretty much competency free, so I could probably do
> almost any time.
>
> Chris
>
> 
> Von: Schouwenaars-Harms, Bart 
> Gesendet: Donnerstag, 14. November 2019 15:27:12
> An: dev@plc4x.apache.org 
> Betreff: PLC4X
>
>
> Hi,
>
> Through some Google searches I found your website in PLC4X and I was
> immediately very interested by what you are trying to achieve. Would it be
> possible to set up a call sometime where we can discuss how I can help you
> with your work?
>
>
>
> Kind regards,
>
> Bart Schouwenaars-Harms
>
> Sr Manager - Product SAs
>
> AWS IoT - Outcome-Driven Engineering
>
> +44 (0) 7810 554071
>
>
>
> [cid:image001.png@01D59AF7.D7406960]<http://www.aws.amazon.com/>
>
>
>
> Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855
> Luxembourg, R.C.S. Luxembourg B186284
>
> Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship
> Street, London, EC2A 2FA, United Kingdom, registered in England and Wales,
> UK Establishment No. BR019315
>
>
>
> DXC Technology Deutschland GmbH: Alfred-Herrhausen-Allee 3-5, 65760
> Eschborn, Germany - Board of Directors: Dirk Schürmann, Joachim Löffler,
> Karl Anzboeck, Claus Schünemann - Registered in Bad Homburg: HRB 14227.
> DXC Technology Company -- This message is transmitted to you by or on
> behalf of DXC Technology Company or one of its affiliates.  It is intended
> exclusively for the addressee.  The substance of this message, along with
> any attachments, may contain proprietary, confidential or privileged
> information or information that is otherwise legally exempt from
> disclosure. Any unauthorized review, use, disclosure

Re: PLC4X

[Christofer Dutz]

Hi all,

I contacted Bart via LinkedIn as I saw he's not subscribed to the list and the 
email was intentionally ... well ... incorrect 
(Don't know if removing the INVALID is enough)

I offered a hangout net week ... will keep you informed and coordinate with you 
as soon as he responds.

Chris



Am 15.11.19, 09:27 schrieb "Julian Feinauer" :

Hi,

Yes, why not a hangout as other projects do.
We have multiple things to share and show and could do both, technical and 
user perspective sessions.
If wanted I could invite on a two week schedule.

What do others think?

Julian

From: Ott, Lukas 
Sent: Friday, November 15, 2019 8:10:29 AM
To: dev@plc4x.apache.org 
    Subject: RE: PLC4X

+1 for a public Webinar-Session that is also announced via Twitter etc. So 
more people can participate. Maybe stream on Apache YT Channel?

Lukas Ott
Associate Consultant Business
Industry Consulting Manufacturing - North and Central Europe
DXC Technology
Alfred-Herrhausen-Allee 3-5, 65760 Eschborn, Germany
M: +49.173.705.2298 | lo...@dxc.com | LinkedIn | Twitter Me
Notice of temporary leave

DXC Technology Deutschland GmbH * This is a PRIVATE message. If you are not 
the intended recipient, please delete without copying and kindly advise us by 
e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail 
shall not operate to bind DXC to any order or other contract unless pursuant to 
explicit written agreement or government initiative expressly permitting the 
use of e-mail for such purpose* Registered Office: Alfred-Herrhausen-Allee 3-5, 
65760 Eschborn, Germany * Registered in Germany: HRB 11307

-Original Message-
From: Christofer Dutz 
Sent: Donnerstag, 14. November 2019 23:30
To: dev@plc4x.apache.org
Subject: AW: PLC4X

Hi Bart,

We're happy you found your way to us and of course we would be happy for 
any help you could offer. After all open source lives from this.

Usually it's not the typical way Apache projects do it, as we usually do 
everything on the mailinglist, however I wold be happy to assist you with your 
request of a call, if we bring things back to the list after that.

Perhaps a conference call would be a good idea, so others could attend and 
not only me.

Would next week work for you, as I'm currently traveling in Brussels and 
will be back to normal business on Monday? Next week I just noticed that my 
calendar it pretty much competency free, so I could probably do almost any time.

Chris


Von: Schouwenaars-Harms, Bart 
Gesendet: Donnerstag, 14. November 2019 15:27:12
An: dev@plc4x.apache.org 
Betreff: PLC4X


Hi,

Through some Google searches I found your website in PLC4X and I was 
immediately very interested by what you are trying to achieve. Would it be 
possible to set up a call sometime where we can discuss how I can help you with 
your work?



Kind regards,

Bart Schouwenaars-Harms

Sr Manager - Product SAs

AWS IoT - Outcome-Driven Engineering

+44 (0) 7810 554071



[cid:image001.png@01D59AF7.D7406960]<http://www.aws.amazon.com/>



Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 
Luxembourg, R.C.S. Luxembourg B186284

Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship 
Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK 
Establishment No. BR019315



DXC Technology Deutschland GmbH: Alfred-Herrhausen-Allee 3-5, 65760 
Eschborn, Germany - Board of Directors: Dirk Schürmann, Joachim Löffler, Karl 
Anzboeck, Claus Schünemann - Registered in Bad Homburg: HRB 14227.
DXC Technology Company -- This message is transmitted to you by or on 
behalf of DXC Technology Company or one of its affiliates.  It is intended 
exclusively for the addressee.  The substance of this message, along with any 
attachments, may contain proprietary, confidential or privileged information or 
information that is otherwise legally exempt from disclosure. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient of this message, you are not authorized to read, print, 
retain, copy or disseminate any part of this message. If you have received this 
message in error, please destroy and delete all copies and notify the sender by 
return e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose.

Re: PLC4X

[Julian Feinauer]

Hi,

Yes, why not a hangout as other projects do.
We have multiple things to share and show and could do both, technical and user 
perspective sessions.
If wanted I could invite on a two week schedule.

What do others think?

Julian

From: Ott, Lukas 
Sent: Friday, November 15, 2019 8:10:29 AM
To: dev@plc4x.apache.org 
Subject: RE: PLC4X

+1 for a public Webinar-Session that is also announced via Twitter etc. So more 
people can participate. Maybe stream on Apache YT Channel?

Lukas Ott
Associate Consultant Business
Industry Consulting Manufacturing - North and Central Europe
DXC Technology
Alfred-Herrhausen-Allee 3-5, 65760 Eschborn, Germany
M: +49.173.705.2298 | lo...@dxc.com | LinkedIn | Twitter Me
Notice of temporary leave

DXC Technology Deutschland GmbH * This is a PRIVATE message. If you are not the 
intended recipient, please delete without copying and kindly advise us by 
e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail 
shall not operate to bind DXC to any order or other contract unless pursuant to 
explicit written agreement or government initiative expressly permitting the 
use of e-mail for such purpose* Registered Office: Alfred-Herrhausen-Allee 3-5, 
65760 Eschborn, Germany * Registered in Germany: HRB 11307

-Original Message-
From: Christofer Dutz 
Sent: Donnerstag, 14. November 2019 23:30
To: dev@plc4x.apache.org
Subject: AW: PLC4X

Hi Bart,

We're happy you found your way to us and of course we would be happy for any 
help you could offer. After all open source lives from this.

Usually it's not the typical way Apache projects do it, as we usually do 
everything on the mailinglist, however I wold be happy to assist you with your 
request of a call, if we bring things back to the list after that.

Perhaps a conference call would be a good idea, so others could attend and not 
only me.

Would next week work for you, as I'm currently traveling in Brussels and will 
be back to normal business on Monday? Next week I just noticed that my calendar 
it pretty much competency free, so I could probably do almost any time.

Chris


Von: Schouwenaars-Harms, Bart 
Gesendet: Donnerstag, 14. November 2019 15:27:12
An: dev@plc4x.apache.org 
Betreff: PLC4X


Hi,

Through some Google searches I found your website in PLC4X and I was 
immediately very interested by what you are trying to achieve. Would it be 
possible to set up a call sometime where we can discuss how I can help you with 
your work?



Kind regards,

Bart Schouwenaars-Harms

Sr Manager - Product SAs

AWS IoT - Outcome-Driven Engineering

+44 (0) 7810 554071



[cid:image001.png@01D59AF7.D7406960]<http://www.aws.amazon.com/>



Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, 
R.C.S. Luxembourg B186284

Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, 
London, EC2A 2FA, United Kingdom, registered in England and Wales, UK 
Establishment No. BR019315



DXC Technology Deutschland GmbH: Alfred-Herrhausen-Allee 3-5, 65760 Eschborn, 
Germany - Board of Directors: Dirk Schürmann, Joachim Löffler, Karl Anzboeck, 
Claus Schünemann - Registered in Bad Homburg: HRB 14227.
DXC Technology Company -- This message is transmitted to you by or on behalf of 
DXC Technology Company or one of its affiliates.  It is intended exclusively 
for the addressee.  The substance of this message, along with any attachments, 
may contain proprietary, confidential or privileged information or information 
that is otherwise legally exempt from disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended recipient 
of this message, you are not authorized to read, print, retain, copy or 
disseminate any part of this message. If you have received this message in 
error, please destroy and delete all copies and notify the sender by return 
e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose.

RE: PLC4X

[Ott, Lukas]

+1 for a public Webinar-Session that is also announced via Twitter etc. So more 
people can participate. Maybe stream on Apache YT Channel?

Lukas Ott
Associate Consultant Business
Industry Consulting Manufacturing - North and Central Europe
DXC Technology
Alfred-Herrhausen-Allee 3-5, 65760 Eschborn, Germany
M: +49.173.705.2298 | lo...@dxc.com | LinkedIn | Twitter Me
Notice of temporary leave

DXC Technology Deutschland GmbH * This is a PRIVATE message. If you are not the 
intended recipient, please delete without copying and kindly advise us by 
e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail 
shall not operate to bind DXC to any order or other contract unless pursuant to 
explicit written agreement or government initiative expressly permitting the 
use of e-mail for such purpose* Registered Office: Alfred-Herrhausen-Allee 3-5, 
65760 Eschborn, Germany * Registered in Germany: HRB 11307

-Original Message-
From: Christofer Dutz 
Sent: Donnerstag, 14. November 2019 23:30
To: dev@plc4x.apache.org
Subject: AW: PLC4X

Hi Bart,

We're happy you found your way to us and of course we would be happy for any 
help you could offer. After all open source lives from this.

Usually it's not the typical way Apache projects do it, as we usually do 
everything on the mailinglist, however I wold be happy to assist you with your 
request of a call, if we bring things back to the list after that.

Perhaps a conference call would be a good idea, so others could attend and not 
only me.

Would next week work for you, as I'm currently traveling in Brussels and will 
be back to normal business on Monday? Next week I just noticed that my calendar 
it pretty much competency free, so I could probably do almost any time.

Chris


Von: Schouwenaars-Harms, Bart 
Gesendet: Donnerstag, 14. November 2019 15:27:12
An: dev@plc4x.apache.org 
Betreff: PLC4X


Hi,

Through some Google searches I found your website in PLC4X and I was 
immediately very interested by what you are trying to achieve. Would it be 
possible to set up a call sometime where we can discuss how I can help you with 
your work?



Kind regards,

Bart Schouwenaars-Harms

Sr Manager - Product SAs

AWS IoT - Outcome-Driven Engineering

+44 (0) 7810 554071



[cid:image001.png@01D59AF7.D7406960]



Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, 
R.C.S. Luxembourg B186284

Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, 
London, EC2A 2FA, United Kingdom, registered in England and Wales, UK 
Establishment No. BR019315



DXC Technology Deutschland GmbH: Alfred-Herrhausen-Allee 3-5, 65760 Eschborn, 
Germany - Board of Directors: Dirk Schürmann, Joachim Löffler, Karl Anzboeck, 
Claus Schünemann - Registered in Bad Homburg: HRB 14227.
DXC Technology Company -- This message is transmitted to you by or on behalf of 
DXC Technology Company or one of its affiliates.  It is intended exclusively 
for the addressee.  The substance of this message, along with any attachments, 
may contain proprietary, confidential or privileged information or information 
that is otherwise legally exempt from disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended recipient 
of this message, you are not authorized to read, print, retain, copy or 
disseminate any part of this message. If you have received this message in 
error, please destroy and delete all copies and notify the sender by return 
e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose.

Re: PLC4X and OSGi

[Christofer Dutz]

Hi,

I totally agree that it's a good thing that we can use PLC4X in an OSGI 
environment and the changes are really minimal.
Also I have no problems with the refactoring of the packages ... 
even if I probably would have built the package tree a little different, but 
that's functionally not an issue and more a matter of taste ;-)

Chris

Am 14.10.19, 03:21 schrieb "Niclas Hedhman" :

As a former OSGi-buff, I think I need to provide a little bit
guidance/translation here

What Julian is talking about is how bundles are constructed according to
OSGi, i.e. more stuff in META-INF/MANIFEST.MF, and there is tooling support
to ensure this is done correctly, such as a Maven plugin, Gradle plugin or
bnd/bndtools for Ant. How to package bundles is in the Core Specification.

What Cesar is talking about is that there is an additional Specification
(all supplementary specifications are known as the Compendium[1]) regarding
how hardware drivers should work in the OSGi framework. This is about being
able to create applications that are unaware of the implementations (such
as PLC4X in our case). The first diagram on
http://glcj.blogspot.com/2016/02/merlot-abstract-driver-model-24.html is
taken from the Compendium. Merlot is then Cesar's implementation of the
OSGi "Device Access Specification" for communication with external devices
(not sure the exact scope).

So, Julian is only talking about cases where "I want to use PLC4X in OSGi"
and that requires proper bundling. Cesar is talking about "I want to talk
to external devices via Device Access Specification" and PLC4X could be an
implementation (or part of one) for that. This would in reality require a
sub-project in PLC4X with additional OSGi dependencies and possibly
(depends on many things) some accommodation (typically classloader-related,
and might be needed for Julian's intentions as well) in the PLC4X core
implementation to make that possible.

Needless to say, Julian's suggestion is rather simple and IMHO should put
the metadata inside the regular jars. MOST Apache projects, Spring projects
and endless others, already do this, even though they have no OSGi focus at
all. Cesar's effort is non-trivial and requires a lot of OSGi-expertise,
possibly more than Karaf community is able to provide.

Further, OpenHAB might be (or already is) of interest to PLC4X. OpenHAB
runs on OSGi and it embraces the "implement to Spec" approach of OSGi. I
assume that it leverages the Device Access Specification, and not only do
those folks have plenty of experience with OSGi, they are very comfortable
in the PLC4X space as well, and have a strong community in Germany. I
suggest that a reach-out to them is initiated and see how they could help.
May they will package PLC4X for OSGi to be used on OpenHAB (I think they
use Karaf, but can't remember for sure) and this community won't need to
maintain the hard parts, only the bundlization.


Hope that Helps
Niclas


[1] Other specifications in the Compendium includes things like; JDBC, Http
servers, Configuration management, Declarative Services and much much more.

On Sun, Oct 13, 2019 at 8:11 PM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hi all,
>
> with the help of the Karaf Community and especially @Christian Schneider I
> was able to finalize a PR which makes PLC4X fully OSGi-compatible:
> https://github.com/apache/plc4x/pull/89
>
> This means that all jars are also valid (and hopefully correct) OSGi
> Bundles.
> Furthermore, I introduced a Karaf Feature fort he S7 driver (which I
> already tested manually and it works).
>
> Despite some pom additions I had to do a slight refactoring and rename
> several packages to avoid package-split situations.
> Thus, please review my PR carefully (although I consider all of those
> minor).
>
> Thanks!
> Julian
>
> PS.: I think we really should take this into 0.5 release
>
>
> Am 08.10.19, 15:26 schrieb "Christofer Dutz" :
>
> I agree ... as far as I understand it it's just some text in the
> MANIFEST that doesn't have impact on other class loading systems.
>
> We should check how we get this additional data in there however.
> There are multiple options and I don't quite know how good all of them 
are.
>
> Chris
>
>
> Am 08.10.19, 10:07 schrieb "Sebastian Rühl"
> :
>
> Hi Julian,
>
> We should put the osgi metadata directly into the modules as they
> „just“ enhance the manifest.
> Additional JARs would only increase the complexity.
>
> Sebastian
>
> > Am 07.10.2019 um 15:58 schrieb Julian Feinauer <
> j.feina...@pragmaticminds.d

Re: PLC4X and OSGi

[Niclas Hedhman]

As a former OSGi-buff, I think I need to provide a little bit
guidance/translation here

What Julian is talking about is how bundles are constructed according to
OSGi, i.e. more stuff in META-INF/MANIFEST.MF, and there is tooling support
to ensure this is done correctly, such as a Maven plugin, Gradle plugin or
bnd/bndtools for Ant. How to package bundles is in the Core Specification.

What Cesar is talking about is that there is an additional Specification
(all supplementary specifications are known as the Compendium[1]) regarding
how hardware drivers should work in the OSGi framework. This is about being
able to create applications that are unaware of the implementations (such
as PLC4X in our case). The first diagram on
http://glcj.blogspot.com/2016/02/merlot-abstract-driver-model-24.html is
taken from the Compendium. Merlot is then Cesar's implementation of the
OSGi "Device Access Specification" for communication with external devices
(not sure the exact scope).

So, Julian is only talking about cases where "I want to use PLC4X in OSGi"
and that requires proper bundling. Cesar is talking about "I want to talk
to external devices via Device Access Specification" and PLC4X could be an
implementation (or part of one) for that. This would in reality require a
sub-project in PLC4X with additional OSGi dependencies and possibly
(depends on many things) some accommodation (typically classloader-related,
and might be needed for Julian's intentions as well) in the PLC4X core
implementation to make that possible.

Needless to say, Julian's suggestion is rather simple and IMHO should put
the metadata inside the regular jars. MOST Apache projects, Spring projects
and endless others, already do this, even though they have no OSGi focus at
all. Cesar's effort is non-trivial and requires a lot of OSGi-expertise,
possibly more than Karaf community is able to provide.

Further, OpenHAB might be (or already is) of interest to PLC4X. OpenHAB
runs on OSGi and it embraces the "implement to Spec" approach of OSGi. I
assume that it leverages the Device Access Specification, and not only do
those folks have plenty of experience with OSGi, they are very comfortable
in the PLC4X space as well, and have a strong community in Germany. I
suggest that a reach-out to them is initiated and see how they could help.
May they will package PLC4X for OSGi to be used on OpenHAB (I think they
use Karaf, but can't remember for sure) and this community won't need to
maintain the hard parts, only the bundlization.


Hope that Helps
Niclas


[1] Other specifications in the Compendium includes things like; JDBC, Http
servers, Configuration management, Declarative Services and much much more.

On Sun, Oct 13, 2019 at 8:11 PM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hi all,
>
> with the help of the Karaf Community and especially @Christian Schneider I
> was able to finalize a PR which makes PLC4X fully OSGi-compatible:
> https://github.com/apache/plc4x/pull/89
>
> This means that all jars are also valid (and hopefully correct) OSGi
> Bundles.
> Furthermore, I introduced a Karaf Feature fort he S7 driver (which I
> already tested manually and it works).
>
> Despite some pom additions I had to do a slight refactoring and rename
> several packages to avoid package-split situations.
> Thus, please review my PR carefully (although I consider all of those
> minor).
>
> Thanks!
> Julian
>
> PS.: I think we really should take this into 0.5 release
>
>
> Am 08.10.19, 15:26 schrieb "Christofer Dutz" :
>
> I agree ... as far as I understand it it's just some text in the
> MANIFEST that doesn't have impact on other class loading systems.
>
> We should check how we get this additional data in there however.
> There are multiple options and I don't quite know how good all of them are.
>
> Chris
>
>
> Am 08.10.19, 10:07 schrieb "Sebastian Rühl"
> :
>
> Hi Julian,
>
> We should put the osgi metadata directly into the modules as they
> „just“ enhance the manifest.
> Additional JARs would only increase the complexity.
>
> Sebastian
>
> > Am 07.10.2019 um 15:58 schrieb Julian Feinauer <
> j.feina...@pragmaticminds.de>:
> >
> > Hi all,
> >
> > as some of you may have notices from Twitter or Slack I am
> currently working on integrating PLC4X into OSGi and especially Karaf.
> > I get a lot of help from the Karaf guys and also Lukasz joined
> the effort to get this done, finally : )
> >
> > For the Drivers, there is one “central” question.
> > Do we want the Driver jars to also be OSGi-Bundles or do we
> prefer separate jars with a 1-1 relationship as OSGi bundles.
> > Other projects, like Netty do it all in one (
> https://netty.io/wiki/new-and-noteworthy-in-4.0.html).
> > In fact, the only difference is a “META-INF/MANIFEST.MF” file
> which is there additionally. So it hurts nobody but helps OSGi users.
>

Re: PLC4X and OSGi

[Julian Feinauer]

Hi all,

with the help of the Karaf Community and especially @Christian Schneider I was 
able to finalize a PR which makes PLC4X fully OSGi-compatible: 
https://github.com/apache/plc4x/pull/89

This means that all jars are also valid (and hopefully correct) OSGi Bundles.
Furthermore, I introduced a Karaf Feature fort he S7 driver (which I already 
tested manually and it works).

Despite some pom additions I had to do a slight refactoring and rename several 
packages to avoid package-split situations.
Thus, please review my PR carefully (although I consider all of those minor).

Thanks!
Julian

PS.: I think we really should take this into 0.5 release


Am 08.10.19, 15:26 schrieb "Christofer Dutz" :

I agree ... as far as I understand it it's just some text in the MANIFEST 
that doesn't have impact on other class loading systems.

We should check how we get this additional data in there however. There are 
multiple options and I don't quite know how good all of them are.

Chris


Am 08.10.19, 10:07 schrieb "Sebastian Rühl" 
:

Hi Julian,

We should put the osgi metadata directly into the modules as they 
„just“ enhance the manifest.
Additional JARs would only increase the complexity.

Sebastian

> Am 07.10.2019 um 15:58 schrieb Julian Feinauer 
:
> 
> Hi all,
> 
> as some of you may have notices from Twitter or Slack I am currently 
working on integrating PLC4X into OSGi and especially Karaf.
> I get a lot of help from the Karaf guys and also Lukasz joined the 
effort to get this done, finally : )
> 
> For the Drivers, there is one “central” question.
> Do we want the Driver jars to also be OSGi-Bundles or do we prefer 
separate jars with a 1-1 relationship as OSGi bundles.
> Other projects, like Netty do it all in one 
(https://netty.io/wiki/new-and-noteworthy-in-4.0.html).
> In fact, the only difference is a “META-INF/MANIFEST.MF” file which 
is there additionally. So it hurts nobody but helps OSGi users.
> 
> What are your thoughts on that?
> 
> Julian

Re: PLC4X and OSGi

[Christofer Dutz]

I agree ... as far as I understand it it's just some text in the MANIFEST that 
doesn't have impact on other class loading systems.

We should check how we get this additional data in there however. There are 
multiple options and I don't quite know how good all of them are.

Chris


Am 08.10.19, 10:07 schrieb "Sebastian Rühl" 
:

Hi Julian,

We should put the osgi metadata directly into the modules as they „just“ 
enhance the manifest.
Additional JARs would only increase the complexity.

Sebastian

> Am 07.10.2019 um 15:58 schrieb Julian Feinauer 
:
> 
> Hi all,
> 
> as some of you may have notices from Twitter or Slack I am currently 
working on integrating PLC4X into OSGi and especially Karaf.
> I get a lot of help from the Karaf guys and also Lukasz joined the effort 
to get this done, finally : )
> 
> For the Drivers, there is one “central” question.
> Do we want the Driver jars to also be OSGi-Bundles or do we prefer 
separate jars with a 1-1 relationship as OSGi bundles.
> Other projects, like Netty do it all in one 
(https://netty.io/wiki/new-and-noteworthy-in-4.0.html).
> In fact, the only difference is a “META-INF/MANIFEST.MF” file which is 
there additionally. So it hurts nobody but helps OSGi users.
> 
> What are your thoughts on that?
> 
> Julian

Re: PLC4X and OSGi

[Sebastian Rühl]

Hi Julian,

We should put the osgi metadata directly into the modules as they „just“ 
enhance the manifest.
Additional JARs would only increase the complexity.

Sebastian

> Am 07.10.2019 um 15:58 schrieb Julian Feinauer :
> 
> Hi all,
> 
> as some of you may have notices from Twitter or Slack I am currently working 
> on integrating PLC4X into OSGi and especially Karaf.
> I get a lot of help from the Karaf guys and also Lukasz joined the effort to 
> get this done, finally : )
> 
> For the Drivers, there is one “central” question.
> Do we want the Driver jars to also be OSGi-Bundles or do we prefer separate 
> jars with a 1-1 relationship as OSGi bundles.
> Other projects, like Netty do it all in one 
> (https://netty.io/wiki/new-and-noteworthy-in-4.0.html).
> In fact, the only difference is a “META-INF/MANIFEST.MF” file which is there 
> additionally. So it hurts nobody but helps OSGi users.
> 
> What are your thoughts on that?
> 
> Julian

Re: PLC4X and OSGi

[Cesar Garcia]

 Hello Julian,

Thanks for the clarification.

Any question is welcome. I will take the time to study the PLC4X project
and be able to contribute.

Regards.

El lun., 7 oct. 2019 a las 10:36, Julian Feinauer (<
j.feina...@pragmaticminds.de>) escribió:

> Hi Cesar,
>
> thanks for the reply and very nice to see you here.
> In fact, we are currently working on something which seems to be similar
> to what I see in your Blog about "Merlot".
>
> I will have a deeper look and come back to you with questions : )
> And regarding your comment, of course we have to be compliant to the
> compendium spec, but generally AFAIR there are two ways to have OSGi-ready
> bundles.
> First is to add the MANIFEST.MF in the original jar then its both, a jar
> and a bundle.
> Or add a "jar" on top (which only consitst of a pom as Module) and
> specifies the Imports / exports for BND to generate the jar with the code
> (and probably some nested jars).
> This is what I was referring to.
> Both approaches should lead to compliant OSGi Bundles, in my
> understanding, or?
>
> Julian
>
> Am 07.10.19, 16:32 schrieb "César García" :
>
> Hello everyone,
>
>  First of all, cordial greetings to the entire PLC4X team, I am very
> happy to see this project working and I hope to collaborate on it.
>
>  Regarding the integration of PLC4X with Karaf (aka OSGI), I think we
> need follow the path specified by the standard, as indicated in the
> Compendium document, Charter 103. I put a short summary in this blog [1].
>
>  Karaf is an excellent tool, and a while ago I developed a
> communications gateway for Apacs, S7 and Modbus with Karaf version 2, all
> running 24/7 in an OIL & Gas plant.
>
>  I will work to make part of that code in PLC4X at some point.
>
>  Regards,
>
>
>  1. Http://glcj.blogspot.com
>  2.
>
>
>
> Enviado desde mi BlackBerry, el dispositivo móvil más seguro
>
>
>   Mensaje original
>
>
>
> De: j.feina...@pragmaticminds.de
> Enviados: 7 de octubre de 2019 10:07
> Para: dev@plc4x.apache.org
> Responder a: dev@plc4x.apache.org
> Asunto: PLC4X and OSGi
>
>
> Hi all,
>
> as some of you may have notices from Twitter or Slack I am currently
> working on integrating PLC4X into OSGi and especially Karaf.
> I get a lot of help from the Karaf guys and also Lukasz joined the
> effort to get this done, finally : )
>
> For the Drivers, there is one “central” question.
> Do we want the Driver jars to also be OSGi-Bundles or do we prefer
> separate jars with a 1-1 relationship as OSGi bundles.
> Other projects, like Netty do it all in one (
> https://netty.io/wiki/new-and-noteworthy-in-4.0.html).
> In fact, the only difference is a “META-INF/MANIFEST.MF” file which is
> there additionally. So it hurts nobody but helps OSGi users.
>
> What are your thoughts on that?
>
> Julian
>
>
>

-- 
*CEOS Automatización, C.A.*
*GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
*PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*

*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
*Ing. César García*
*Cel: 0416-681.03.99*

*Cel: 0414-760.98.95*

*Hotline Técnica SIEMENS: 0800 1005080*

*Email: support.aan.automat...@siemens.com
*

Re: PLC4X and OSGi

[Julian Feinauer]

Hi Cesar,

thanks for the reply and very nice to see you here.
In fact, we are currently working on something which seems to be similar to 
what I see in your Blog about "Merlot".

I will have a deeper look and come back to you with questions : )
And regarding your comment, of course we have to be compliant to the compendium 
spec, but generally AFAIR there are two ways to have OSGi-ready bundles.
First is to add the MANIFEST.MF in the original jar then its both, a jar and a 
bundle.
Or add a "jar" on top (which only consitst of a pom as Module) and specifies 
the Imports / exports for BND to generate the jar with the code (and probably 
some nested jars).
This is what I was referring to.
Both approaches should lead to compliant OSGi Bundles, in my understanding, or?

Julian

Am 07.10.19, 16:32 schrieb "César García" :

Hello everyone,

 First of all, cordial greetings to the entire PLC4X team, I am very happy 
to see this project working and I hope to collaborate on it.

 Regarding the integration of PLC4X with Karaf (aka OSGI), I think we need 
follow the path specified by the standard, as indicated in the Compendium 
document, Charter 103. I put a short summary in this blog [1].

 Karaf is an excellent tool, and a while ago I developed a communications 
gateway for Apacs, S7 and Modbus with Karaf version 2, all running 24/7 in an 
OIL & Gas plant.

 I will work to make part of that code in PLC4X at some point.

 Regards,


 1. Http://glcj.blogspot.com
 2.



Enviado desde mi BlackBerry, el dispositivo móvil más seguro


  Mensaje original  



De: j.feina...@pragmaticminds.de
Enviados: 7 de octubre de 2019 10:07
Para: dev@plc4x.apache.org
Responder a: dev@plc4x.apache.org
Asunto: PLC4X and OSGi


Hi all,

as some of you may have notices from Twitter or Slack I am currently 
working on integrating PLC4X into OSGi and especially Karaf.
I get a lot of help from the Karaf guys and also Lukasz joined the effort 
to get this done, finally : )

For the Drivers, there is one “central” question.
Do we want the Driver jars to also be OSGi-Bundles or do we prefer separate 
jars with a 1-1 relationship as OSGi bundles.
Other projects, like Netty do it all in one 
(https://netty.io/wiki/new-and-noteworthy-in-4.0.html).
In fact, the only difference is a “META-INF/MANIFEST.MF” file which is 
there additionally. So it hurts nobody but helps OSGi users.

What are your thoughts on that?

Julian

Re: PLC4X and OSGi

[César García]

Hello everyone,

 First of all, cordial greetings to the entire PLC4X team, I am very happy to 
see this project working and I hope to collaborate on it.

 Regarding the integration of PLC4X with Karaf (aka OSGI), I think we need 
follow the path specified by the standard, as indicated in the Compendium 
document, Charter 103. I put a short summary in this blog [1].

 Karaf is an excellent tool, and a while ago I developed a communications 
gateway for Apacs, S7 and Modbus with Karaf version 2, all running 24/7 in an 
OIL & Gas plant.

 I will work to make part of that code in PLC4X at some point.

 Regards,


 1. Http://glcj.blogspot.com
 2.



Enviado desde mi BlackBerry, el dispositivo móvil más seguro


  Mensaje original  



De: j.feina...@pragmaticminds.de
Enviados: 7 de octubre de 2019 10:07
Para: dev@plc4x.apache.org
Responder a: dev@plc4x.apache.org
Asunto: PLC4X and OSGi


Hi all,

as some of you may have notices from Twitter or Slack I am currently working on 
integrating PLC4X into OSGi and especially Karaf.
I get a lot of help from the Karaf guys and also Lukasz joined the effort to 
get this done, finally : )

For the Drivers, there is one “central” question.
Do we want the Driver jars to also be OSGi-Bundles or do we prefer separate 
jars with a 1-1 relationship as OSGi bundles.
Other projects, like Netty do it all in one 
(https://netty.io/wiki/new-and-noteworthy-in-4.0.html).
In fact, the only difference is a “META-INF/MANIFEST.MF” file which is there 
additionally. So it hurts nobody but helps OSGi users.

What are your thoughts on that?

Julian

Re: PLC4X IoT Lab VPN Access

[Robert Meissner]

Dear all,

my name is Robert, I joined the CC team in Muenster last week. I did my 
PhD in Physics and had to completely build, control and automatize my 
lab. I programmed a lot in Matlab, a bit in python and a very small bit 
in Java and C++.


Right now I am being fast-trained here in Muenster. At least that is 
what I call it. Dieter had the idea of me helping in PCL4X and since I 
am interested in data science, ML and IoT the Industry 4.0 seems well 
suited to get me going.


Naturally, I will not be able to supply meaningful code or in depth 
hardware understanding at the beginning. Right now my goal is to 
understand what PLC4X is about and how I as a user can get it running 
according to the currently available documentation.


Jannik and I will have a chit chat on the project tomorrow.

I am not sure what the required informations are you need about me but I 
see those as a good starting point. Just ask ahead.


Looking forward to contributing to the project and getting to known you all.

Cheers, Robert

On 09.05.19 12:22, Julian Feinauer wrote:

Hi Robert,

also a warm welcome from my side.
It would be great if you could, after joining the list, just say a few words 
about you and introduce you to the community?

Julian

Am 09.05.19, 11:54 schrieb "Robert Meissner" :

 Dear Sir or Madam,
 
 I would like to test the PLC4X on the IoT lab in Frankfurt. Could you

 please give me access to the hardware?
 
 Best, Robert Meissner
 
 


--
Dr. Robert Meissner | IT-Consultant

codecentric AG | dock14 | Am Mittelhafen 14 | 48155 Münster | Deutschland
mailto:robert.meiss...@codecentric.de mobil: --

www.codecentric.de | blog.codecentric.de | www.meettheexperts.de

Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
Vorstand: Michael Hochgürtel . Ulrich Kühn . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz

Diese E-Mail einschließlich evtl. beigefügter Dateien enthält vertrauliche 
und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige 
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie 
bitte sofort den Absender und löschen Sie diese E-Mail und evtl. beigefügter 
Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder Öffnen evtl. beigefügter 
Dateien sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

Re: PLC4X IoT Lab VPN Access

[Christofer Dutz]

Hi Markus,

I requested access ... will get back to you as soon as I have it.

Chris

Am 09.05.19, 12:09 schrieb "Markus Sommer" :

Hi Chris,

an access to an S7 PLC would also be good for me.

Best regards

Markus

Freundliche Grüße

Markus Sommer
Geschäftsführer

isb innovative software businesses GmbH
Otto-Lilienthal-Strasse 2
D - 88046 Friedrichshafen

Tel.:+49 (0) 7541 3834-14
Mob:  +49 (0) 171 537 8437
Fax: +49 (0) 7541 3834-20
E-Mail: som...@isb-fn.de
Web: www.isb-fn.de 

Geschäftsführer: Markus Sommer, Thomas Zeler
Sitz: Friedrichshafen

Registergericht: Amtsgericht Ulm HRB-Nr. 631624
Important Note: This e-mail and any attachments are confidential, may 
contain trade secrets and may well also be legally privileged or otherwise 
protected from disclosure. If you have received it in error, you are on notice 
of its status. 
Please notify us immediately by reply e-mail and then delete his e-mail and 
any attachment from your system. If you are not the intended recipient please 
understand that you must not copy this e-mail or any attachments or disclose 
the contents to any other person. Thank you.


-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Donnerstag, 9. Mai 2019 11:57
An: dev@plc4x.apache.org
Cc: Robert Meissner 
    Betreff: Re: PLC4X IoT Lab VPN Access

Hi Robert,

welcome to this list, even if you haven't subscribed to it yet, so I am 
adding you as cc.
Please send an email to dev-subscr...@plc4x.apache.org to subscribe to this 
list.

Other than that, I was told you are a new colleague of mine at codecentric 
Münster, so I'll take care of creating an account.

Chris




Am 09.05.19, 11:54 schrieb "Robert Meissner" 
:

Dear Sir or Madam,

I would like to test the PLC4X on the IoT lab in Frankfurt. Could you 
please give me access to the hardware?

Best, Robert Meissner

Re: PLC4X IoT Lab VPN Access

[Julian Feinauer]

Hi Robert,

also a warm welcome from my side.
It would be great if you could, after joining the list, just say a few words 
about you and introduce you to the community?

Julian

Am 09.05.19, 11:54 schrieb "Robert Meissner" :

Dear Sir or Madam,

I would like to test the PLC4X on the IoT lab in Frankfurt. Could you 
please give me access to the hardware?

Best, Robert Meissner

Re: PLC4X IoT Lab VPN Access

[Christofer Dutz]

Hi Robert,

welcome to this list, even if you haven't subscribed to it yet, so I am adding 
you as cc.
Please send an email to dev-subscr...@plc4x.apache.org to subscribe to this 
list.

Other than that, I was told you are a new colleague of mine at codecentric 
Münster, so I'll take care of creating an account.

Chris




Am 09.05.19, 11:54 schrieb "Robert Meissner" :

Dear Sir or Madam,

I would like to test the PLC4X on the IoT lab in Frankfurt. Could you 
please give me access to the hardware?

Best, Robert Meissner

Re: PLC4X-to-OPC-Bridge

[Christofer Dutz]

As soon as we have the OPC-UA support, it might be an idea to create an 
"example" app that does exactly that ... shouldn't be that difficult.

Chris

Am 12.10.18, 18:44 schrieb "Christofer Dutz" :

Yeah,

The SPS IPC drives has two full areas full of those "Solutions", most if 
them are based on Windows CE. So I agree, that an open source solution runable 
on a raspberry might be a cool thing :-)

Chris

Outlook for Android<https://aka.ms/ghei36> herunterladen


From: Pier Fumagalli 
Sent: Friday, October 12, 2018 5:06:40 PM
To: dev@plc4x.apache.org
Cc: timm.von.ber...@hs-esslingen.de
Subject: Re: PLC4X-to-OPC-Bridge

There are a lot of solutions already "bridging" old PLCs with OPC-UA.

For example, I know some folks here at work use the KEPware KEPServer
https://www.kepware.com/en-us/ which roughly does what you described for
Siemens (runs on windows, though, don't get me started).

It sure would be nice to have something OSS, though :-D

Pier



On Fri, Oct 12, 2018 at 1:10 PM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hey all,
>
> I visited the Motec Fair for industrial automation and had a lot of
> interesting discussions in the context of plc4x.
> Timm and his colleagues at the Hochschule Esslingen developed a very
> interesting “I4.0” solution which is currently solely based on OPC UA.
> We then discussed about something which is so obvious that I’m pretty sure
> that anyone else has already thought about.
>
> The idea was to have a “plc4x-opc-ua-bridge”, i.e., a small OPC UA Server
> application which has a configuration that maps between an OPC UA tree and
> plc4x fields.
> This is a very interesting “retro-fit” from my perspective (and I think
> there are several hardware applications for that also) but would be really
> cool in an OSS Stack.
> For the OPC UA Server Eclipse Milo should bring all that’s needed.
>
> What are your thoughts on that?
> Ideally, we could do this together with the Hochschule and some students
> could support with the implementation.
>
> Best
> Julian
>

Re: PLC4X-to-OPC-Bridge

[Christofer Dutz]

Yeah,

The SPS IPC drives has two full areas full of those "Solutions", most if them 
are based on Windows CE. So I agree, that an open source solution runable on a 
raspberry might be a cool thing :-)

Chris

Outlook for Android<https://aka.ms/ghei36> herunterladen


From: Pier Fumagalli 
Sent: Friday, October 12, 2018 5:06:40 PM
To: dev@plc4x.apache.org
Cc: timm.von.ber...@hs-esslingen.de
Subject: Re: PLC4X-to-OPC-Bridge

There are a lot of solutions already "bridging" old PLCs with OPC-UA.

For example, I know some folks here at work use the KEPware KEPServer
https://www.kepware.com/en-us/ which roughly does what you described for
Siemens (runs on windows, though, don't get me started).

It sure would be nice to have something OSS, though :-D

Pier



On Fri, Oct 12, 2018 at 1:10 PM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hey all,
>
> I visited the Motec Fair for industrial automation and had a lot of
> interesting discussions in the context of plc4x.
> Timm and his colleagues at the Hochschule Esslingen developed a very
> interesting “I4.0” solution which is currently solely based on OPC UA.
> We then discussed about something which is so obvious that I’m pretty sure
> that anyone else has already thought about.
>
> The idea was to have a “plc4x-opc-ua-bridge”, i.e., a small OPC UA Server
> application which has a configuration that maps between an OPC UA tree and
> plc4x fields.
> This is a very interesting “retro-fit” from my perspective (and I think
> there are several hardware applications for that also) but would be really
> cool in an OSS Stack.
> For the OPC UA Server Eclipse Milo should bring all that’s needed.
>
> What are your thoughts on that?
> Ideally, we could do this together with the Hochschule and some students
> could support with the implementation.
>
> Best
> Julian
>

Re: PLC4X-to-OPC-Bridge

[Pier Fumagalli]

There are a lot of solutions already "bridging" old PLCs with OPC-UA.

For example, I know some folks here at work use the KEPware KEPServer
https://www.kepware.com/en-us/ which roughly does what you described for
Siemens (runs on windows, though, don't get me started).

It sure would be nice to have something OSS, though :-D

Pier



On Fri, Oct 12, 2018 at 1:10 PM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hey all,
>
> I visited the Motec Fair for industrial automation and had a lot of
> interesting discussions in the context of plc4x.
> Timm and his colleagues at the Hochschule Esslingen developed a very
> interesting “I4.0” solution which is currently solely based on OPC UA.
> We then discussed about something which is so obvious that I’m pretty sure
> that anyone else has already thought about.
>
> The idea was to have a “plc4x-opc-ua-bridge”, i.e., a small OPC UA Server
> application which has a configuration that maps between an OPC UA tree and
> plc4x fields.
> This is a very interesting “retro-fit” from my perspective (and I think
> there are several hardware applications for that also) but would be really
> cool in an OSS Stack.
> For the OPC UA Server Eclipse Milo should bring all that’s needed.
>
> What are your thoughts on that?
> Ideally, we could do this together with the Hochschule and some students
> could support with the implementation.
>
> Best
> Julian
>

Re: PLC4X talk at Open-Source Summit Europe in Edinburgh got accepted

[Christofer Dutz]

Hi All,

While fixing our "Community" menu, I took the liberty to update the page about 
PLC4X conference talks and meetups ...

http://plc4x.apache.org/community/conferences.html

So if you got things not in there, be sure to tell us about them, so we can add 
them.

Chris

Re: PLC4X talk at Open-Source Summit Europe in Edinburgh got accepted

[Julian Feinauer]

Hi Chris,



congratulations! This seems like a cool opportunity to bring things forward.

I'll note it in my calendar but I'm not sure if I'll be able to attend.



Best

Julian



Am 14.08.18, 09:43 schrieb "Christofer Dutz" :



Hi all,



I got an email yesterday evening, that my talk proposal for the Open-Source 
Summit Europe in Edinburgh got accepted.

It’s going to take place October 22-24 at the Edinburgh International 
Conference Centre in Edinburgh, United Kingdom



Revolutionizing the production industry with Apache PLC4X



Would really like to use the chance to meet with anyone going there too.



Chris

Re: Plc4X meeting in Nürtingen

[Christofer Dutz]

+1



Perfect from my side (





Am 10.08.18, 13:23 schrieb "Julian Feinauer" :



* Discussion: Where is PLC4X currently used or will be soon? Feedbacks from 
Industry.

Re: Plc4X meeting in Nürtingen

[Julian Feinauer]

Hey Matthias,



(if you are on the list) I like Chris idea.

Do you like to give us some insight into what you are doing currently and what 
are you planning to do?



So a first draft of the agenda is:

* Chris: History and Wrap-Up of PLC4X

* Chris: Architecture and Deep-Dive PLC4X

* (Hopefully) Matthias Strlijc: Efforts with PLC Communication at University 
Stuttgart

* Julian: "Industrie 4.0" and use cases for PLC4X in the german "Mittelstand"

* Discussion: Where is PLC4X currently used or will be soon? Feedbacks from 
Industry.

* Discussion: How to we proceed in the future, what could be next features & 
milestones



What do you think of this?



Julian



Am 09.08.18, 13:05 schrieb "Christofer Dutz" :



Hi Julian,







I think Matthias Strljic from the University of Stuttgart might want to 
join in and tell us what they are doing there as it seems they are working on a 
similar project and we were discussing options of joining forces off list for 
quite some time, but never managed to actually meet and get started.







As you mentioned, I would like to give you all a short history wrap-up 
about the project itself (from an Apache point of view and from a codecentric 
point of view)







Also I could give all a quick deep-dive into PLC4X, the architecture, how 
to use it and what at we had planned in the near future.







Beyond that I have a huge packet of feedback from the industry from we 
distilled typical use cases.







But the 20th is blocked in my calendar and 10am sounds good for me :-)







Chris











Am 09.08.18, 11:49 schrieb "Julian Feinauer" :







Hey all,







from our doodle we have a clear winner for the date.



We will do the plc4x meeting on Sept. 20.



I suggest that we start at 10 AM.



Our office is located at







pragmatic industries GmbH



Zementwerk 1



72622 Nürtingen







Our entry can only be reached via the spiral stair.







I have an idea for the agenda that I like to share with you and which 
is open for discussion.



For us, the main objektives are







  *   Get in contact with other commiters



  *   Learn about other use cases / problems / solutions with regards 
to IoT / Industrie 4.0



  *   Get a feeling of how everybody thinks plc4x will evolve







We can give you a little insight into two “larger” projects we are 
currently working on (with german machine manufacturerers) and say something 
about how we plan (or perhaps already use) plc4x in these projects and also 
sketch why we do that and what we do with the data acquired.



I would really love if somebody else could also join this and give some 
insights into projects or use cases and perhaps it would also be nice to learn 
a bit of the history of the project why and how it started out at codecentric 
(@chris / Sebastian?).







And the rest of the time should be open to get together and discuss.







What do you think?



Julian

Re: Plc4X meeting in Nürtingen

[Julian Feinauer]

Hey chris,



thats absolutely fine for me.

Who comes first, gets the first coffee : )



Best Julian





Am 09.08.18, 13:19 schrieb "Christofer Dutz" :



Hi Julian,







I just had a look at the train schedules ... seems the trains from 
Stuttgart to Nürtingen usually arrive some time round {hour}:55 ... would 
something 10:15 or 10:30 be ok too? 







Chris











Am 09.08.18, 13:05 schrieb "Christofer Dutz" :







Hi Julian,















I think Matthias Strljic from the University of Stuttgart might want to 
join in and tell us what they are doing there as it seems they are working on a 
similar project and we were discussing options of joining forces off list for 
quite some time, but never managed to actually meet and get started.















As you mentioned, I would like to give you all a short history wrap-up 
about the project itself (from an Apache point of view and from a codecentric 
point of view)















Also I could give all a quick deep-dive into PLC4X, the architecture, 
how to use it and what at we had planned in the near future.















Beyond that I have a huge packet of feedback from the industry from we 
distilled typical use cases.















But the 20th is blocked in my calendar and 10am sounds good for me :-)















Chris























Am 09.08.18, 11:49 schrieb "Julian Feinauer" 
:















Hey all,















from our doodle we have a clear winner for the date.







We will do the plc4x meeting on Sept. 20.







I suggest that we start at 10 AM.







Our office is located at















pragmatic industries GmbH







Zementwerk 1







72622 Nürtingen















Our entry can only be reached via the spiral stair.















I have an idea for the agenda that I like to share with you and 
which is open for discussion.







For us, the main objektives are















  *   Get in contact with other commiters







  *   Learn about other use cases / problems / solutions with 
regards to IoT / Industrie 4.0







  *   Get a feeling of how everybody thinks plc4x will evolve















We can give you a little insight into two “larger” projects we are 
currently working on (with german machine manufacturerers) and say something 
about how we plan (or perhaps already use) plc4x in these projects and also 
sketch why we do that and what we do with the data acquired.







I would really love if somebody else could also join this and give 
some insights into projects or use cases and perhaps it would also be nice to 
learn a bit of the history of the project why and how it started out at 
codecentric (@chris / Sebastian?).















And the rest of the time should be open to get together and discuss.















What do you think?







Julian

Re: Plc4X meeting in Nürtingen

[Christofer Dutz]

Hi Julian,



I just had a look at the train schedules ... seems the trains from Stuttgart to 
Nürtingen usually arrive some time round {hour}:55 ... would something 10:15 or 
10:30 be ok too? 



Chris





Am 09.08.18, 13:05 schrieb "Christofer Dutz" :



Hi Julian,







I think Matthias Strljic from the University of Stuttgart might want to 
join in and tell us what they are doing there as it seems they are working on a 
similar project and we were discussing options of joining forces off list for 
quite some time, but never managed to actually meet and get started.







As you mentioned, I would like to give you all a short history wrap-up 
about the project itself (from an Apache point of view and from a codecentric 
point of view)







Also I could give all a quick deep-dive into PLC4X, the architecture, how 
to use it and what at we had planned in the near future.







Beyond that I have a huge packet of feedback from the industry from we 
distilled typical use cases.







But the 20th is blocked in my calendar and 10am sounds good for me :-)







Chris











Am 09.08.18, 11:49 schrieb "Julian Feinauer" :







Hey all,







from our doodle we have a clear winner for the date.



We will do the plc4x meeting on Sept. 20.



I suggest that we start at 10 AM.



Our office is located at







pragmatic industries GmbH



Zementwerk 1



72622 Nürtingen







Our entry can only be reached via the spiral stair.







I have an idea for the agenda that I like to share with you and which 
is open for discussion.



For us, the main objektives are







  *   Get in contact with other commiters



  *   Learn about other use cases / problems / solutions with regards 
to IoT / Industrie 4.0



  *   Get a feeling of how everybody thinks plc4x will evolve







We can give you a little insight into two “larger” projects we are 
currently working on (with german machine manufacturerers) and say something 
about how we plan (or perhaps already use) plc4x in these projects and also 
sketch why we do that and what we do with the data acquired.



I would really love if somebody else could also join this and give some 
insights into projects or use cases and perhaps it would also be nice to learn 
a bit of the history of the project why and how it started out at codecentric 
(@chris / Sebastian?).







And the rest of the time should be open to get together and discuss.







What do you think?



Julian

Re: Plc4X meeting in Nürtingen

[Christofer Dutz]

Hi Julian,



I think Matthias Strljic from the University of Stuttgart might want to join in 
and tell us what they are doing there as it seems they are working on a similar 
project and we were discussing options of joining forces off list for quite 
some time, but never managed to actually meet and get started.



As you mentioned, I would like to give you all a short history wrap-up about 
the project itself (from an Apache point of view and from a codecentric point 
of view)



Also I could give all a quick deep-dive into PLC4X, the architecture, how to 
use it and what at we had planned in the near future.



Beyond that I have a huge packet of feedback from the industry from we 
distilled typical use cases.



But the 20th is blocked in my calendar and 10am sounds good for me :-)



Chris





Am 09.08.18, 11:49 schrieb "Julian Feinauer" :



Hey all,



from our doodle we have a clear winner for the date.

We will do the plc4x meeting on Sept. 20.

I suggest that we start at 10 AM.

Our office is located at



pragmatic industries GmbH

Zementwerk 1

72622 Nürtingen



Our entry can only be reached via the spiral stair.



I have an idea for the agenda that I like to share with you and which is 
open for discussion.

For us, the main objektives are



  *   Get in contact with other commiters

  *   Learn about other use cases / problems / solutions with regards to 
IoT / Industrie 4.0

  *   Get a feeling of how everybody thinks plc4x will evolve



We can give you a little insight into two “larger” projects we are 
currently working on (with german machine manufacturerers) and say something 
about how we plan (or perhaps already use) plc4x in these projects and also 
sketch why we do that and what we do with the data acquired.

I would really love if somebody else could also join this and give some 
insights into projects or use cases and perhaps it would also be nice to learn 
a bit of the history of the project why and how it started out at codecentric 
(@chris / Sebastian?).



And the rest of the time should be open to get together and discuss.



What do you think?

Julian

Re: Plc4x dev-meeting in Nürtingen

[Julian Feinauer]

Hey everybody,



as the rate of registering users decreases, I think it's reasonable to set a 
Deadline for participation in the Doodle.

If anybody else intents to join our plc4x dev-meeting In Nürtingen, please feel 
free to add you availability dates to the doodle: 
https://doodle.com/poll/9szmww57ennrigux until Wednesday, 8th of August.



Then I would like to close the doodle and to schedule a fixed date to avoid 
anybody being blocked otherwise in the meantime.



I would really love to see some more participants to get in touch with all of 
you : )

Julian



Am 31.07.18, 15:02 schrieb "Julian Feinauer" :



Hey all,



as discussed with Chris we plan to host a small Plc4X meeting in Nürtingen 
(near Stuttgart) at the pragmatic minds office.

I created a doodle for finding a date in September (as in August everybody 
is on holiday).

So if you plan to come please feel free to participate!



Link: https://doodle.com/poll/9szmww57ennrigux



Best

Julian

Re: PLC4X talks this year ...

[Christofer Dutz]

Oh ... forgot one:

04.-06. June 2018: Colone   
Building IoT
https://www.buildingiot.de/veranstaltung-6815-industrial-iot-und-edge-computing-mit-apache-plc4x-und-apache-edgent-%5Bsponsored-talk%5D.html?id=6815

Chris

Am 24.03.18, 17:44 schrieb "Christofer Dutz" :

Hi all,

so I wanted to tell you about two talks on PLC4X I recently got accepted. 
So if you’re interested and able to come … I’d be more than happy to meet you.

05. April 2018: Hamburg
TechCamp Hamburg

https://techcamp.hamburg/events/revolutionizing-industrial-iot-with-apache-plc4x/

13-14th June 2018: Berlin
Apache EU Roadshow
http://www.apachecon.com/euroadshow18/#

But several CFPs still running …

I think it would be a good idea to have this information on our website … 
so if you guys have anything, please feel free to report that.

Chris