Re: AW: So when do we want to meet on Saturday?

[Julian Feinauer]

Why do all of you hate sleep? 樂

On 2024/03/18 09:51:50 Sebastian Rühl wrote:
> 11 sounds good
> 
> - Sebastian
> 
> On 2024/03/18 09:48:04 Christofer Dutz wrote:
> > Hi Lukasz,
> > 
> > Ok … I could have a look and be there some time round 11 AM …
> > 
> > My Toddy shirt is so faded, that you can’t even see it anymore :-(
> > 
> > And with bringing stuff … I’m a bit torn … I could load up my car with all 
> > the stuff I have (Except the big Factory).
> > But then there’s no beer for me at the hackathon.
> > 
> > But on the other side we actually only need a hand full of devices, right?
> > They should fit in a bag.
> > 
> > Chris
> > 
> > 
> > 
> > 
> > Von: Łukasz Dywicki 
> > Datum: Montag, 18. März 2024 um 10:30
> > An: dev@plc4x.apache.org 
> > Betreff: Re: So when do we want to meet on Saturday?
> > If I'm not asleep, I'll land at 09:45. I think it will take me about
> > hour and something to get into downtown.
> > 
> > My other question is - what shall we bring with us, beyond toddy shirts? ;-)
> > 
> > Cheers,
> > Łukasz
> > 
> > On 18.03.2024 09:04, Lukas Ott wrote:
> > > Hi all,
> > >
> > > according to my travel plans.
> > > My train arrives in Frankfurt Main Station at 14:00.
> > > Connection on Sat. 23.03.2024
> > > - from Oerestad st, departure 00:46 Gl. 2 with IC 1401
> > > - to Frankfurt(Main)Hbf, arrival 14:00 Gl. 6 with ICE 75
> > > Verbindung ansehen:
> > > https://www.bahn.de/buchung/start?vbid=c10e14c7-cd2b-4691-90f9-82e504366818
> > >
> > > So I can not join earlier.
> > >
> > > Lukas
> > >
> > >
> > > Am Mo., 18. März 2024 um 08:59 Uhr schrieb Christofer Dutz <
> > > christofer.d...@c-ware.de>:
> > >
> > >> Hi all,
> > >>
> > >> So, when do we want to meet on Saturday?
> > >>
> > >> I would propose something round 13:00 (could also do even earlier)
> > >>
> > >> Chris
> > >>
> > >>
> > >
> > 
> 

AW: Building a PLC4X and IoTDB Historian?

[Julian Feinauer]

I fully agree with that.
If we get something to work in private we could easily go TLP or through the 
Incubator whatever is decided then to do.

Julian

PS.: Do you setup the repo and invite myself?

Von: Christofer Dutz 
Datum: Montag, 28. November 2022 um 13:47
An: dev@plc4x.apache.org 
Betreff: Re: Building a PLC4X and IoTDB Historian?
And if we already agree on a name (I think “Apache Historian” would be a good 
name),
we could even already work on code with that package-name and maven 
coordinates, so we don’t have to change much when coming to Apache?

Chris

From: Christofer Dutz 
Date: Monday, 28. November 2022 at 13:18
To: dev@plc4x.apache.org 
Subject: Re: Building a PLC4X and IoTDB Historian?
Hi Julian,

Indeed, your concerns are valid regarding creating an already abandoned TLP.

In that case, I would opt for a private repo on GitHub which we invite everyone 
willing to help work on it and as soon as we have something workable, we make 
it public as part of a TLP?

This avoids at least the fear of creating a new TLP that’s product doesn’t even 
see the light of day. And as soon as we have something we want to show the 
world, we join Apache?

Would that be a compromise?


Chris

From: Julian Feinauer 
Date: Monday, 28. November 2022 at 13:14
To: dev@plc4x.apache.org 
Subject: AW: Building a PLC4X and IoTDB Historian?
Hey,

as I said.. we could just do it as part of one of the TLPs like PLC4X or IoTDB 
easily or in a private repo as well, for sure.
I just want to avoid to create a TLP which is soon abandoned, that’s my only 
concern.
Regarding all your comments I totally agree and am with you.

Julian

Von: Christofer Dutz 
Datum: Montag, 28. November 2022 um 13:07
An: dev@plc4x.apache.org 
Betreff: Re: Building a PLC4X and IoTDB Historian?
Hi Julian,

well … I would be hesitant to try something like this without the legal shield 
of the ASF … from what I’ve learned in the early days, Siemens and Co. 
continuously threatened to sue me for my work on PLC4X.
The only thing that helped me then, was to say: I am doing everything legally, 
so you’d have trouble succeeding with that and you also can’t sue me but would 
have to sue the ASF and good luck on that not backfiring badly on you publicly.

I know that in the sector of drivers in the past there were several occasions 
where open-source developers were annoyed so much by nuisance law-suites, that 
they gave up.

I also know Historians are silly expensive systems. I haven’t seen one under 
100k€ and the annual fees for certified solutions tend to start at 
100k€/year/production-line … so there’s a lot of money for them to fear losing. 
So yes: I’m too scared to try something like this publicly without a legal 
shield.

We could however work on something like this in a protected repo at GitHub etc. 
and go to TLP as soon as we have something.

Would that be an option?

Chris


From: Julian Feinauer 
Date: Monday, 28. November 2022 at 12:57
To: dev@plc4x.apache.org 
Subject: AW: Building a PLC4X and IoTDB Historian?
Hey Chris,

wrt testing I meant how „sustainable” the community is, that we intend to 
building.
You know the effect pretty well if you ask “How wants to start this” everybody 
is like “me, me, me” and after 2 weeks you stand there alone.
And one important aspect of a TLP for me is that the community is also 
“resilient” and will last “long” (whatever that means).
And this is something I think is hard to guarantee in the current state.

Technically I have no worries, this is something we would get to work rather 
easily, I see no “magics” hidden there.

Julian

Von: Christofer Dutz 
Datum: Montag, 28. November 2022 um 12:48
An: dev@plc4x.apache.org 
Betreff: Re: Building a PLC4X and IoTDB Historian?
Hi Julian,

Well, the problem with starting at one Project as a subproject … We then need 
to make everyone involved or wanting to be involved in the other project to 
become committers in the other.
I wouldn’t have problems with doing it under the hood of IoTDB, personally.

A separate Project would have the benefit of giving the industry an impression 
that this is something built just for them instead of being a side-product of 
something that’s already there (I have given up expecting the Automation 
industry to use any form of common sense ;-) … guess that will be my definition 
of Industry 5.0 … “connected everything + common sense”)

The incubator is intended for teaching the initial community how things work at 
Apache, I guess as we’d be starting with mainly people that have already 
brought projects from outside into the incubator and into TLPs, this teaching 
effort will not exist in this case. Even Justin mentioned that this would 
probably be a case for straight TLP.

Regarding the testing … not sure I understand what you want to test? The idea 
of an open-source historian?
I mean the need exists … I’ve seen it in multiple occasions and our friends 
from IoTDB have confirmed they have built or at least seen IoTDB serve

AW: Building a PLC4X and IoTDB Historian?

[Julian Feinauer]

Hey,

as I said.. we could just do it as part of one of the TLPs like PLC4X or IoTDB 
easily or in a private repo as well, for sure.
I just want to avoid to create a TLP which is soon abandoned, that’s my only 
concern.
Regarding all your comments I totally agree and am with you.

Julian

Von: Christofer Dutz 
Datum: Montag, 28. November 2022 um 13:07
An: dev@plc4x.apache.org 
Betreff: Re: Building a PLC4X and IoTDB Historian?
Hi Julian,

well … I would be hesitant to try something like this without the legal shield 
of the ASF … from what I’ve learned in the early days, Siemens and Co. 
continuously threatened to sue me for my work on PLC4X.
The only thing that helped me then, was to say: I am doing everything legally, 
so you’d have trouble succeeding with that and you also can’t sue me but would 
have to sue the ASF and good luck on that not backfiring badly on you publicly.

I know that in the sector of drivers in the past there were several occasions 
where open-source developers were annoyed so much by nuisance law-suites, that 
they gave up.

I also know Historians are silly expensive systems. I haven’t seen one under 
100k€ and the annual fees for certified solutions tend to start at 
100k€/year/production-line … so there’s a lot of money for them to fear losing. 
So yes: I’m too scared to try something like this publicly without a legal 
shield.

We could however work on something like this in a protected repo at GitHub etc. 
and go to TLP as soon as we have something.

Would that be an option?

Chris


From: Julian Feinauer 
Date: Monday, 28. November 2022 at 12:57
To: dev@plc4x.apache.org 
Subject: AW: Building a PLC4X and IoTDB Historian?
Hey Chris,

wrt testing I meant how „sustainable” the community is, that we intend to 
building.
You know the effect pretty well if you ask “How wants to start this” everybody 
is like “me, me, me” and after 2 weeks you stand there alone.
And one important aspect of a TLP for me is that the community is also 
“resilient” and will last “long” (whatever that means).
And this is something I think is hard to guarantee in the current state.

Technically I have no worries, this is something we would get to work rather 
easily, I see no “magics” hidden there.

Julian

Von: Christofer Dutz 
Datum: Montag, 28. November 2022 um 12:48
An: dev@plc4x.apache.org 
Betreff: Re: Building a PLC4X and IoTDB Historian?
Hi Julian,

Well, the problem with starting at one Project as a subproject … We then need 
to make everyone involved or wanting to be involved in the other project to 
become committers in the other.
I wouldn’t have problems with doing it under the hood of IoTDB, personally.

A separate Project would have the benefit of giving the industry an impression 
that this is something built just for them instead of being a side-product of 
something that’s already there (I have given up expecting the Automation 
industry to use any form of common sense ;-) … guess that will be my definition 
of Industry 5.0 … “connected everything + common sense”)

The incubator is intended for teaching the initial community how things work at 
Apache, I guess as we’d be starting with mainly people that have already 
brought projects from outside into the incubator and into TLPs, this teaching 
effort will not exist in this case. Even Justin mentioned that this would 
probably be a case for straight TLP.

Regarding the testing … not sure I understand what you want to test? The idea 
of an open-source historian?
I mean the need exists … I’ve seen it in multiple occasions and our friends 
from IoTDB have confirmed they have built or at least seen IoTDB serve as such 
a system.
Not 100% sure what you want to try out.

But I agree … we should probably start with an (online) workshop, as this time 
we’d probably be spread out a bit wider geographically, than with our PLC4X 
workshops in the past.

Chris



From: Julian Feinauer 
Date: Monday, 28. November 2022 at 12:37
To: dev@plc4x.apache.org 
Subject: AW: Building a PLC4X and IoTDB Historian?
Hey,

I understand your point and also agree generally.
But I personally dislike the straight to TLP route as this is something I’d 
like to try out first.
And my point with the separate repo (or whatever) was just to make the 
community ready for the Incubator (where a codebase and community normally 
should exist).

But the easiest way in any regard would be to start of as a subproject in an 
existing PMC. This would only require to get another repo and we could start 
(formally no need to even register it as a subproject).
And the repo thing could be done by you alone I think as Chair.

Next steps would then be more of brainstorming and workshoping and building 
something (whatever?).
I think the timing is quite good before Christmas because if its intereting, I 
see myself contributing over the Holidays (better don’t show this mail to my 
wife…).

Best
Julian

Von: Christofer Dutz 
Datum: Montag, 28. November 2022 um 09:27
An: dev@plc4x.apache.org

AW: Building a PLC4X and IoTDB Historian?

[Julian Feinauer]

Hey Chris,

wrt testing I meant how „sustainable” the community is, that we intend to 
building.
You know the effect pretty well if you ask “How wants to start this” everybody 
is like “me, me, me” and after 2 weeks you stand there alone.
And one important aspect of a TLP for me is that the community is also 
“resilient” and will last “long” (whatever that means).
And this is something I think is hard to guarantee in the current state.

Technically I have no worries, this is something we would get to work rather 
easily, I see no “magics” hidden there.

Julian

Von: Christofer Dutz 
Datum: Montag, 28. November 2022 um 12:48
An: dev@plc4x.apache.org 
Betreff: Re: Building a PLC4X and IoTDB Historian?
Hi Julian,

Well, the problem with starting at one Project as a subproject … We then need 
to make everyone involved or wanting to be involved in the other project to 
become committers in the other.
I wouldn’t have problems with doing it under the hood of IoTDB, personally.

A separate Project would have the benefit of giving the industry an impression 
that this is something built just for them instead of being a side-product of 
something that’s already there (I have given up expecting the Automation 
industry to use any form of common sense ;-) … guess that will be my definition 
of Industry 5.0 … “connected everything + common sense”)

The incubator is intended for teaching the initial community how things work at 
Apache, I guess as we’d be starting with mainly people that have already 
brought projects from outside into the incubator and into TLPs, this teaching 
effort will not exist in this case. Even Justin mentioned that this would 
probably be a case for straight TLP.

Regarding the testing … not sure I understand what you want to test? The idea 
of an open-source historian?
I mean the need exists … I’ve seen it in multiple occasions and our friends 
from IoTDB have confirmed they have built or at least seen IoTDB serve as such 
a system.
Not 100% sure what you want to try out.

But I agree … we should probably start with an (online) workshop, as this time 
we’d probably be spread out a bit wider geographically, than with our PLC4X 
workshops in the past.

Chris



From: Julian Feinauer 
Date: Monday, 28. November 2022 at 12:37
To: dev@plc4x.apache.org 
Subject: AW: Building a PLC4X and IoTDB Historian?
Hey,

I understand your point and also agree generally.
But I personally dislike the straight to TLP route as this is something I’d 
like to try out first.
And my point with the separate repo (or whatever) was just to make the 
community ready for the Incubator (where a codebase and community normally 
should exist).

But the easiest way in any regard would be to start of as a subproject in an 
existing PMC. This would only require to get another repo and we could start 
(formally no need to even register it as a subproject).
And the repo thing could be done by you alone I think as Chair.

Next steps would then be more of brainstorming and workshoping and building 
something (whatever?).
I think the timing is quite good before Christmas because if its intereting, I 
see myself contributing over the Holidays (better don’t show this mail to my 
wife…).

Best
Julian

Von: Christofer Dutz 
Datum: Montag, 28. November 2022 um 09:27
An: dev@plc4x.apache.org 
Cc: Tim Mitsch , hoe...@ltsoft.de 

Betreff: Re: Building a PLC4X and IoTDB Historian?
Hi Julian,

happy you like the idea ;-)

We would probably outclass the established ones in point of price ;-)
Right now, I think we should probably set up something that bundles IoTDB and 
PLC4X and then the “code of the project” is the bubble-wrap, that brings the 
two together and then provides an API that is equivalent to existing Historian 
products.
I think the only way we can score points here, is if switching to it is as easy 
as possible and that only works if it’s sort of a drop-in replacement.

Currently also discussing with other board members and the IPMC chair … he at 
least would not see us in the incubator. If there are enough PMC members of 
other projects and Apache Members on board, we could take the straight to TLP 
route.

And I would really like to keep it at Apache and not set up something outside. 
This for multiple reasons:

  *   Protection (The market for the established products is huge and the 
companies behind them are also huge with huge legal departments, I would fear 
the same as I did with PLC4X, when I started it … don’t want to be stuck in 
nuisance lawsuits, just filed for keeping us occupied)
  *   The satement: we want Open-Source to be accepted by the industry and for 
me “Apache” is the form of Open-Source that I admire most. If it’s built up out 
of Apache stuff, it should be an Apache project (If we establish this in a way, 
that the industry notices Apache as a “vendor”, this will benefit many other 
projects)

Chris



From: Julian Feinauer 
Date: Monday, 28. November 2022 at 09:17
To: dev@plc4x.apache.org 
Cc: Tim Mitsch

AW: Building a PLC4X and IoTDB Historian?

[Julian Feinauer]

Hey,

I understand your point and also agree generally.
But I personally dislike the straight to TLP route as this is something I’d 
like to try out first.
And my point with the separate repo (or whatever) was just to make the 
community ready for the Incubator (where a codebase and community normally 
should exist).

But the easiest way in any regard would be to start of as a subproject in an 
existing PMC. This would only require to get another repo and we could start 
(formally no need to even register it as a subproject).
And the repo thing could be done by you alone I think as Chair.

Next steps would then be more of brainstorming and workshoping and building 
something (whatever?).
I think the timing is quite good before Christmas because if its intereting, I 
see myself contributing over the Holidays (better don’t show this mail to my 
wife…).

Best
Julian

Von: Christofer Dutz 
Datum: Montag, 28. November 2022 um 09:27
An: dev@plc4x.apache.org 
Cc: Tim Mitsch , hoe...@ltsoft.de 

Betreff: Re: Building a PLC4X and IoTDB Historian?
Hi Julian,

happy you like the idea ;-)

We would probably outclass the established ones in point of price ;-)
Right now, I think we should probably set up something that bundles IoTDB and 
PLC4X and then the “code of the project” is the bubble-wrap, that brings the 
two together and then provides an API that is equivalent to existing Historian 
products.
I think the only way we can score points here, is if switching to it is as easy 
as possible and that only works if it’s sort of a drop-in replacement.

Currently also discussing with other board members and the IPMC chair … he at 
least would not see us in the incubator. If there are enough PMC members of 
other projects and Apache Members on board, we could take the straight to TLP 
route.

And I would really like to keep it at Apache and not set up something outside. 
This for multiple reasons:

  *   Protection (The market for the established products is huge and the 
companies behind them are also huge with huge legal departments, I would fear 
the same as I did with PLC4X, when I started it … don’t want to be stuck in 
nuisance lawsuits, just filed for keeping us occupied)
  *   The satement: we want Open-Source to be accepted by the industry and for 
me “Apache” is the form of Open-Source that I admire most. If it’s built up out 
of Apache stuff, it should be an Apache project (If we establish this in a way, 
that the industry notices Apache as a “vendor”, this will benefit many other 
projects)

Chris



From: Julian Feinauer 
Date: Monday, 28. November 2022 at 09:17
To: dev@plc4x.apache.org 
Cc: Tim Mitsch , hoe...@ltsoft.de 

Subject: AW: Building a PLC4X and IoTDB Historian?
Hi all,

first of all.. sorry for coming in so late.
I think this is a great idea and there really is a product market fit for such 
a solution.
I think technology wise its not "that complicated" to build such a system, I 
think many of the details that are necessary for a good adoption of such a 
software is in the areas around like documentation, marketing, more marketing, 
even more and even bolder marketing and sales (how to sell an open source 
project??).

But technology wise I really like the idea and I think with the technology one 
has today it is very easy to "outclass" these established systems e.g. in 
performance, efficiency and als user friendliness.
The only thing which might be challenging for the future are things like 
plugins or an extension system to allow users to customize their installation.

Regarding the "separate project" approach I am not 100% certain.
Personally, I would consider starting EITHER as a subproject in an existing PMC 
(PLC4X?) or as a separate undertaking on GitHub or somewhere else and not 
directly go to the Incubator or something.
Because I think we should really find out if there is enough developer interest 
to build and sustain such a system.

But I'm totally in for such a system either way!

Julian

PS.: Also forwarding the email to Björn and Tim who work(ed) a lot with 
historians

Von: Christofer Dutz 
Datum: Montag, 28. November 2022 um 08:56
An: dev@plc4x.apache.org 
Betreff: Re: Building a PLC4X and IoTDB Historian?
Hi Xiangdong,

that’s perfect that some of you folks would be on board. I should probably 
check, if there are enough PLC4X folks on board too … would be a shame if it 
was just me ;-)

And regarding the name … yeah … you are absolutely right: Historian might 
really be the ideal choice … as it instantly explains what it is … A Historian 
from the Apache Software Foundation and probably also no bias towards any 
regional culture.

So (Speaking to my fellow PLC4X folks … who would be on board with this?)


Chris



From: Xiangdong Huang 
Date: Monday, 28. November 2022 at 04:24
To: dev@plc4x.apache.org 
Subject: Re: Building a PLC4X and IoTDB Historian?
> I guess I would sort of also vote for a separate Project. Would however only 
> make s

AW: Building a PLC4X and IoTDB Historian?

[Julian Feinauer]

Hi all,

first of all.. sorry for coming in so late.
I think this is a great idea and there really is a product market fit for such 
a solution.
I think technology wise its not "that complicated" to build such a system, I 
think many of the details that are necessary for a good adoption of such a 
software is in the areas around like documentation, marketing, more marketing, 
even more and even bolder marketing and sales (how to sell an open source 
project??).

But technology wise I really like the idea and I think with the technology one 
has today it is very easy to "outclass" these established systems e.g. in 
performance, efficiency and als user friendliness.
The only thing which might be challenging for the future are things like 
plugins or an extension system to allow users to customize their installation.

Regarding the "separate project" approach I am not 100% certain.
Personally, I would consider starting EITHER as a subproject in an existing PMC 
(PLC4X?) or as a separate undertaking on GitHub or somewhere else and not 
directly go to the Incubator or something.
Because I think we should really find out if there is enough developer interest 
to build and sustain such a system.

But I'm totally in for such a system either way!

Julian

PS.: Also forwarding the email to Björn and Tim who work(ed) a lot with 
historians

Von: Christofer Dutz 
Datum: Montag, 28. November 2022 um 08:56
An: dev@plc4x.apache.org 
Betreff: Re: Building a PLC4X and IoTDB Historian?
Hi Xiangdong,

that’s perfect that some of you folks would be on board. I should probably 
check, if there are enough PLC4X folks on board too … would be a shame if it 
was just me ;-)

And regarding the name … yeah … you are absolutely right: Historian might 
really be the ideal choice … as it instantly explains what it is … A Historian 
from the Apache Software Foundation and probably also no bias towards any 
regional culture.

So (Speaking to my fellow PLC4X folks … who would be on board with this?)


Chris



From: Xiangdong Huang 
Date: Monday, 28. November 2022 at 04:24
To: dev@plc4x.apache.org 
Subject: Re: Building a PLC4X and IoTDB Historian?
> I guess I would sort of also vote for a separate Project. Would however only 
> make sense if some people from both of our projects would join in.

Agree, I think the iotdb developers in Timecho can join.

> And name-wise … one of the names of Historic Historians (Ideally a Greek one) 
> would make it into my top 10 ;-) … sort of like Hudson or Jenkins are 
> “famous” Buttler names ;-)

If we consider famous names (well, there will be culture bias), I'd
like to suggest this one: https://en.wikipedia.org/wiki/Sima_Qian , as
"Records of the Grand Historian" is tooo famous (at least in China).

BTW. naming "Apache Historian" directly may be another option.

Best,
---
Xiangdong Huang
School of Software, Tsinghua University


Christofer Dutz  于2022年11月27日周日 22:56写道：
>
> How about Apache Ephorous? ;-)
>
> https://en.wikipedia.org/wiki/Ephorus
> Ephorus of Cyme (/ˈɛfərəs/; 
> Greek: Ἔφορος ὁ Κυμαῖος, 
> Ephoros ho Kymaios; c. 400 – 330 BC) was an ancient 
> Greek 
> historian known for his universal 
> history.
>
> Chris
>
> From: Christofer Dutz 
> Date: Sunday, 27. November 2022 at 15:28
> To: dev@plc4x.apache.org 
> Subject: Re: Building a PLC4X and IoTDB Historian?
> Hi all,
>
> I guess I would sort of also vote for a separate Project. Would however only 
> make sense if some people from both of our projects would join in.
>
> And name-wise … one of the names of Historic Historians (Ideally a Greek one) 
> would make it into my top 10 ;-) … sort of like Hudson or Jenkins are 
> “famous” Buttler names ;-)
> https://en.wikipedia.org/wiki/List_of_Greek_historiographers
> https://en.wikipedia.org/wiki/List_of_historians
>
> I think anything but a turnkey-ready solution will not be accepted by anyone 
> in the Automation industry.
>
> Chris
>
>
>
>
> From: Xiangdong Huang 
> Date: Sunday, 27. November 2022 at 14:05
> To: dev@plc4x.apache.org 
> Subject: Re: Building a PLC4X and IoTDB Historian?
> If we just provide a solution, or demonstration, then either is ok.
> If we want to provide an "one-box thing" (even without GUI), +1 for a
> new project.
>
> > I don’t even think it would be bad if an entity like Timecho would add 
> > enterprise offerings, because I know, that the industry won’t “buy” 
> > something, if there’s no commercial support or anyone, they can throw money 
> > at, even if it’s free (That might even make them more skeptical).
> Yes, indeed. :D
>
> Best,
> ---
> Xiangdong Huang
>
> Ben Hutcheson  于2022年11月27日周日 18:38写道：
> >
> > Hi,
> >
> > I think it's a great idea.
> >
> > I'd vote for having 

[jira] [Created] (PLC4X-332) Maven Precondition Check fails on M1 Mac

[Julian Feinauer (Jira)]

Julian Feinauer created PLC4X-332:
-

 Summary: Maven Precondition Check fails on M1 Mac
 Key: PLC4X-332
 URL: https://issues.apache.org/jira/browse/PLC4X-332
 Project: Apache PLC4X
  Issue Type: Bug
  Components: Build
Reporter: Julian Feinauer
Assignee: Christofer Dutz


I have libpcap installed (via brew install libpcap) but when I trigger the 
maven build the precondition check fails and reports

 
{code:java}
[INFO] --- groovy-maven-plugin:2.1.1:execute (prerequisite-check) @ 
plc4x-parent ---
Detected OS:   mac
Detected Arch: x86_64Detecting Java version:    17.0.1         OK
Detecting Git version:     2.30.1         OK
Detecting LibPcap version: missing
{code}
My System is a M1 Mac, if that helps using macOS Monterey 12.0.1.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

AW: [DISCUSS] Behaviour of a ConnectionPool?

[Julian Feinauer]

Hi Chris,

excellent question (and worth discussing).
In the java pool there currently is NO automatic reconnection (lazy connection).
I have no backup strategy there (but makes sense to have one although this may 
depend on specific situations).

I currently fail one connection at a time after their specific timeout.

If e.g. you set the timeout for the connection request to 1 second then you 
could easily have one connection failing but the next attempt working.

So I personally would go for sequential failing when their limit is due but I 
think the other alternative is fine as well.

Julian

Von: Christofer Dutz 
Datum: Mittwoch, 19. Januar 2022 um 10:21
An: dev@plc4x.apache.org 
Betreff: [DISCUSS] Behaviour of a ConnectionPool?
Hi all,

I'm currently working on the go connection-pool. Now while in general I would 
assume the functionality of a connection pool to be quite clearly defined, 
there still are some special cases where I want to make sure we consistently 
implement them.

Right now, I'm implementing it so there is only one connection for one given 
connection string ... we can later adjust this. Reasoning here is that in 
general connections to plcs can be considered highly limited so we won't be 
going much over 2 or 3 anyway.

The thing that I'm currently working on are the edge-cases. So, what happens if:


  *   The connection itself fails.
 *   Should the pool try automatically reconnecting?
 *   If yes, should it do it as fast as possible?
 *   Should there be an increasing back-off delay between attempts?
 *   Should there be a maximum number of retries?
 *   What happens to other waiting clients in case of a connection failure?
*   Do all instantly get a "connection-error"?
*   Does the connection get retried for each client in the queue 
independently?

Right now, I would opt for a delay between attempts of 1s at first, the number 
doubling between each attempt and giving up after 3 times and then failing all 
waiting clients simultaneously. But I would make the limits configurable in the 
pool (reconnectInitialDelay, reconnectMaxAttempts, reconnectBackoffStrategy, 
reconnectFailureStrategy).

I think if I run into any other situations where I'm unsure, I'll continue this 
thread.

Chris

Re: [VOTE] Apache PLC4X Build-Tools Code-Generation 1.5.0 RC1

[Julian Feinauer]

+1 (binding)

I checked:
- Signatures and Hashes
- Content of README and RELEASE_NOTES (same strange behavior with README as 
stated in slack, line encodings seem to be different in zip and in svn)
- Files in svn are similar to those in artefact
- Builds on my system via mvn clean install

Thanks for the work Chris!
Julian

On 2021/09/08 18:17:14, Christofer Dutz  wrote: 
>Apache PLC4X Build-Tools Code-Generation 1.5.0 has been staged under [2]
>and it's time to vote on accepting it for release.
> 
>All Maven artifacts are available under [1]. Voting will be open for 72hr.
> 
>A minimum of 3 binding +1 votes and more binding +1 than binding -1
>are required to pass.
> 
>Repository: https://gitbox.apache.org/repos/asf/plc4x-build-tools.git
>Release tag: releases/code-generation/1.5.0
>Hash for the release tag: e0f1569f74ad00af15e4a984efa0cc8ffbae85d1
> 
>Per [3] "Before voting +1 PMC members are required to download
>the signed source code package, compile it as provided, and test
>the resulting executable on their own platform, along with also
>verifying that the package meets the requirements of the ASF policy
>on releases."
> 
>You can achieve the above by following [4].
> 
>[ ]  +1 accept (indicate what you validated - e.g. performed the non-RM 
> items in [4])
>[ ]  -1 reject (explanation required)
> 
> 
>[1] https://repository.apache.org/content/repositories/orgapacheplc4x-1034
>[2] 
> https://dist.apache.org/repos/dist/dev/plc4x/build-tools/code-generation/1.5.0/rc1/
>[3] https://www.apache.org/dev/release/validation.html#approving-a-release
>[4] https://plc4x.apache.org/developers/release/validation.html
> 

Re: [VOTE] Apache PLC4X Build-Tools Site-Skin 1.1.0 RC1

[Julian Feinauer]

+1 (binding)

I checked:
- Signatures and Hashes
- Content of README and RELEASE_NOTES
- Files in svn are similar to those in artefact
- Builds on my system via mvn clean install

Thanks for the work Chris!
Julian

On 2021/09/08 18:40:58, Christofer Dutz  wrote: 
> Apache PLC4X Build-Tools Site-Skink 1.1.0 has been staged under [2]
> and it's time to vote on accepting it for release.
> 
> All Maven artifacts are available under [1]. Voting will be open for 72hr.
> 
> A minimum of 3 binding +1 votes and more binding +1 than binding -1
> are required to pass.
> 
> Repository: https://gitbox.apache.org/repos/asf/plc4x-build-tools.git
> Release tag: site-skin/v1.1.0
> Hash for the release tag: be516d634bcff0c09c714e948fd5958915f47771
> 
> Per [3] "Before voting +1 PMC members are required to download
> the signed source code package, compile it as provided, and test
> the resulting executable on their own platform, along with also
> verifying that the package meets the requirements of the ASF policy
> on releases."
> 
> You can achieve the above by following [4].
> 
> [ ]  +1 accept (indicate what you validated - e.g. performed the non-RM items 
> in [4])
> [ ]  -1 reject (explanation required)
> 
> 
> [1] https://repository.apache.org/content/repositories/orgapacheplc4x-1035
> [2] 
> https://dist.apache.org/repos/dist/dev/plc4x/build-tools/plc4x-site-skin/1.1.0/rc1/
> [3] https://www.apache.org/dev/release/validation.html#approving-a-release
> [4] https://plc4x.apache.org/developers/release/validation.html
> 

Re: RFC / Tooling SPI for drivers / connection state tracking

[Julian Feinauer]

Hi Lukasz,

this is a response not only to this thread but also tot he previous one.

Frankly, I have to admit that we did not an in-depth architecture session when 
creating all those classes so I’m pretty sure there are some things which can 
be done better.

One general topic why I decided to choose classes over instances was that it 
works also for classes which would decide to store state (which would be a 
total upfuck otherwise) AND that we have this „auto injection of properties“ 
which ist he major point.
But those are generally rather week points so I would not object a refactoring 
there at all.

When we worked on the StackConfigurer we did it the way to support what was 
there an das CAN is kind of a new beast we SHOULD see where we need to 
generalize again to make it work.
And I also agree with what you say about reporting connection issues back tot 
he driver. This is a powerful feature that I think makes a lot of sense.

So TL;DR; Go ahead, you got my support. And no, we did not consider every case 
that you bring up now : )

Best
Julian

On 2021/04/14 13:55:36, Łukasz Dywicki 
mailto:l...@code-house.org>> wrote:
> I need an clarification and/or have request for change in our API/SPI.>
> This is closely related to further CAN bus work I plan to do, but not>
> only. I do see that what Ben did few weeks ago with connection tracking>
> is very interesting to move forward.>
> At present we do not offer end user an API to react on connection>
> shutdown or failure. There is no way for him to find that ie. link died>
> and his program needs to take action.>
>
> What I currently also do not understand/lack clearance is how stack>
> configurer interacts with TCP connection. Here what bothers me:>
> - Is there a new stack/decode instance per each active connection?>
> - What is was intended design for driver context and why it is>
> inaccessible via PLC connection interface?>
>
> I suppose that stack per connection is desired case, but if that's true>
> why we pass classes and instead of creating instances in stack configurer?>
> My case here is intended to attach connection state listener but also an>
> message listeners which could help debugging message exchanges. All>
> without tapping into wire.>
>
> A default way we advertise is making PCAP recordings>
> which is fine for development. What I look for is an "logging" interface>
> to be used in production or test environments without necessity to get>
> libpcap involved. This would allow creation of additional tools if needed.>
>
> Best,>
> Łukasz>
>

AW: Source Time of PLC Value?

[Julian Feinauer]

This is not a simple questing and depends on the protocol and device you are 
using. What are you using?

J

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Von: Andreas Vogler 
Datum: Fr., 5. März 2021, 21:04
An: dev@plc4x.apache.org
Betreff: Re: Source Time of PLC Value?
Ah, forgot: and is there a status available? Valid/invalid/good/bad indicator 
of a plc value?

> On 05.03.2021, at 21:02, Andreas Vogler  wrote:
>
> Hi,
>
> How can I get the source time of a PlcValue?
>
> a) from a subscription PlcSubscriptionEvent
> b) from a read request  PlcReadResponse
>
> Best regards,
> Andreas

AW: mspec vs Apache Tika

[Julian Feinauer]

Hey,

well this is no clear proposal but just starting discussing things that I’m 
currently thinking about : )
As Josh wanted to do a bit on C# we had the idea to “rewarm” the old “java plc 
server” idea to play around with.

But I agree, with your plc4x protocol would be ready we could also use that as 
layer between. Then we would get even non-POSIX compatibility. I’m totally open 
here : )

Julian

Von: Christofer Dutz 
Datum: Dienstag, 23. Februar 2021 um 11:17
An: dev@plc4x.apache.org 
Betreff: AW: mspec vs Apache Tika
Hi Julian,

isn't the implementing a native API exactly what we are doing right now?

Also I think I don't quite seem to understand what you are actually proposing 
... we use mspec to generate the code for model serializer and parser in a 
given language ... that's a part the user actually never has contact with.

The only part where I'm currently working on a different usage for mspec is 
where I'm tryging to replace what we had planned with Thrift and then gRPC with 
a custom PLC4X internal protocol. The main reason is that for none of the other 
approaches there's actually C support. So this might be something that I'll 
only use to communicate with C PLC4X agents.

But I don't think you are referring to that.

Chris


-Ursprüngliche Nachricht-
Von: Julian Feinauer 
Gesendet: Dienstag, 23. Februar 2021 10:56
An: dev@plc4x.apache.org
Betreff: AW: mspec vs Apache Tika

Hey,

I totally agree with you that the "one api" is something language specific 
(that's e.g. the way we currently do it in Apache IoTDB).

So in the case of a "Language Server" there would be the need to write a 
"native" API for every language because the default would be something like (in 
pseudocode)

Request {
item[]
}

That would be send via RPC. But the "API" for the user should of course be 
language specific and look like what you describe here.

But as I said, I don't see this as an either / or discussion but rather as a 
way to bring most features "easily" and "quickly" to all other protocols at a 
cost (the cost is the need to run a Java based Server somewhere).
This does not conflict with the current ("native") drivers that are really 
"embeddebale" in such a project and often the better solution.

WDYT?

Julian

Von: Christofer Dutz 
Datum: Dienstag, 23. Februar 2021 um 10:17
An: dev@plc4x.apache.org 
Betreff: AW: mspec vs Apache Tika
Hi Julian,

having worked on the PLC4J, PLC4Go, PLC4C, PLC4Net and PLC4Cpp now, I think I 
can add more insights to this discussion.

The main problem is the availability of concepts in different languages. Right 
now for example we couldn't do the cool chaining of stuff we use in the PLC4J 
API.

PlcReadRequest readRequest = 
plcConnection.readRequestBuilder().addItem("item1", "lalala").addItem("item2", 
"hurz").build()

Go simply doesn't support this. Here this has to look differently:

rrb := connection.ReadRequestBuilder()
rrb.AddItem("item1", "lalala")
rrb.AddItem("item2", "hurz")
readRequest, err := rrb.Build()

And in C again none of these would work that way (But I woulnd't let C block 
anything)

This "one api" approach would probably only work, if we reduced the API on the 
simplest possible variant, throwing overboard the language specific benefits.

- Builder Pattern in Java (And this is just one cool example)
- Service discovery in Java
    - Go Routines and channels in Go
- Size of everything in C

Just my input to the discussion.


Chris




-Ursprüngliche Nachricht-
Von: Julian Feinauer 
Gesendet: Dienstag, 23. Februar 2021 09:00
An: dev@plc4x.apache.org
Betreff: mspec vs Apache Tika

Hi friends!

I recently had some discussions about PLC4X for different types of protocols 
and languages (esp. C#).

So I wanted to "rewarm" an old discussion (and also point it out for newer 
community members.

As you all know we have this m x n problem (where m being the protocols we 
support, while n is the languages we support). Some time ago we decided to go 
the way of code generation to tackle this. Chris made incredible efforts and 
came up with mspec which is, I would say today, the new core of PLC4X and one 
of its biggest assets as its just so. cool.

Another alternative we discussed a bit was the idea that Apache Tika [1] went. 
Basically to have one interface and behind this interface we integrate all kind 
of tools to get the job done. E.g. also third party libs, probably also 
adapters for proprietay stuff and so on.
One concrete example for this is the OPC UA protocol. The current 
Implementation done by Matthias is basically an adapter to Eclipse Milo (or a 
differently named project of Kevin) which only does "mediation" between the 
full OPC UA Stack and the PLC4X Frontend.
The other way 

AW: mspec vs Apache Tika

[Julian Feinauer]

Hey,

I totally agree with you that the “one api” is something language specific 
(that’s e.g. the way we currently do it in Apache IoTDB).

So in the case of a “Language Server” there would be the need to write a 
“native” API for every language because the default would be something like (in 
pseudocode)

Request {
item[]
}

That would be send via RPC. But the “API” for the user should of course be 
language specific and look like what you describe here.

But as I said, I don’t see this as an either / or discussion but rather as a 
way to bring most features “easily” and “quickly” to all other protocols at a 
cost (the cost is the need to run a Java based Server somewhere).
This does not conflict with the current (“native”) drivers that are really 
“embeddebale” in such a project and often the better solution.

WDYT?

Julian

Von: Christofer Dutz 
Datum: Dienstag, 23. Februar 2021 um 10:17
An: dev@plc4x.apache.org 
Betreff: AW: mspec vs Apache Tika
Hi Julian,

having worked on the PLC4J, PLC4Go, PLC4C, PLC4Net and PLC4Cpp now, I think I 
can add more insights to this discussion.

The main problem is the availability of concepts in different languages. Right 
now for example we couldn't do the cool chaining of stuff we use in the PLC4J 
API.

PlcReadRequest readRequest = 
plcConnection.readRequestBuilder().addItem("item1", "lalala").addItem("item2", 
"hurz").build()

Go simply doesn't support this. Here this has to look differently:

rrb := connection.ReadRequestBuilder()
rrb.AddItem("item1", "lalala")
rrb.AddItem("item2", "hurz")
readRequest, err := rrb.Build()

And in C again none of these would work that way (But I woulnd't let C block 
anything)

This "one api" approach would probably only work, if we reduced the API on the 
simplest possible variant, throwing overboard the language specific benefits.

- Builder Pattern in Java (And this is just one cool example)
- Service discovery in Java
- Go Routines and channels in Go
- Size of everything in C

Just my input to the discussion.


Chris




-Ursprüngliche Nachricht-
Von: Julian Feinauer 
Gesendet: Dienstag, 23. Februar 2021 09:00
An: dev@plc4x.apache.org
Betreff: mspec vs Apache Tika

Hi friends!

I recently had some discussions about PLC4X for different types of protocols 
and languages (esp. C#).

So I wanted to "rewarm" an old discussion (and also point it out for newer 
community members.

As you all know we have this m x n problem (where m being the protocols we 
support, while n is the languages we support). Some time ago we decided to go 
the way of code generation to tackle this. Chris made incredible efforts and 
came up with mspec which is, I would say today, the new core of PLC4X and one 
of its biggest assets as its just so. cool.

Another alternative we discussed a bit was the idea that Apache Tika [1] went. 
Basically to have one interface and behind this interface we integrate all kind 
of tools to get the job done. E.g. also third party libs, probably also 
adapters for proprietay stuff and so on.
One concrete example for this is the OPC UA protocol. The current 
Implementation done by Matthias is basically an adapter to Eclipse Milo (or a 
differently named project of Kevin) which only does "mediation" between the 
full OPC UA Stack and the PLC4X Frontend.
The other way is currently engineered mostly by Ben who works on integrating 
OPC UA via mspec that it is a PLC4X "native" driver.

There already were some discussions what would be better and I'm totally 
unemotional about it but I also see value in the "adapter" approach. For me, 
PLC4Xs main benefit is the unified API we can provide that makes it awesome.

And, the discussion doesn't need to be an either or it can also be both. I 
agree that a well written native driver always beats "external" ones. But from 
a time and material perspective it is usually easier (as a first step) to 
integrate existing work into the project to get it out there. And we can also 
mark that on the homepage or elsewhere as "native" or "non-native".

And regarding our n-Languages Problem there already was the idea to come up 
with a Java based Web Server and other language Bindings e.g. via Thrift, 
Protobuf or gRPC (which where thrown out due to the build complexity they 
brought). But If someone (looking at you Josh) is willing to experiment a bit 
with it, I would definetly be in : )

What are your thoughs on these matters?

Best
Julian

[1] https://tika.apache.org/

AW: DF1 protocol ...cant find documentation

[Julian Feinauer]

Hey,

as far as I see your code looks good Gaurav, lets try it and then report : )

Best
Julian

Von: Gaurav P 
Datum: Samstag, 20. Februar 2021 um 19:14
An: dev@plc4x.apache.org 
Betreff: Re: DF1 protocol ...cant find documentation
Thanks Chris ... its working ...i added both entries in maven on Monday
when I have access to the hardware (AB PLC/5 30) I will test and report
back

But for the test case, I am was thinking

   1. Write a value to register like N71
   2. Read from register  and confirm value  N71

Kindly review the code below  for testing
  try (PlcConnection plcConnection = new
PlcDriverManager().getConnection("df1:serial:///ttySC1")) {

 *   //I want write to register N71 , is below code ok ?*
PlcReadRequest request = plcConnection.readRequestBuilder()
.addItem("N71", "5:INTEGER")
.build();

PlcReadResponse response = request.execute().get(100,
TimeUnit.SECONDS);

// Check if this connection support reading of data.
if (!plcConnection.getMetadata().canRead()) {
System.out.println("This connection doesn't support
reading.");
return "This connection doesn't support reading.";
}else {
// TODO: get the actual read bytes from the response
System.out.println(response);
System.out.println("Response code was " +
response.getResponseCode("erster"));

System.out.println("Response I got was" +
response.getAllIntegers("N71"));
  *  //I want Read to register N71 , is below code ok ?*
return response.getAllIntegers("N71").iterator().next()+"";
}




On Sat, Feb 20, 2021 at 10:52 PM Gaurav P  wrote:

> Hi Chirs ,
> Thanks I had suspected the same thing
>
> I was able to make it work via adding an apache repository  (after I
> changed the maven snippet you  had given  from  pluginRepositories to
> repositories ) and DF1 guide
> >
> (wip)
>
> 
>   
> apache-snapshots
> https://repository.apache.org/content/repositories/snapshots
> 
>   false
> 
> 
>   true
> 
>   
> 
>
>
> On Sat, Feb 20, 2021 at 10:07 PM Christofer Dutz <
> christofer.d...@c-ware.de> wrote:
>
>> Hi,
>>
>> the solution was quite simple:
>>
>> First off all, we don't release stuff in the Sandbox. So there's no 0.8.0
>> version.
>> Secondly our SNAPSHOTS aren't available from Maven-Central. You need to
>> add the Apache SNAPSHOT repo to your project.
>>
>> In order to do this, please add this to your pom.
>>
>>   
>>   
>> 
>>   apache-snapshots
>>   https://repository.apache.org/content/repositories/snapshots
>> 
>>   
>> false
>>   
>>   
>> true
>>   
>> 
>>   
>>
>>   
>>   
>> 
>>   apache-snapshots
>>   https://repository.apache.org/content/repositories/snapshots
>> 
>>   
>> false
>>   
>>   
>> true
>>   
>> 
>>   
>>
>> That should help.
>>
>> Chris
>>
>>
>> -Ursprüngliche Nachricht-
>> Von: Christofer Dutz 
>> Gesendet: Samstag, 20. Februar 2021 10:13
>> An: dev@plc4x.apache.org
>> Betreff: Re: DF1 protocol ...cant find documentation
>>
>> I'll have a look why this is not available.
>>
>> Holen Sie sich Outlook für Android
>>
>> 
>> From: Gaurav P 
>> Sent: Saturday, February 20, 2021 6:19:38 AM
>> To: dev@plc4x.apache.org 
>> Subject: Re: DF1 protocol ...cant find documentation
>>
>> Hi Chris ,
>>
>> I also  tried with 0.8 , but no luck
>>
>>   org.apache.plc4x.sandbox
>>   test-java-df1-driver
>>   0.8.0
>> 
>>
>>
>> On Sat, Feb 20, 2021 at 7:15 AM Gaurav P  wrote:
>>
>> > Hi Chris ,
>> >
>> > I am not able to maven dependency for df1 driver Cannot resolve
>> > org.apache.plc4x.sandbox:test-java-df1-driver:0.9.0-SNAPSHOT
>> >
>> > is it not hosted in maven central?
>> >
>> > On Fri, Feb 19, 2021 at 6:58 PM Christofer Dutz
>> > 
>> > wrote:
>> >
>> >> Hi Gaurav,
>> >>
>> >> you haven't added a dependency to the driver, but to the protocol
>> >> specificaton instead.
>> >> This is something we use internally to generate the driver code in
>> >> various languages. You need to add a dependency to
>> >>
>> >> 
>> >> org.apache.plc4x.sandbox
>> >> test-java-df1-driver
>> >> 0.9.0-SNAPSHOT 
>> >>
>> >> Chris
>> >>
>> >> -Ursprüngliche Nachricht-
>> >> Von: Gaurav P 
>> >> Gesendet: Freitag, 19. Februar 2021 14:20
>> >> An: dev@plc4x.apache.org
>> >> Betreff: Re: DF1 protocol ...cant find documentation
>> >>
>> >> Thanks Chris , Steven
>> >>
>> >> I tried the code below but I am getting following error *error Unable
>> >> to find driver for protocol 'df1'*
>> >>
>> >> I checked in maven DF1 is added ...what can be the issue ?
>> >>
>> >>
>> >>
>> >> 

mspec vs Apache Tika

[Julian Feinauer]

Hi friends!

I recently had some discussions about PLC4X for different types of protocols 
and languages (esp. C#).

So I wanted to “rewarm” an old discussion (and also point it out for newer 
community members.

As you all know we have this m x n problem (where m being the protocols we 
support, while n is the languages we support). Some time ago we decided to go 
the way of code generation to tackle this. Chris made incredible efforts and 
came up with mspec which is, I would say today, the new core of PLC4X and one 
of its biggest assets as its just so… cool.

Another alternative we discussed a bit was the idea that Apache Tika [1] went. 
Basically to have one interface and behind this interface we integrate all kind 
of tools to get the job done. E.g. also third party libs, probably also 
adapters for proprietay stuff and so on.
One concrete example for this is the OPC UA protocol. The current 
Implementation done by Matthias is basically an adapter to Eclipse Milo (or a 
differently named project of Kevin) which only does “mediation” between the 
full OPC UA Stack and the PLC4X Frontend.
The other way is currently engineered mostly by Ben who works on integrating 
OPC UA via mspec that it is a PLC4X “native” driver.

There already were some discussions what would be better and I’m totally 
unemotional about it but I also see value in the “adapter” approach. For me, 
PLC4Xs main benefit is the unified API we can provide that makes it awesome.

And, the discussion doesn’t need to be an either or it can also be both. I 
agree that a well written native driver always beats “external” ones. But from 
a time and material perspective it is usually easier (as a first step) to 
integrate existing work into the project to get it out there. And we can also 
mark that on the homepage or elsewhere as “native” or “non-native”.

And regarding our n-Languages Problem there already was the idea to come up 
with a Java based Web Server and other language Bindings e.g. via Thrift, 
Protobuf or gRPC (which where thrown out due to the build complexity they 
brought). But If someone (looking at you Josh) is willing to experiment a bit 
with it, I would definetly be in : )

What are your thoughs on these matters?

Best
Julian

[1] https://tika.apache.org/

Re: DF1 protocol ...cant find documentation

[Julian Feinauer]

Hi folks, that sunds really cool!
In fact, we did the implementation oft he DF1 protocoll just to end up noting 
that we have a PLC using some variant oft he DF1 protocl (its sometimes called 
AB-ETH).
So we never did a real test on DF1 AFAIR so your help is appreciated!

Julian

Am 19.02.21, 10:51 schrieb "Stephen Snow" :

Hello,
I have been lurking this list off and on for some time. I am a solution
provider in Ontario Canada. With respect to the DF1 protocol, and
specifically testing it further, I would be more than willing, and able
too, to setup a SLC500 say with a 10 slot rack and assorted IO in order
to do some testing. I have a solid background in PLC programming,
actually systems integration and solution providing that spans many
years and industries, and I program in various computer languages too,
Java in particular in recent years.
So if someone would like to get the DF1 driver tweaked and tested, I
can help.

Regards,
Stephen
On Fri, 2021-02-19 at 07:36 +, Christofer Dutz wrote:
> Hi Gaurav,
> 
> also from my side, welcome :-)
> 
> I think the DF1 was one of the first tob e created with the new code-
> generation framework. 
> However due to lack of hardware to test on, it's still located in the
> "Sandbox" and got a "test" prefix on it.
> 
> 
> org.apache.plc4x.sandbox
> test-java-df1-driver
> 0.9.0-SNAPSHOT
> 
> 
> Also I think it supports all features that were needed by the folks
> that implemented it, but probably not much more than that. 
> 
> So please test it. If you need it to do more and you've got a device
> you can test it with, we'd be happy to help you with that.
> 
> Chris
> 
> 
> -Ursprüngliche Nachricht-
> Von: Lukas Ott  
> Gesendet: Freitag, 19. Februar 2021 07:33
> An: dev@plc4x.apache.org
> Betreff: Re: DF1 protocol ...cant find documentation
> 
> Hi Gaurav,
> 
> Welcome to the list :-),
> 
> Yes it really is supported. Here you ll find some more details:
> https://plc4x.apache.org/developers/code-gen/protocol/df1.html
> 
> The best way to get started you can find here:
> https://plc4x.apache.org/users/getting-started/plc4j.html
> to understand more read here:
> https://plc4x.apache.org/users/getting-started/general-concepts.html
> 
> For release 0.6 you ll find the java code here:
> 
https://github.com/apache/plc4x/blob/rel/0.6/protocols/df1/src/main/java/org/apache/plc4x/protocol/df1/Df1Protocol.java
> 
> 
> Example code you ll find here:
> https://github.com/apache/plc4x/tree/develop/plc4j/examples
> 
> Currently not sure if we ported DF1 to release 0.8
> 
> Cheers,
> otluk
> 
> Am Fr., 19. Feb. 2021 um 03:41 Uhr schrieb Gaurav P :
> 
> > Hi Team ,
> > I am new to PLC4x , trying to integrate with DF1 but cant find any 
> > documentation 
> > https://plc4x.apache.org/users/protocols/df1.html
> > 
> > is it really supported? if yes where can I get documentation  and
> > an 
> > example code
> > --
> > B*e * the *Ch*ange
> > 

AW: AW: Test on plc4x-pool2

[Julian Feinauer]

Hi,

first, thanks for reporting.
As discussed in Slack we try to fix the issue and I think I already pushed a 
fix.

So just for the list to notice : )

Julian

Von: Stefano Bossi 
Datum: Freitag, 27. November 2020 um 09:26
An: dev@plc4x.apache.org 
Betreff: Re: AW: Test on plc4x-pool2
ok,

l'et's wait Julian, who is probably doing his father work :-D

Anyway, Netty is really hard to fine tune!

Regards,
S.

On 27/11/2020 08:52, Christofer Dutz wrote:

Hi Stefano,



I really wonder how often I will end up looking up this stupid 
java.lang.UnsupportedOperationException …

I have to admit that for me this is one of the most annoying things with Netty 
:-/



But seeing the actual error is coming from the pool, I guess Julian should 
probably help you with this, I doubt this is something I can help with.



Chris



Von: Stefano Bossi 

Datum: Donnerstag, 26. November 2020 um 23:16

An: dev@plc4x.apache.org 


Betreff: Test on plc4x-pool2

Hi Julian,



I have tried to integrate in my code the new pool library you wrote but without 
success, I have probably did something wrong.



I am started trying to work with the HelloPlc4x





PlcDriverManager manager = new PlcDriverManager();



PlcDriverManager cached = new CachedDriverManager(connectionString, 
() -> {



try {



return manager.getConnection(connectionString);



} catch (PlcConnectionException e) {



e.printStackTrace();



}



return null;



});



PlcConnection plcConnection = 
cached.getConnection(connectionString);



// Check if this connection support reading of data.



if (!plcConnection.getMetadata().canRead()) {



logger.error("This connection doesn't support reading.");



return;



}











integrate When the code reach the line plcConnection.getMetadata().canRead()



 integrate an exception is rised:







bash-3.2$  /Users/fox/.jenv/versions/openjdk64-13.0.2/bin/java 
-agentlib:jdwp=transport=dt_socket,server=n,suspend=y,address=localhost:51806 
-ea -Dfile.encoding=UTF-8 
@/var/folders/p1/lb5grfpn3tncxdtrptqq9fw4gp/T/cp_dkqa6x1i5h7yfdha7mxc6sn5h.argfile
 it.fox.datapicker.HelloPlc4x



2020-11-26 23:09:30,677 main DEBUG Apache Log4j Core 2.14.0 initializing 
configuration 
XmlConfiguration[location=/Users/fox/Documents/workspace/2020-06-30 - 
HelloPlc4x/bin/main/log4j2.xml]



2020-11-26 23:09:30,684 main DEBUG Installed 1 script engine



Warning: Nashorn engine is planned to be removed from a future JDK release



2020-11-26 23:09:30,885 main DEBUG Oracle Nashorn version: 13.0.2, language: 
ECMAScript, threading: Not Thread Safe, compile: true, names: [nashorn, 
Nashorn, js, JS, JavaScript, javascript, ECMAScript, ecmascript], factory 
class: jdk.nashorn.api.scripting.NashornScriptEngineFactory



2020-11-26 23:09:30,885 main DEBUG PluginManager 'Core' found 122 plugins



2020-11-26 23:09:30,885 main DEBUG PluginManager 'Level' found 0 plugins



2020-11-26 23:09:30,889 main DEBUG PluginManager 'Lookup' found 16 plugins



2020-11-26 23:09:30,890 main DEBUG Building Plugin[name=layout, 
class=org.apache.logging.log4j.core.layout.PatternLayout].



2020-11-26 23:09:30,899 main DEBUG PluginManager 'TypeConverter' found 26 
plugins



2020-11-26 23:09:30,911 main DEBUG PatternLayout$Builder(pattern="[%-5level] 
%d{HH:mm:ss.SSS} %logger{36}.%M() - %msg%n", PatternSelector=null, 
Configuration(/Users/fox/Documents/workspace/2020-06-30 - 
HelloPlc4x/bin/main/log4j2.xml), Replace=null, charset="null", 
alwaysWriteExceptions="null", disableAnsi="null", noConsoleNoAnsi="null", 
header="null", footer="null")



2020-11-26 23:09:30,911 main DEBUG PluginManager 'Converter' found 44 plugins



2020-11-26 23:09:30,912 main DEBUG Building Plugin[name=appender, 
class=org.apache.logging.log4j.core.appender.ConsoleAppender].



2020-11-26 23:09:30,917 main DEBUG ConsoleAppender$Builder(target="SYSTEM_OUT", 
follow="null", direct="null", bufferedIo="null", bufferSize="null", 
immediateFlush="null", ignoreExceptions="null", PatternLayout([%-5level] 
%d{HH:mm:ss.SSS} %logger{36}.%M() - %msg%n), name="Console", 
Configuration(/Users/fox/Documents/workspace/2020-06-30 - 
HelloPlc4x/bin/main/log4j2.xml), Filter=null, ={})



2020-11-26 23:09:30,919 main DEBUG Starting OutputStreamManager 
SYSTEM_OUT.false.false



2020-11-26 23:09:30,919 main DEBUG Building Plugin[name=appenders, 
class=org.apache.logging.log4j.core.config.AppendersPlugin].



2020-11-26 23:09:30,922 main DEBUG createAppenders(={Console})



2020-11-26 23:09:30,922 main DEBUG Building Plugin[name=AppenderRef, 
class=org.apache.logging.log4j.core.config.AppenderRef].



2020-11-26 23:09:30,926 main DEBUG createAppenderRef(ref="Console", 
level="TRACE", 

Re: Please welcome Ben as our newest PMC member

[Julian Feinauer]

Hi Ben,

congratulations and very well deserved.
Although I am pretty inactive at the moment I really appreciate your work and 
you already brought so many results tot he project : )

Best
Julian

Am 09.11.20, 05:15 schrieb "Cesar Garcia" :

1+

Welcome

El dom., 8 nov. 2020 a las 11:33, Christofer Dutz (<
christofer.d...@c-ware.de>) escribió:

> Hi all,
>
> I would like to officially welcome Ben as our newest addition to the
> Apache PLC4X PMC.
> Ben has recently been doing an outstanding job all over the project,
> greatly helping the project move forward.
> I am honored, that he accepted our invitation.
>
> Happy to have you, Ben
>
> Chris
>


-- 
*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: +58 414-760.98.95*

*Hotline Técnica SIEMENS: 0800 1005080*

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

Re: [DISCUSS] Start having a regular PLC4X community call?

[Julian Feinauer]

Why not. I guess I would participate if I'm available and it surely would be 
fun : )

J

Am 29.10.20, 01:52 schrieb "Ben Hutcheson" :

Hi,

I'm in favour of a call every so often.

+1 for announcing it to the wider community.

Ben

On Wed, Oct 28, 2020 at 12:17 PM Lukas Ott  wrote:

> Hi Chris,
>
> I personally would really appreciate such a meeting. As it helps to form a
> community and also increases transparency on the current stuff we are
> working on.
>
> Just because of time and effort in my humble opinion quarterly would be
> sufficient as most of the active developers are chatting on Slack anyways
> on our current topics.
>
> + We could announce these meetings via Twitter as well to make it visible
> and more transparent for others to be able to join and get in contact with
> us as well
>
> so +1 for starting such a thing.
>
> Lukas
>
> Am Mi., 28. Okt. 2020 um 17:06 Uhr schrieb Christofer Dutz <
> christofer.d...@c-ware.de>:
>
> > Hi all,
> >
> > yesterdays the Mahout project started announcing to start having regular
> > community calls where anyone can join in.
> > These calls would sort of be used for chatting with the community and
> > perhaps exchanging where people need help, and generally exchanging
> > information.
> >
> > I know finding a time where everyone can participate will be impossible,
> I
> > would suggest doing it in the evening (Germany) so the folks in the
> > US/Canada can participate (morning)
> > Right now we definitely have more people actively working on plc4x if we
> > go West (EU and US) than going east (EU and Australia) … and this way we
> > can have a beer while at it ;-)
> >
> > I would propose a Wednesday 19:00 CET … and perhaps doing it every
> > (first/second/third/fourth) Wednesday of the month … (I’d prefer first 
or
> > second)
> >
> > What do you think? Should we start such a thing?
> >
> > Chris
> >
> >
> >
>

Re: Doing some read-tests with S7

[Julian Feinauer]

Hey Chris,

Sadly I do not find the time to push that forward at the moment, sorry : /

Julian

Am 26.10.20, 20:07 schrieb "Christofer Dutz" :

Hi folks

Guess the "String(10)[3]" issue is going to be a tricky one :-(
Perhaps it's easier for me to also implement the automatic splitting of 
items that are itself too big for one packet.

I was hoping on the proposed generic optimizer, but I guess I better get 
working on this myself and implement some basic rules manually.

    Or @Julian Feinauer ... any progress/plans for this?

Chris


Am 25.10.20, 23:42 schrieb "Christofer Dutz" :

Ok ... so I fixed most of the issues.

So-far the problems I need to address are the following:

- When using "BOOL[]" we have to read a bit-string (byte, word, dword) 
instead and filter out the bits that are not asked for.
- When reading "STRING(x)[]" (limited strings), we have to split up the 
request into multiple items as the typical array notation doesn't work.
- When reading bit-strings the order of the bits looks the wrong way 
around
- When reading bit-string arrays, I would like to concatenate the 
values to one bit-string instead of returning lists of lists

Chris




Am 25.10.20, 21:59 schrieb "Christofer Dutz" 
:

Hi all,

in order to have some good tests for the S7 protocol, I defined a 
lot of variables in one of the data-blocks of one of my S7 devices.
I then created a little test program that should simply use this to 
read all sorts of types of elements.
With these tests I found some things:


  *   In general all Bit-String operations, when reading arrays, 
produce lists of lists … I think it would be cooler if for bit-strings they 
would return one large List
  *   STRING handling seems to be messed up again
  *   When reading a BOOL array, it seems the S7 only returns the 
first bit (I would have expected it to send up to 8 bits in one byte and after 
that to add more bytes, but it’s always just one and that always just contains 
the first bit) -> We need to translate BOOL-array reads into bit-string 
operations which return partial lists.
  *   Reading of DATE_AND_TIME arrays seems to be messed up as only 
the first item is correct and the succeeding elements are always “null”
  *   Reading of CHAR values seems messed up

I’ll be working on addressing this asap

Chris

AW: Kotlin and PLC4x

[Julian Feinauer]

Hi folks,

I think it should be sufficient to check thread safety and implement the api in 
kotlin as Java generated code should work just fine, right?

But as Chris said, any help is appreciated : )

Julian

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Von: Christofer Dutz 
Datum: Fr., 23. Okt. 2020, 09:14
An: Patrick Boisclair , dev@plc4x.apache.org
Betreff: Re: Kotlin and PLC4x
Hi Patrick,

Well there shouldn’t be anything preventing you from starting this.

I think we have code generation working in Java, C and Go (Not sure how far the 
Python folks are with this).
So I think we have a reasonably base of very different languages.

Of course, every new language shows us new things that need a little tweaking 
(Right now I’m adjusting the C code generation after adding support for Enums 
with “string” basetype), but in general there shouldn’t be much preventing a 
PLC4K.

You want to start working on this? I definitely don’t have the time for that. 
But I could help mentoring you to do it on your own.

Chris



Von: Patrick Boisclair 
Gesendet: Freitag, 23. Oktober 2020 03:49
An: dev@plc4x.apache.org 
Betreff: Kotlin and PLC4x


Hello,



I would like to know if there is any "Contraindication" to use Kotlin with 
PLC4X.



Any "unexpexted" behavior known ?

Coroutines working well ?



Thank you very much for your response and especially on your fantastic work !



Best regards

Patrick Boisclair
Analyste - Programmeur senior / Senior Analyst Programmer

[cid:image001.gif@01D6A91C.E19F4BE0]


462, rue des Forges, Trois-Rivières (Québec) G9A 2H5 CANADA
noovelia.com

"Veuillez noter ma nouvelle adresse courriel. / Please note my new email 
address."

Re: [RESULT] [VOTE] Apache PLC4X Build-Tools Code-Generation 1.3.0 RC1

[Julian Feinauer]

Hi,

minor correction, you had a typo and it is 3 binding +1s.
Just for the record, that the vote passed and is valid : )

J

Am 14.09.20, 08:45 schrieb "Christofer Dutz" :

Hi all,

so the vote passes with:

1 binding +1 and 1 non-binding +1

I'll finish the release steps and update the main repo to the new released 
version.

Chris

Am 12.09.20, 21:38 schrieb "Julian Feinauer" :

Hi,

sorry, a bit late to the party but my vote is

+1 (binding)

- Downloaded all artefacts
- checked signatures and hash code
- unzipped archive
- verified existence and content of LINCENSE, NOTICE, README and 
RELEASE_NOTES
- build from sources via "mvn clean install" under OS X 10.14.6

Julian

Am 09.09.20, 20:21 schrieb "Dominik Riemer" :

Hi,

+1 (non-binding)

[OK] Download all staged artifacts under the url specified in the 
release vote email
[OK] Verify the signature is correct and references an Apache Email 
address
[OK] Verify the SHA512 hashes
[OK] Unzip the archive
[OK] Verify the existence of LICENSE, NOTICE, README and 
RELEASE_NOTES files in the extracted source bundle.
[OK] Verify the content of LICENSE, NOTICE, README and 
RELEASE_NOTES files in the extracted source bundle.
[OK] Can build from source via "mvn clean install" under Windows 10 
(Java 8) and W10 WSL2 (Java 11)

Looks good!

Dominik

-Original Message-
From: Lukas Ott  
Sent: Wednesday, September 9, 2020 6:34 PM
To: dev@plc4x.apache.org
Subject: Re: [VOTE] Apache PLC4X Build-Tools Code-Generation 1.3.0 
RC1

+1 (binding)

[OK] Download all staged artifacts under the url specified in the 
release vote email [OK] Verify the signature is correct and references an 
Apache Email address [OK] Verify the SHA512 hashes [OK] Unzip the archive [OK] 
Verify the existence of LICENSE, NOTICE, README and RELEASE_NOTES files in the 
extracted source bundle.
[OK] Verify the content of LICENSE, NOTICE, README and 
RELEASE_NOTES files in the extracted source bundle.

Can build from Source via "mvn install"
OS: Ubuntu 20.04.1 LTS

No further remarks.

Am Mi., 9. Sept. 2020 um 18:10 Uhr schrieb Christofer Dutz <
christofer.d...@c-ware.de>:

> +1 (binding)
>
> Chris
>
> [OK] Download all staged artifacts under the url specified in the 
> release vote email [OK] Verify the signature is correct and 
references 
> an Apache Email address [OK] Verify the SHA512 hashes [OK] Unzip 
the 
> archive [OK] Verify the existence of LICENSE, NOTICE, README and 
> RELEASE_NOTES files in the extracted source bundle.
> [OK] Verify the content of LICENSE, NOTICE, README and 
RELEASE_NOTES 
> files in the extracted source bundle.
> [OK] Run RAT externally to ensure there are no surprises.
> [OK] Search for SNAPSHOT references
> [OK] Search for Copyright references, and if they are in headers, 
make 
> sure these files containing them are mentioned in the LICENSE 
file.
> [MINOR] Build the project according to the Maven defaults
>
> Remarks:
>
> The script "mvnw" seems to not be executable.
>
>
>
> Am 08.09.20, 13:46 schrieb "Christofer Dutz" 
:
>
>Apache PLC4X Build-Tools Code-Generation 1.3.0 has been 
staged 
> under [2]
>and it’s time to vote on accepting it for release.
>
>All Maven artifacts are available under [1]. Voting will 
be 
> open for 72hr.
>
>A minimum of 3 binding +1 votes and more binding +1 than 
binding -1
>are required to pass.
>
>Repository:
> https://gitbox.apache.org/repos/asf/plc4x-build-tools.git
>Release tag: releases/code-generation/1.3.0
>Hash for the release tag: 
> 7f2fab83d6cd0ccba41b8622d6abe4f8995748bd
>
>Per [3] "Before voting +1 PMC members are required to 
download
>the signed source code package, compile it as provided, 
and test
>the resulting executable on their own platform, along with 
also
>verifying that t

Re: [VOTE] Apache PLC4X Build-Tools Code-Generation 1.3.0 RC1

[Julian Feinauer]

Hi,

sorry, a bit late to the party but my vote is

+1 (binding)

- Downloaded all artefacts
- checked signatures and hash code
- unzipped archive
- verified existence and content of LINCENSE, NOTICE, README and RELEASE_NOTES
- build from sources via "mvn clean install" under OS X 10.14.6

Julian

Am 09.09.20, 20:21 schrieb "Dominik Riemer" :

Hi,

+1 (non-binding)

[OK] Download all staged artifacts under the url specified in the release 
vote email
[OK] Verify the signature is correct and references an Apache Email address
[OK] Verify the SHA512 hashes
[OK] Unzip the archive
[OK] Verify the existence of LICENSE, NOTICE, README and RELEASE_NOTES 
files in the extracted source bundle.
[OK] Verify the content of LICENSE, NOTICE, README and RELEASE_NOTES files 
in the extracted source bundle.
[OK] Can build from source via "mvn clean install" under Windows 10 (Java 
8) and W10 WSL2 (Java 11)

Looks good!

Dominik

-Original Message-
From: Lukas Ott  
Sent: Wednesday, September 9, 2020 6:34 PM
To: dev@plc4x.apache.org
Subject: Re: [VOTE] Apache PLC4X Build-Tools Code-Generation 1.3.0 RC1

+1 (binding)

[OK] Download all staged artifacts under the url specified in the release 
vote email [OK] Verify the signature is correct and references an Apache Email 
address [OK] Verify the SHA512 hashes [OK] Unzip the archive [OK] Verify the 
existence of LICENSE, NOTICE, README and RELEASE_NOTES files in the extracted 
source bundle.
[OK] Verify the content of LICENSE, NOTICE, README and RELEASE_NOTES files 
in the extracted source bundle.

Can build from Source via "mvn install"
OS: Ubuntu 20.04.1 LTS

No further remarks.

Am Mi., 9. Sept. 2020 um 18:10 Uhr schrieb Christofer Dutz <
christofer.d...@c-ware.de>:

> +1 (binding)
>
> Chris
>
> [OK] Download all staged artifacts under the url specified in the 
> release vote email [OK] Verify the signature is correct and references 
> an Apache Email address [OK] Verify the SHA512 hashes [OK] Unzip the 
> archive [OK] Verify the existence of LICENSE, NOTICE, README and 
> RELEASE_NOTES files in the extracted source bundle.
> [OK] Verify the content of LICENSE, NOTICE, README and RELEASE_NOTES 
> files in the extracted source bundle.
> [OK] Run RAT externally to ensure there are no surprises.
> [OK] Search for SNAPSHOT references
> [OK] Search for Copyright references, and if they are in headers, make 
> sure these files containing them are mentioned in the LICENSE file.
> [MINOR] Build the project according to the Maven defaults
>
> Remarks:
>
> The script "mvnw" seems to not be executable.
>
>
>
> Am 08.09.20, 13:46 schrieb "Christofer Dutz" :
>
>Apache PLC4X Build-Tools Code-Generation 1.3.0 has been staged 
> under [2]
>and it’s time to vote on accepting it for release.
>
>All Maven artifacts are available under [1]. Voting will be 
> open for 72hr.
>
>A minimum of 3 binding +1 votes and more binding +1 than binding -1
>are required to pass.
>
>Repository:
> https://gitbox.apache.org/repos/asf/plc4x-build-tools.git
>Release tag: releases/code-generation/1.3.0
>Hash for the release tag: 
> 7f2fab83d6cd0ccba41b8622d6abe4f8995748bd
>
>Per [3] "Before voting +1 PMC members are required to download
>the signed source code package, compile it as provided, and test
>the resulting executable on their own platform, along with also
>verifying that the package meets the requirements of the ASF policy
>on releases."
>
>You can achieve the above by following [4].
>
>[ ]  +1 accept (indicate what you validated - e.g. performed 
> the non-RM items in [4])
>[ ]  -1 reject (explanation required)
>
>
> [1]
> https://repository.apache.org/content/repositories/orgapacheplc4x-1029
> [2]
> 
https://dist.apache.org/repos/dist/dev/plc4x/build-tools/code-generation/1.3.0/rc1/
> [3]
> https://www.apache.org/dev/release/validation.html#approving-a-release
> [4] https://plc4x.apache.org/developers/release/validation.html
>
>
>
>
>

FW: [DISCUSS] Add Wrappers to PLC4X Project

[Julian Feinauer]

Forwarding it tot he list (i think chris simply hit reply...) : )

Am 11.09.20, 09:27 schrieb "Christofer Dutz" :

And my only concern about native-drivers is that I want to prevent us from 
becoming lazy.

I know we had the EIP and Modbus drivers by using external libs and that 
wasn't very pleasant (At least not for me)
We were relying on libs we had no control over. It got us to the point 
where we could support these protocols,
But looking back it cost us (mainly me) way more time in supporting them 
than it would have cost me if we had implemented the parts we needed.

So I would generally say:
- If it’s a technical problem preventing us from implementing it fully in 
plc4x (CAN, Profibus, ...) then this is the way to go ...
- If it's a protocol problem (want to avoid implementing the protocol in 
order to save time) ... then we should put it in the sandbox

Chris



Am 11.09.20, 09:01 schrieb "Julian Feinauer" :

Hi folks,

thanks for all the replies and the controversy in here shows that ist 
good to discuss the matter, indeed : )

I like Cesars way of putting it (which is pretty close to mine) that 
PLC4X is a unified API.
This is the Killer thing here.

And what we currently do and mostly did was "PLC4X native". Because we 
get all these nice benefits of controlling everyhting and doing code for all 
languages.

But, we may end up in situations where there i seither no possiblity to 
do a native implementation (profinet, profibus, CAN, ...) where we need some 
kind of special hardware where I would like to still have it in the project.
This would mean that there is some special setup instruction how to 
setup the "native" part and then there is some glue code (could easily again be 
plattform independent) like a PLC4X generic driver (@Christofer Dutz a bit like 
what we reasoned about with PLCnext) which "binds" them together.

As we are really small on man-power and maintainers I think it is a 
good and reasonable way to go with a "integrate whats already there" instead of 
a "try to find the single silver bullet and die in beatuy".

So my reasoning at the moment is to place something like this wrapper 
as native code in a generic section somewhere in the "PLC4X native" part, that 
it can be integrated. But then host install instructions fort he "agent" or 
proprietary part somewhere else in an "integration" part (not like integration 
into other downstream systems but integration of other communication layers).

Is this something which sounds acceptable for the community are there 
feelings against it?

Julian

Am 11.09.20, 02:20 schrieb "Ben Hutcheson" :

Hi,

I agree with Chris, having new drivers in a contrib section would 
be a good
idea to make it clear that it hasn't been developed as much as other
protocols or that there is some constraint excluding it from the 
main
driver section. The worst that could happen is that it gets culled
eventually because it isn't maintained and no one else shows 
interest.

What protocol is it?

I'm assuming you've already set your mind on developing it, but 
something
to consider. Is anybody else likely to want to use it to warrant 
spending
time on it? Is there a spec that is published? Does the 
manufacturer change
the protocol often? Can they provide information on the protocol?

Kind Regards

Ben

On Thu, Sep 10, 2020 at 5:03 PM Łukasz Dywicki 
 wrote:

> It is pretty good question to answer. Given that Julien proposal
> includes native binary I can also add that socketcan stuff I am 
working
> on .. is bound only to Linux due to native dependency in JavaCAN 
transport.
>
> From my perspective I can tell that it really depends on budget 
you
> have. Our CAN journey started from CAN over Ethernet (UDP) and 
ended up
> in dark corner which some of you could observe over past weeks. 
We had
> to do it, because that was customer requirement (skip vendor 
gateway).
> If you don't have such requirement then I would say there is 
quite weak
> case to invest in it.
> My point comes from observations. I wrote couple of MSpec files 
and it
> was indeed fun. Both profinet and lldp took me a little bit, but
> structures I got structures and I was able to parse real traffic. 
What I
> skipped in my earlier attempts was implementation of driver api 
where
> you actually start implementing necessary conversation logic. 
Having a
   

FW: [DISCUSS] Add Wrappers to PLC4X Project

[Julian Feinauer]

Forwarding it tot he list (i think chris simply hit reply...) : )

Am 11.09.20, 09:22 schrieb "Christofer Dutz" :

Hi Julian,

I think a "native-drivers" might be a good approach. But if they should 
live outside of the sandbox, I would have to insist that who adds something 
like that, to make sure the build works on all platforms.
And with "work" I mean: "Not break the rest". My greatest nightmare would 
be having to maintain a build that's highly platform dependent.

And we would need documentation for each of them. How to set them up, how 
to build them. 
I know documentation hasn't been what we are best at, but especially for 
these types of drivers they would be essential.

I do agree that some drivers require special hardware transports. CAN and 
Profibus would fit for this. However Profinet and the protocol you are talking 
about is not really a transport problem, but a protocol problem. 
I know we could pretty directly implement Profinet with mspec ... it's 
probably just a pretty big protocol - specification-wise. Or does that PLC you 
want to talk to use anything else than Ethernet as transport? 
You mentioned DCOM ... so I wouldn't call it a technical problem.

We could do one thing: 
- Add them in a native drivers section first
- Migrate them into the drivers section by porting them to mspec as far as 
possible later

How about that?

Chris





Am 11.09.20, 09:01 schrieb "Julian Feinauer" :

Hi folks,

thanks for all the replies and the controversy in here shows that ist 
good to discuss the matter, indeed : )

I like Cesars way of putting it (which is pretty close to mine) that 
PLC4X is a unified API.
This is the Killer thing here.

And what we currently do and mostly did was "PLC4X native". Because we 
get all these nice benefits of controlling everyhting and doing code for all 
languages.

But, we may end up in situations where there i seither no possiblity to 
do a native implementation (profinet, profibus, CAN, ...) where we need some 
kind of special hardware where I would like to still have it in the project.
This would mean that there is some special setup instruction how to 
setup the "native" part and then there is some glue code (could easily again be 
plattform independent) like a PLC4X generic driver (@Christofer Dutz a bit like 
what we reasoned about with PLCnext) which "binds" them together.

As we are really small on man-power and maintainers I think it is a 
good and reasonable way to go with a "integrate whats already there" instead of 
a "try to find the single silver bullet and die in beatuy".

So my reasoning at the moment is to place something like this wrapper 
as native code in a generic section somewhere in the "PLC4X native" part, that 
it can be integrated. But then host install instructions fort he "agent" or 
proprietary part somewhere else in an "integration" part (not like integration 
into other downstream systems but integration of other communication layers).

Is this something which sounds acceptable for the community are there 
feelings against it?

Julian

Am 11.09.20, 02:20 schrieb "Ben Hutcheson" :

Hi,

I agree with Chris, having new drivers in a contrib section would 
be a good
idea to make it clear that it hasn't been developed as much as other
protocols or that there is some constraint excluding it from the 
main
driver section. The worst that could happen is that it gets culled
eventually because it isn't maintained and no one else shows 
interest.

What protocol is it?

I'm assuming you've already set your mind on developing it, but 
something
to consider. Is anybody else likely to want to use it to warrant 
spending
time on it? Is there a spec that is published? Does the 
manufacturer change
the protocol often? Can they provide information on the protocol?

Kind Regards

Ben

On Thu, Sep 10, 2020 at 5:03 PM Łukasz Dywicki 
 wrote:

> It is pretty good question to answer. Given that Julien proposal
> includes native binary I can also add that socketcan stuff I am 
working
> on .. is bound only to Linux due to native dependency in JavaCAN 
transport.
>
> From my perspective I can tell that it really depends on budget 
you
> have. Our CAN journey started from CAN over Ethernet (UDP) and 
ended up
> in dark corner which some of you could observe over past weeks. 
We had
> to do it, because that was customer requirement (skip vendor 
gateway).
> If you don't have s

Re: [DISCUSS] Add Wrappers to PLC4X Project

[Julian Feinauer]

ith a shared
> > API."
> >
> > If your client allows you to publish the project in PLC4X, it is a very
> > important opportunity for this project to increase and share knowledge.
> >
> > As for DCOM, it is a reality that will be with us no less than 20 years
> in
> > the future due to its installed base [1]. We need to live with the
> Windows
> > and Linux environment for years to come, and that is a reality.
> >
> > As for solutions with DCOM we have [2], in my case which allows using
> > OPC-DA from Java, as in [3].
> >
> > My grain of sand
> >
> > 1.
> >
> 
https://opcfoundation.org/wp-content/uploads/2018/02/ARC-Report-OPC-Installed-Base-Insights.pdf
> > 2. http://j-interop.org/
> > 3. https://www.eclipse.org/eclipsescada/
> >
> > El mié., 9 sept. 2020 a las 8:31, Otto Fowler ( >)
> > escribió:
> >
> >>  I think this should be hosted and more importantly _maintained_ 
outside
> >> the project.  If you want to add reference to it to the project site or
> >> something, that would be something to talk about.
> >>
> >>
> >> On September 9, 2020 at 08:28:12, Stefano Bossi (
> stefano.bo...@gmail.com)
> >> wrote:
> >>
> >> Hi,
> >>
> >> personally I think this kind of approach will limit the usability of 
the
> >> library in a very narrow subset of uses do to the windows operating
> system
> >> dependency.
> >>
> >> I think you guys put a lot of effort in portability and small footprint
> of
> >> the library and this is a great think in the industrial world where
> >> typically there are small PC or embedded one.
> >>
> >> Using the library in a small PC like a Rasperry Pi with a linux distro
> and
> >> a lot of attention for the security and hardening of the environment I
> >> think is a pro for any industrial project
> >> (e.g. Selinux, Firewall, minimal service installation, OSCAP security
> >> profile compliance, etc ).
> >>
> >> Evaluating the effort required in reversing the DCOM protocol is
> something
> >> to be taken into consideration before integrating a windows library in
> the
> >> plc4x code.
> >>
> >> Maybe this could be a transient solution or a way to validate a full
> open
> >> source solution.
> >>
> >> Regards,
> >> Stefano
> >>
> >>
> >>
> >> On 09/09/2020 13:35, Christofer Dutz wrote:
> >>
> >> Hi Julian,
> >>
> >>
> >>
> >> the issue I see here is that it will make the build more complex (the
> >> part using the wrapper will only be runnable on windows and not sure
> >> if the license of the wrapped DLLs would allow including them).
> >>
> >>
> >> It will also eliminate the ability to auto-port the driver to other
> >> languages.
> >>
> >>
> >> And, beyond that, it would limit these drivers to only work on a
> >> subset of platforms (Aka ... a Java Driver that only works on Windows
> >> Systems with installed subsystem for the PLC)
> >>
> >>
> >>
> >> I wouldn't want to make such a solution a first class citizen (aka
> >> live in plc4j/drivers) ... we could sort of start providing some sort
    > >> of "plc4j/contrib" modules, if we have to go this path.
> >>
> >>
> >>
> >> But personally I would opt for at least having a look at the path I
> >> described in slack:
> >>
> >>
> >>
> >> - Use the native libs and build an application that does the basic
> >> interaction with the Windows DLLs
> >>
> >> - Use WireShark to record the communication
> >>
> >> - Have a look if it's not just a very small subset of DCOM that is used
> >>
> >>
> >>
> >> Perhaps it would sort of be like using some mspec types with a lot of
> >> const fields to allow communication without any intermediate DLL 
> >> this would make it runnable on all target platforms and auto-portable
&g

[DISCUSS] Add Wrappers to PLC4X Project

[Julian Feinauer]

Hi all,

wanted to bring it tot he list as we already had a discussion in the slack 
channel.
We have a project where we consider integrating machinery in our system.
The machinery offers an SDK for communication which is windows only and based 
on DCOM.
Thus, the integration would be a wrapper around the SDK with „only“ a PLC4X 
„frontend“.

Personally, I consider this viable as our aim ist o have one interface for 
„everything“.
Nonetheless, I also agree with everybody saying that its not as nice as having 
the complete stack in our hands.

What do others think, should this be part oft he PLC4X project or should we 
just do it separately.
Personally idk that much but think it would be nice to have maximum support in 
plc4x, if possible.

Best
Julian

Re: [DISCUSS] Start releasing build tools?

[Julian Feinauer]

Hi,

+1 from my side.
Andi f we still find something.. we just do another release.

J

Am 07.09.20, 09:14 schrieb "Christofer Dutz" :

Hi all,

I know I started this thread multiple times, but this time I really think 
we should do it. I know that perhaps after we release we will be needing some 
changes, but I guess we can’t change that.
So I would like to stage a RC soon, so we can start a new release on 0.8.0 
very soon. There are a lot of bugfixes in there which I would like to see 
people using and not having to use the 0.7.0.


Chris

Re: [MODBUS][DISCUSS] Improving handling of datatypes ...

[Julian Feinauer]

Hi,

agree with your suggestion!
Although we have to be careful to not mix it up with specific implementations 
of datatypes in some drivers.

Julian

Am 02.09.20, 15:21 schrieb "Christofer Dutz" :

Hi all,

today I was at a customer’s site and used the Modbus driver to get data. 
This generally worked fine.
The thing however I found a little complicated, was that the PLC seemed to 
offer all values as 32Bit Floating point values.
So in order to correctly read them, I had to read an array of two 
consecutive shorts and then manually convert them into a float.

I bet we can do this better.

So I thought … how about we use the same 
https://en.wikipedia.org/wiki/IEC_61131-3 datatypes we are already using in 
other drivers and for example if you write:

holding-register:1:REAL

it would automatically use modbus to read an array of two shorts and to 
internally convert these to one REAL/float.

What do you think? I think we could probably do this in most drivers.

Chris

Re: How does the code generation process for different languages currently work?

[Julian Feinauer]

Hi Matthias!

first, welcome tot he list!
I think Chris recorded a Video of an introduction to the Python Initiative, 
right @cd...@apache.org or @Lukas Ott?

This could be a good starting point.

Best
Julian

Am 30.08.20, 21:50 schrieb "Matthias Richter" :

Hi all, 

my name is Matthias and I'm studying mechanical engineering at the 
University of Stuttgart. 
Currently, I'm doing my bachelor thesis at the "Institute for Control 
Engineering of Machine Tools and Manufacturing Units". 

The task of my thesis is to define and implement a model for the automatic 
generation of protocol drivers in different programming languages for PLC4X, 
using template-based code generation. 
My supervisor Matthias Strljic recommended to introduce myself to this 
mailing list to get in contact with the developers of the project and maybe get 
some help with questions that might arise during my thesis. 

In the repository and the documentation, I have seen that there are already 
different parts of the drivers which are automatically generated.
Nevertheless, I have some difficulties getting a deeper understanding of 
the current driver generation process. 
I would be pleased if someone would be willing to give me a rough overview 
of the current status of the project and the approaches used for the driver 
generation.

Regards Mattias

Re: Leaking nioEventLoopGroup threads

[Julian Feinauer]

Also thanks to you, Stefano, indeed for the nice community work you do!

Julian

Von: Stefano Bossi 
Datum: Dienstag, 25. August 2020 um 20:20
An: , Adam Rossi , Julian Feinauer 

Betreff: Re: Leaking nioEventLoopGroup threads

Yupiii !!!

good news !!!

Regards,
S.

On 25/08/2020 15:45, Adam Rossi wrote:

Juilan,



My apologies - your fix did indeed work. The issue is that

PooledPlcDriverManager does not seem to be calling the close method on the

connection. Switching back to PlcDriverManager from PooledPlcDriverManager

results in your new log comments showing up in the log, and more

importantly no more leaks of the nioEventLoopGroup threads. I have tested

the code in a loop for an hour or so and it is working perfectly.



The PooledPlcDriverManager seems to intercept the close method on the

plcConnection (lines 125 - 130):



if ("close".equals(method.getName())) {

LOGGER.debug("close called on {}", plcConnection);

proxyInvalidated.set(true);

keyedObjectPool.returnObject(poolKey, plcConnection);

return null;

} else {



Which makes sense as it is trying to keep active connections pooled.

However, when this connection is again retrieved from the pool it seems the

plcConnection connects again and creates an additional nioEventLoopGroup

thread, which is never closed.



I am new to working with this project and Jira. It seems to me that I

should close the issue I just created as your fix does indeed correct the

original issue, and perhaps open another issue on PooledPlcDriverManager

for this thread leak?



Regards, Adam



On Mon, Aug 24, 2020 at 4:39 AM Julian Feinauer <

j.feina...@pragmaticminds.de<mailto:j.feina...@pragmaticminds.de>> wrote:



Hi,



short feedback. I looked into the code and indeed it seems that we had a

bug there which could lead tot he socket leak you described.

I pushed a fix in the branch:



https://github.com/apache/plc4x/tree/bugfix/close-eventloop-after-channel



Would you mind taking a look and testing this with your code @Adam Rossi?



Thanks!

Juliasn



Am 24.08.20, 08:26 schrieb "Julian Feinauer" <

j.feina...@pragmaticminds.de<mailto:j.feina...@pragmaticminds.de>>:



Perhaps, some related questions:



- You are using Linux for your Tests?

- Do you close all Connections properly?

Normally the `PlcConnection.close()` method should close the EventLoop.



Julian



Am 24.08.20, 08:23 schrieb "Julian Feinauer" <

j.feina...@pragmaticminds.de<mailto:j.feina...@pragmaticminds.de>>:



Hi Adam,



I will have a look today!



Do we have a Jira Issue for it already?



Julian



Am 24.08.20, 07:38 schrieb "Christofer Dutz" <

christofer.d...@c-ware.de<mailto:christofer.d...@c-ware.de>>:



Hi Adam,



of course that's unfortunate ... also I will not be able to

address this issue soon as I have to work on the tasks of my research

project.

I have one more month to work on this and I'm months behind

schedule because I have been doing free support way too much lately.



I really hope Julian will be able to help ... he's way more

into the details of Netty than I am (cause he's got the book ;-) )



So Julian? ... it would be super awesome if you could take on

this issue.



Chris







Am 24.08.20, 00:17 schrieb "Adam Rossi" 
<mailto:ac.ro...@gmail.com>:



Thanks, I did test with 0.8.0-SNAPSHOT and see the same

behavior. In every

plcConnection a nioEventLoopGroup thread is created and

does not ever seem

to be destroyed.



I wish I understood the io.netty.channel.EventLoopGroup

class better to be

more helpful here. Would an example program that

reproduces this thread

leak be useful?



jconsole shows the thread data as:



Name: nioEventLoopGroup-19-1

State: RUNNABLE

Total blocked: 0  Total waited: 0



Stack trace:


java.base@13.0.2/sun.nio.ch.EPoll.wait<mailto:java.base@13.0.2/sun.nio.ch.EPoll.wait>(Native
 Method)

java.base@13.0.2<mailto:java.base@13.0.2>



/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)

java.base@13.0.2<mailto:java.base@13.0.2>



/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)

   - locked

io.netty.channel.nio.SelectedSelectionKeySet@1838f97

   - locked sun.nio.ch.EPollSelectorImpl@1f49287

java.base@13.0.2/sun.nio.ch<mailto:java.base@13.0.2/sun.nio.ch>

.SelectorImpl.select(SelectorImpl.java:141)



app//io.netty.channel.nio.SelectedSele

Re: Leaking nioEventLoopGroup threads

[Julian Feinauer]

Hi Adam,

sorry form y late response and in facgt thanks for your feedback, happy to hear!
I will merge my branch and close the issue, no worries.

And you are exactly right, just log another issue fort he Pool and we hope that 
someone may find the time to have a look there : )

Julian

PS.: As you already digged into the code you can try to fix it yourself of 
course, I would be more than happy to get a PR from you : )

Von: Adam Rossi 
Datum: Dienstag, 25. August 2020 um 15:45
An: Julian Feinauer 
Cc: "dev@plc4x.apache.org" 
Betreff: Re: Leaking nioEventLoopGroup threads

Juilan,

My apologies - your fix did indeed work. The issue is that 
PooledPlcDriverManager does not seem to be calling the close method on the 
connection. Switching back to PlcDriverManager from PooledPlcDriverManager 
results in your new log comments showing up in the log, and more importantly no 
more leaks of the nioEventLoopGroup threads. I have tested the code in a loop 
for an hour or so and it is working perfectly.

The PooledPlcDriverManager seems to intercept the close method on the 
plcConnection (lines 125 - 130):

if ("close".equals(method.getName())) {
LOGGER.debug("close called on {}", plcConnection);
proxyInvalidated.set(true);
keyedObjectPool.returnObject(poolKey, plcConnection);
return null;
} else {

Which makes sense as it is trying to keep active connections pooled. However, 
when this connection is again retrieved from the pool it seems the 
plcConnection connects again and creates an additional nioEventLoopGroup 
thread, which is never closed.

I am new to working with this project and Jira. It seems to me that I should 
close the issue I just created as your fix does indeed correct the original 
issue, and perhaps open another issue on PooledPlcDriverManager for this thread 
leak?

Regards, Adam

On Mon, Aug 24, 2020 at 4:39 AM Julian Feinauer 
mailto:j.feina...@pragmaticminds.de>> wrote:
Hi,

short feedback. I looked into the code and indeed it seems that we had a  bug 
there which could lead tot he socket leak you described.
I pushed a fix in the branch:

https://github.com/apache/plc4x/tree/bugfix/close-eventloop-after-channel

Would you mind taking a look and testing this with your code @Adam Rossi?

Thanks!
Juliasn

Am 24.08.20, 08:26 schrieb "Julian Feinauer" 
mailto:j.feina...@pragmaticminds.de>>:

Perhaps, some related questions:

- You are using Linux for your Tests?
- Do you close all Connections properly?
Normally the `PlcConnection.close()` method should close the EventLoop.

Julian

Am 24.08.20, 08:23 schrieb "Julian Feinauer" 
mailto:j.feina...@pragmaticminds.de>>:

Hi Adam,

I will have a look today!

Do we have a Jira Issue for it already?

Julian

Am 24.08.20, 07:38 schrieb "Christofer Dutz" 
mailto:christofer.d...@c-ware.de>>:

Hi Adam,

of course that's unfortunate ... also I will not be able to address 
this issue soon as I have to work on the tasks of my research project.
I have one more month to work on this and I'm months behind 
schedule because I have been doing free support way too much lately.

I really hope Julian will be able to help ... he's way more into 
the details of Netty than I am (cause he's got the book ;-) )

So Julian? ... it would be super awesome if you could take on this 
issue.

Chris



Am 24.08.20, 00:17 schrieb "Adam Rossi" 
mailto:ac.ro...@gmail.com>>:

Thanks, I did test with 0.8.0-SNAPSHOT and see the same 
behavior. In every
plcConnection a nioEventLoopGroup thread is created and does 
not ever seem
to be destroyed.

I wish I understood the io.netty.channel.EventLoopGroup class 
better to be
more helpful here. Would an example program that reproduces 
this thread
leak be useful?

jconsole shows the thread data as:

Name: nioEventLoopGroup-19-1
State: RUNNABLE
Total blocked: 0  Total waited: 0

Stack trace:

java.base@13.0.2/sun.nio.ch<http://sun.nio.ch>.EPoll.wait(Native Method)
java.base@13.0.2

/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)
java.base@13.0.2
/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)
   - locked io.netty.channel.nio.SelectedSelectionKeySet@1838f97
   - locked sun.nio.ch.EPollSelectorImpl@1f49287

java.base@13.0.2/sun.nio.ch<http://sun.nio.ch>.SelectorImpl.select(SelectorImpl.java:141)

app//io.netty.channel.nio.SelectedSelectionKeySetSelecto

Re: Leaking nioEventLoopGroup threads

[Julian Feinauer]

Hi,

short feedback. I looked into the code and indeed it seems that we had a  bug 
there which could lead tot he socket leak you described.
I pushed a fix in the branch:

https://github.com/apache/plc4x/tree/bugfix/close-eventloop-after-channel

Would you mind taking a look and testing this with your code @Adam Rossi?

Thanks!
Juliasn

Am 24.08.20, 08:26 schrieb "Julian Feinauer" :

Perhaps, some related questions:

- You are using Linux for your Tests?
- Do you close all Connections properly?
Normally the `PlcConnection.close()` method should close the EventLoop.

Julian

Am 24.08.20, 08:23 schrieb "Julian Feinauer" :

Hi Adam,

I will have a look today!

Do we have a Jira Issue for it already?

Julian

Am 24.08.20, 07:38 schrieb "Christofer Dutz" 
:

Hi Adam,

of course that's unfortunate ... also I will not be able to address 
this issue soon as I have to work on the tasks of my research project.
I have one more month to work on this and I'm months behind 
schedule because I have been doing free support way too much lately.

I really hope Julian will be able to help ... he's way more into 
the details of Netty than I am (cause he's got the book ;-) ) 

So Julian? ... it would be super awesome if you could take on this 
issue.

Chris



Am 24.08.20, 00:17 schrieb "Adam Rossi" :

Thanks, I did test with 0.8.0-SNAPSHOT and see the same 
behavior. In every
plcConnection a nioEventLoopGroup thread is created and does 
not ever seem
to be destroyed.

I wish I understood the io.netty.channel.EventLoopGroup class 
better to be
more helpful here. Would an example program that reproduces 
this thread
leak be useful?

jconsole shows the thread data as:

Name: nioEventLoopGroup-19-1
State: RUNNABLE
Total blocked: 0  Total waited: 0

Stack trace:
java.base@13.0.2/sun.nio.ch.EPoll.wait(Native Method)
java.base@13.0.2

/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)
java.base@13.0.2
/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)
   - locked io.netty.channel.nio.SelectedSelectionKeySet@1838f97
   - locked sun.nio.ch.EPollSelectorImpl@1f49287

java.base@13.0.2/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:141)

app//io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68)

app//io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:803)

app//io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:457)

app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)

app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)

app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
java.base@13.0.2/java.lang.Thread.run(Thread.java:830)


Regards, Adam

On Sun, Aug 23, 2020 at 1:00 PM Christofer Dutz 

wrote:

> Hi Adam,
>
> the Apache SNAPSHOT repo is at:
> https://repository.apache.org/content/repositories/snapshots
>
> Adding this to your pom should help:
>
>   
>   
> 
>   apache-snapshots
>   
https://repository.apache.org/content/repositories/snapshots
> 
>   
> false
>   
>   
> true
>   
> 
>   
>
>   
>   
> 
>   apache-snapshots
>   
https://repository.apache.org/content/repositories/snapshots
> 
>   
> false
>   
>   
> true
>   
> 
>   
>
> Chris
> Am 23.08.20, 18:56 schrieb "Adam Rossi" :
>
> Sure thing. Is 0.8.0-snapshot hosted anywhere or is that 
something
> t

Re: Leaking nioEventLoopGroup threads

[Julian Feinauer]

Perhaps, some related questions:

- You are using Linux for your Tests?
- Do you close all Connections properly?
Normally the `PlcConnection.close()` method should close the EventLoop.

Julian

Am 24.08.20, 08:23 schrieb "Julian Feinauer" :

Hi Adam,

I will have a look today!

Do we have a Jira Issue for it already?

Julian

Am 24.08.20, 07:38 schrieb "Christofer Dutz" :

Hi Adam,

of course that's unfortunate ... also I will not be able to address 
this issue soon as I have to work on the tasks of my research project.
I have one more month to work on this and I'm months behind schedule 
because I have been doing free support way too much lately.

I really hope Julian will be able to help ... he's way more into the 
details of Netty than I am (cause he's got the book ;-) ) 

So Julian? ... it would be super awesome if you could take on this 
issue.

Chris



Am 24.08.20, 00:17 schrieb "Adam Rossi" :

Thanks, I did test with 0.8.0-SNAPSHOT and see the same behavior. 
In every
plcConnection a nioEventLoopGroup thread is created and does not 
ever seem
to be destroyed.

I wish I understood the io.netty.channel.EventLoopGroup class 
better to be
more helpful here. Would an example program that reproduces this 
thread
leak be useful?

jconsole shows the thread data as:

Name: nioEventLoopGroup-19-1
State: RUNNABLE
Total blocked: 0  Total waited: 0

Stack trace:
java.base@13.0.2/sun.nio.ch.EPoll.wait(Native Method)
java.base@13.0.2
/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)
java.base@13.0.2
/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)
   - locked io.netty.channel.nio.SelectedSelectionKeySet@1838f97
   - locked sun.nio.ch.EPollSelectorImpl@1f49287

java.base@13.0.2/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:141)

app//io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68)
app//io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:803)
app//io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:457)

app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)

app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)

app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
java.base@13.0.2/java.lang.Thread.run(Thread.java:830)


Regards, Adam

On Sun, Aug 23, 2020 at 1:00 PM Christofer Dutz 

wrote:

> Hi Adam,
>
> the Apache SNAPSHOT repo is at:
> https://repository.apache.org/content/repositories/snapshots
>
> Adding this to your pom should help:
>
>   
>   
> 
>   apache-snapshots
>   
https://repository.apache.org/content/repositories/snapshots
> 
>   
> false
>   
>   
> true
>   
> 
>   
>
>   
>   
> 
>   apache-snapshots
>   
https://repository.apache.org/content/repositories/snapshots
> 
>   
> false
>   
>   
> true
>   
> 
>   
>
> Chris
> Am 23.08.20, 18:56 schrieb "Adam Rossi" :
>
> Sure thing. Is 0.8.0-snapshot hosted anywhere or is that 
something
> that needs to be built? Regards Adam
>
> > On Aug 23, 2020, at 12:31 PM, Christofer Dutz <
> christofer.d...@c-ware.de> wrote:
> >
> > Hmm ...
> >
> > Could you possibly give 0.8.0-SNAPSHOT a try?  or 
0.6.x? ...
> 0.7.0 was the first of the new generation drivers. We're 
maintaining the
> 0.6 branch and working hard on making the new generation drivers 
100%
> production ready.
> >
> > Chris
> >
> >
> > Am 23.08.20, 18:06 schrieb "Adam Rossi" 
:
> >
 

Re: Leaking nioEventLoopGroup threads

[Julian Feinauer]

Hi Adam,

I will have a look today!

Do we have a Jira Issue for it already?

Julian

Am 24.08.20, 07:38 schrieb "Christofer Dutz" :

Hi Adam,

of course that's unfortunate ... also I will not be able to address this 
issue soon as I have to work on the tasks of my research project.
I have one more month to work on this and I'm months behind schedule 
because I have been doing free support way too much lately.

I really hope Julian will be able to help ... he's way more into the 
details of Netty than I am (cause he's got the book ;-) ) 

So Julian? ... it would be super awesome if you could take on this issue.

Chris



Am 24.08.20, 00:17 schrieb "Adam Rossi" :

Thanks, I did test with 0.8.0-SNAPSHOT and see the same behavior. In 
every
plcConnection a nioEventLoopGroup thread is created and does not ever 
seem
to be destroyed.

I wish I understood the io.netty.channel.EventLoopGroup class better to 
be
more helpful here. Would an example program that reproduces this thread
leak be useful?

jconsole shows the thread data as:

Name: nioEventLoopGroup-19-1
State: RUNNABLE
Total blocked: 0  Total waited: 0

Stack trace:
java.base@13.0.2/sun.nio.ch.EPoll.wait(Native Method)
java.base@13.0.2
/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)
java.base@13.0.2
/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)
   - locked io.netty.channel.nio.SelectedSelectionKeySet@1838f97
   - locked sun.nio.ch.EPollSelectorImpl@1f49287
java.base@13.0.2/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:141)

app//io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68)
app//io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:803)
app//io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:457)

app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)

app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)

app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
java.base@13.0.2/java.lang.Thread.run(Thread.java:830)


Regards, Adam

On Sun, Aug 23, 2020 at 1:00 PM Christofer Dutz 

wrote:

> Hi Adam,
>
> the Apache SNAPSHOT repo is at:
> https://repository.apache.org/content/repositories/snapshots
>
> Adding this to your pom should help:
>
>   
>   
> 
>   apache-snapshots
>   
https://repository.apache.org/content/repositories/snapshots
> 
>   
> false
>   
>   
> true
>   
> 
>   
>
>   
>   
> 
>   apache-snapshots
>   
https://repository.apache.org/content/repositories/snapshots
> 
>   
> false
>   
>   
> true
>   
> 
>   
>
> Chris
> Am 23.08.20, 18:56 schrieb "Adam Rossi" :
>
> Sure thing. Is 0.8.0-snapshot hosted anywhere or is that something
> that needs to be built? Regards Adam
>
> > On Aug 23, 2020, at 12:31 PM, Christofer Dutz <
> christofer.d...@c-ware.de> wrote:
> >
> > Hmm ...
> >
> > Could you possibly give 0.8.0-SNAPSHOT a try?  or 0.6.x? ...
> 0.7.0 was the first of the new generation drivers. We're maintaining 
the
> 0.6 branch and working hard on making the new generation drivers 100%
> production ready.
> >
> > Chris
> >
> >
> > Am 23.08.20, 18:06 schrieb "Adam Rossi" :
> >
> >This is the latest 0.7.0 release from Maven.
> >
> >
> >Regards Adam
> >
> >> On Aug 23, 2020, at 11:56 AM, Christofer Dutz <
> christofer.d...@c-ware.de> wrote:
> >>
> >> Hi Adam,
> >>
> >> which version of PLC4X are you using? I know we had similar 
reports
> some time ago, but had thought we had fixed them
> >>
> >> Chris
> >>
> >>
> >>
> >> Am 23.08.20, 16:40 schrieb "Adam Rossi" :
> >>
> >>   Howdy. I am seeing a persistent thread being created for 
every
> >>   plcConnection connect which looks like the following:
> >>
> >>   Name: nioEventLoopGroup-11-1
> >>   State: RUNNABLE
> >>   Total blocked: 0 

Re: Starting a new project

[Julian Feinauer]

Many thanks again, its online now: https://plc4x.apache.org/users/adopters.html

<3

Julian

Am 21.08.20, 12:55 schrieb "Julian Feinauer" :

Hi Stefano,

thats awesome to hear and thank you VERY MUCH for caring that much about 
PLC4X and also thanks to Daniele for providing us the Logo!

I will quickly add a PR for you to review!

Julian

Von: Stefano Bossi 
Antworten an: 
Datum: Freitag, 21. August 2020 um 12:31
An: "dev@plc4x.apache.org" , Christofer Dutz 

Cc: Daniele Rimoldi 
Betreff: Starting a new project


Dear Chris,

as discussed privately, I am sending you some brief information about the 
project I am dealing with for the Pietro Rimoldi S.n.c Company.
The technical director, added in copy, agreed to list the name of the 
company to the “Companies using Apache PLC4X” page of your site.

Here are the data for the page:
· Name of the company: PIETRORIMOLDI s.r.l.
· Company Site: www.rimoldi.it<http://www.rimoldi.it>
· Market: IIoT / Analytics
· Summary of the project: We started a project which deals with 
long term data analysis; the data are gathered from machines controlled in real 
time by PLC. Failure prediction and behavioral working condition monitoring are 
the main goals. PLC4x library is a fundamental part of the process.
Logo: attached to the mail

Best regards,
Stefano Bossi

Re: Starting a new project

[Julian Feinauer]

Hi Stefano,

thats awesome to hear and thank you VERY MUCH for caring that much about PLC4X 
and also thanks to Daniele for providing us the Logo!

I will quickly add a PR for you to review!

Julian

Von: Stefano Bossi 
Antworten an: 
Datum: Freitag, 21. August 2020 um 12:31
An: "dev@plc4x.apache.org" , Christofer Dutz 

Cc: Daniele Rimoldi 
Betreff: Starting a new project


Dear Chris,

as discussed privately, I am sending you some brief information about the 
project I am dealing with for the Pietro Rimoldi S.n.c Company.
The technical director, added in copy, agreed to list the name of the company 
to the “Companies using Apache PLC4X” page of your site.

Here are the data for the page:
· Name of the company: PIETRORIMOLDI s.r.l.
· Company Site: www.rimoldi.it
· Market: IIoT / Analytics
· Summary of the project: We started a project which deals with long 
term data analysis; the data are gathered from machines controlled in real time 
by PLC. Failure prediction and behavioral working condition monitoring are the 
main goals. PLC4x library is a fundamental part of the process.
Logo: attached to the mail

Best regards,
Stefano Bossi
​

Re: [S7] proposal for changing the way we read STRING values.

[Julian Feinauer]

Hey,

I'm unemotional with your suggestion so you have my +0 there : )

Julian

Am 20.08.20, 13:27 schrieb "Christofer Dutz" :

Hi Julian,

what I didn't like with using the Array syntax was that your're not reading 
an array of Strings ... 

How would you read an array of strings?

How about using round-braces? 

STRING(10) 

This way you could read an array of 10-Char strings:

STRING(10)[5]

Chris


Am 20.08.20, 13:16 schrieb "Julian Feinauer" :

Hi,

this also was a bit controversial in the past and AFAIR we already hat 
STRING[xx] as the command to not read a String Array but a String with given 
size (ignoring ACT value).
In the end its about latency vs bandwith I guess. 
Personally, I would stick to the rule: Read MAX either given by 
STRING[xx] syntax or the default 254 or 256 (dont remember the spec exactly).

Julian

Am 20.08.20, 12:46 schrieb "Christofer Dutz" 
:

Another alternative would be to explicitly limit the number of 
chars read.

So if we would extend the address syntax for STRING types to 
something like 

%DB2:30:STRING:10

It would simply read the 10 chars without checking the size first.

Chris



Am 20.08.20, 12:44 schrieb "Christofer Dutz" 
:

Hi all,

while investigating: 
https://issues.apache.org/jira/browse/PLC4X-240 I noticed that the reading of 
STRING types seems to be extremely inefficient.

The reason is that we are currently reading a STRING element by 
reading 258 bytes (1 byte for MAX num of chars, 1 byte for ACT num of chars and 
then 256 bytes containing char data).

The problem is that with a PDU-Size of 240 you can’t read one 
STRING with only one packet. With a S7 1500 or 400 it might work as they have 
larger PDU sizes. Currently the 0.6 drivers split this up into 2 requests.

But it’s highly inefficient as usually the content will not be 
anywhere near the 256 chars.

So my idea is to only request one byte (the ACT size) of the 
String and as soon as that’s returned, to ask for only the chars that are 
actually used. This should drastically reduce the payload on the wire.

What do you think?

Chris

Re: [S7] proposal for changing the way we read STRING values.

[Julian Feinauer]

Hi,

this also was a bit controversial in the past and AFAIR we already hat 
STRING[xx] as the command to not read a String Array but a String with given 
size (ignoring ACT value).
In the end its about latency vs bandwith I guess. 
Personally, I would stick to the rule: Read MAX either given by STRING[xx] 
syntax or the default 254 or 256 (dont remember the spec exactly).

Julian

Am 20.08.20, 12:46 schrieb "Christofer Dutz" :

Another alternative would be to explicitly limit the number of chars read.

So if we would extend the address syntax for STRING types to something like 

%DB2:30:STRING:10

It would simply read the 10 chars without checking the size first.

Chris



Am 20.08.20, 12:44 schrieb "Christofer Dutz" :

Hi all,

while investigating: https://issues.apache.org/jira/browse/PLC4X-240 I 
noticed that the reading of STRING types seems to be extremely inefficient.

The reason is that we are currently reading a STRING element by reading 
258 bytes (1 byte for MAX num of chars, 1 byte for ACT num of chars and then 
256 bytes containing char data).

The problem is that with a PDU-Size of 240 you can’t read one STRING 
with only one packet. With a S7 1500 or 400 it might work as they have larger 
PDU sizes. Currently the 0.6 drivers split this up into 2 requests.

But it’s highly inefficient as usually the content will not be anywhere 
near the 256 chars.

So my idea is to only request one byte (the ACT size) of the String and 
as soon as that’s returned, to ask for only the chars that are actually used. 
This should drastically reduce the payload on the wire.

What do you think?

Chris

Re: unit-identifier in PooledPlcDriverManager

[Julian Feinauer]

Hey,

I created PLC4X-224 for this https://issues.apache.org/jira/browse/PLC4X-224
Ideally every Connection brings a “normalization” function which prints a 
normalized String which contains all “relevant” parameters in a default order.

J

Von: Christofer Dutz 
Datum: Sonntag, 9. August 2020 um 11:21
An: Julian Feinauer , "dev@plc4x.apache.org" 

Betreff: Re: unit-identifier in PooledPlcDriverManager

I would generally say that every parameter is important. So perhaps a matcher 
that simply compares all configured keys would be a solution, regardless of the 
order.

Perhaps a new annotation that allows to exclude individual parameters would be 
an idea.

Chris

Von: Julian Feinauer 
Gesendet: Sonntag, 9. August 2020 10:41
An: dev@plc4x.apache.org 
Betreff: Re: unit-identifier in PooledPlcDriverManager

Hi Adam,

I created an Issue: https://issues.apache.org/jira/browse/PLC4X-223
And provided a PR: https://github.com/apache/plc4x/pull/176

I would be happy for your feedback : )

Thanks
Julian

Am 09.08.20, 10:27 schrieb "Julian Feinauer" :

Hi Adam,

thanks for the hint.
I guess this simply is a bug.

Let me have a look.

Julian

Am 09.08.20, 00:34 schrieb "Adam Rossi" :

Howdy. I am using Plc4x for modbus tcp integration.

For my application I need to specify the slave ID in the following 
format:

modbus://192.168.0.1:503?unit-identifier=50

This works for a single PlcConnection. However, parameters are not
supported in the PooledPlcDriverManager, I get this exception:

Caused by: org.apache.plc4x.java.api.exceptions.PlcConnectionException:
java.lang.IllegalArgumentException: modbus://
192.168.0.5:503?unit-identifier=50 doesn't match

^(?modbus:(tcp://(?[\w.]+)(:(?\d*))?|serial://(?((?!/\d).)*)))/?(?\?.*)?
at

org.apache.plc4x.java.utils.connectionpool.PooledPlcDriverManager.getConnection(PooledPlcDriverManager.java:117)

Is there a reason the pool does not like parameters for tcp (but does
accept them for serial modbus)?

Thanks for all of the hard work here. Wonderful project! Regards, Adam

Re: unit-identifier in PooledPlcDriverManager

[Julian Feinauer]

Hi Adam,

I created an Issue: https://issues.apache.org/jira/browse/PLC4X-223
And provided a PR: https://github.com/apache/plc4x/pull/176

I would be happy for your feedback : )

Thanks
Julian

Am 09.08.20, 10:27 schrieb "Julian Feinauer" :

Hi Adam,

thanks for the hint.
I guess this simply is a bug.

Let me have a look.

Julian

Am 09.08.20, 00:34 schrieb "Adam Rossi" :

Howdy. I am using Plc4x for modbus tcp integration.

For my application I need to specify the slave ID in the following 
format:

modbus://192.168.0.1:503?unit-identifier=50

This works for a single PlcConnection. However, parameters are not
supported in the PooledPlcDriverManager, I get this exception:

Caused by: org.apache.plc4x.java.api.exceptions.PlcConnectionException:
java.lang.IllegalArgumentException: modbus://
192.168.0.5:503?unit-identifier=50 doesn't match

^(?modbus:(tcp://(?[\w.]+)(:(?\d*))?|serial://(?((?!/\d).)*)))/?(?\?.*)?
at

org.apache.plc4x.java.utils.connectionpool.PooledPlcDriverManager.getConnection(PooledPlcDriverManager.java:117)

Is there a reason the pool does not like parameters for tcp (but does
accept them for serial modbus)?

Thanks for all of the hard work here. Wonderful project! Regards, Adam

[jira] [Created] (PLC4X-224) Add URI normalization method for Connection Strings for PooledDriverManager

[Julian Feinauer (Jira)]

Julian Feinauer created PLC4X-224:
-

 Summary: Add URI normalization method for Connection Strings for 
PooledDriverManager
 Key: PLC4X-224
 URL: https://issues.apache.org/jira/browse/PLC4X-224
 Project: Apache PLC4X
  Issue Type: Improvement
Affects Versions: 0.7.0
Reporter: Julian Feinauer


Currently, one could write two "identical" connections with different 
connection strings, e.g.
{code:java}
s7://127.0.0.1?rackId=0=1
{code}
and
{code:java}
s7://127.0.0.1?slotId=1=0{code}
If the connection Pool only looks at String comparison he would open two 
connetions as the strings are different.

Thus each Connection should have a way to normalize its strings (also paste in 
all defaults) so that two Connection Stirngs beeing equal means the Connections 
are equal and can be shared.

See PoolKeyFactory.java L44ff



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (PLC4X-223) PooledPlcDriverManager does not support parameter

[Julian Feinauer (Jira)]

Julian Feinauer created PLC4X-223:
-

 Summary: PooledPlcDriverManager does not support parameter
 Key: PLC4X-223
 URL: https://issues.apache.org/jira/browse/PLC4X-223
 Project: Apache PLC4X
  Issue Type: Bug
Affects Versions: 0.7.0
Reporter: Julian Feinauer
Assignee: Julian Feinauer


For my application I need to specify the slave ID in the following format:
 
modbus://192.168.0.1:503?unit-identifier=50
 
This works for a single PlcConnection. However, parameters are not
supported in the PooledPlcDriverManager, I get this exception:
 
Caused by: org.apache.plc4x.java.api.exceptions.PlcConnectionException:
java.lang.IllegalArgumentException: modbus://
192.168.0.5:503?unit-identifier=50 doesn't match
^(?modbus:(tcp://(?[\w.]+)(:(?\d*))?|serial://(?((?!/\d).)*)))/?(?\?.*)?
at
org.apache.plc4x.java.utils.connectionpool.PooledPlcDriverManager.getConnection(PooledPlcDriverManager.java:117)
 
Is there a reason the pool does not like parameters for tcp (but does
accept them for serial modbus)?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: unit-identifier in PooledPlcDriverManager

[Julian Feinauer]

Hi Adam,

thanks for the hint.
I guess this simply is a bug.

Let me have a look.

Julian

Am 09.08.20, 00:34 schrieb "Adam Rossi" :

Howdy. I am using Plc4x for modbus tcp integration.

For my application I need to specify the slave ID in the following format:

modbus://192.168.0.1:503?unit-identifier=50

This works for a single PlcConnection. However, parameters are not
supported in the PooledPlcDriverManager, I get this exception:

Caused by: org.apache.plc4x.java.api.exceptions.PlcConnectionException:
java.lang.IllegalArgumentException: modbus://
192.168.0.5:503?unit-identifier=50 doesn't match

^(?modbus:(tcp://(?[\w.]+)(:(?\d*))?|serial://(?((?!/\d).)*)))/?(?\?.*)?
at

org.apache.plc4x.java.utils.connectionpool.PooledPlcDriverManager.getConnection(PooledPlcDriverManager.java:117)

Is there a reason the pool does not like parameters for tcp (but does
accept them for serial modbus)?

Thanks for all of the hard work here. Wonderful project! Regards, Adam

Re: New drivers: Different Root-Type depending on selected transport?

[Julian Feinauer]

Hi Chris,

this should not be a big problem as this was the main reason I introduced the 
whol "Handler Registration" Concept where you tell the underlying layer which 
type of root it should try to deserialize.

Lets chat later today or tomorrow to find a way but generally this should be 
rather "straightforward"

Julian

Am 05.08.20, 14:40 schrieb "Christofer Dutz" :

Hi all,

While working on the ADS driver I ran into a problem with the new drivers.
With ADS depending on the selected transport I would need the driver to use 
a different Root-Level type.
AmsTCPPacket for TCP based traffic and AmsSerialFrame for serial 
transports. However right now I have no means to do this.

I think it would be great if there was an extension point to the new driver 
core, that allows to register another layer in front of the current root, that 
allows this transoport-dependent level.

I think this also applies or could apply to other drivers too, so I think 
it would be great to have this in the SPI part.

Chris

Re: Reading Array of Int

[Julian Feinauer]

Thank you Stefano, first for your feedback and second fort he compliments.

We are doing our best and it feels really good if people see our efforts <3

Julian

Von: Stefano Bossi 
Datum: Montag, 3. August 2020 um 11:49
An: , Julian Feinauer , 
Christofer Dutz 
Betreff: Re: Reading Array of Int

Thanks you guys 

I have downloaded and compiled the develop code and now I cloud read the INT 
array without any problem!

You are managing a great project with a great support !!!

Thanks,
Stefano

On 02/08/2020 21:08, Julian Feinauer wrote:

Hi,



sorry for the delayed working on it but I just took a look and think I fixed 
the issue.



It seems that arrays where not properly implemented in the S7 Driver (?).



I opened up a PR (https://github.com/apache/plc4x/pull/175) and hope that 
@Christofer Dutz finds some time to have a quick look (as he did most of the 
work there) and merge it, if he agrees with it.



If you could try out the branch and give your feedback I would be happy.



Thanks for the excellent preparation of work! : )



Julian



Am 02.08.20, 20:40 schrieb "Julian Feinauer" 
<mailto:j.feina...@pragmaticminds.de>:



Hi,



I'm looking into it : )



J



Am 01.08.20, 16:17 schrieb "Christofer Dutz" 
<mailto:christofer.d...@c-ware.de>:



Hi Stefano,



I think such a Jira would be a good idea.



I’m currently working on the Beckhoff ADS and would try to have a look 
as soon as possible.



Chris







Von: Stefano Bossi 
<mailto:stefano.bo...@gmail.com>

Antworten an: <mailto:dev@plc4x.apache.org>

Datum: Samstag, 1. August 2020 um 11:25

    An: <mailto:dev@plc4x.apache.org>, Julian 
Feinauer <mailto:j.feina...@pragmaticminds.de>

Betreff: Re: Reading Array of Int



Hi julian,



if you need or think could simplify the development I could open a jira 
ticket and upload a couple of pcap capture for you.



As I wrote I am using the 0.7.0 version from Maven and I am talking 
with a real Siemens 1200 with firmware 1.2 (pretty old but I didn't find a way 
to upgrade it ).



Let me know.



Thanks for help.



    Regards,

Stefano



On 30/07/2020 07:49, Julian Feinauer wrote:



Hey Stefano, I will try to have a look later today. Are you using plc4x 
version 0.6 or 0.7?







Thank you!







Julian







Holen Sie sich Outlook für 
Android<https://aka.ms/ghei36><https://aka.ms/ghei36><https://aka.ms/ghei36><https://aka.ms/ghei36>











Von: Stefano Bossi 
<mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com>



Gesendet: Mittwoch, 29. Juli 2020, 12:32



An: 
dev@plc4x.apache.org<mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org>;
 Christofer Dutz



Betreff: Re: Reading Array of Int







Thanks Chris,







yes definitely this is a workaround, I am experimenting and learning.







I really appreciate your time on the investigation of the issue.







Thanks,



Stefano Bossi















On 29/07/2020 12:08, Christofer Dutz wrote:







Well that’s a workaround, but not a fix …







We should focus on fixing this.







I’ll investigate the issue as soon as I’m done with the Beckhoff 
ADS/AMS stuff …







Perhaps Julian could find some time to investigate?







Chris















Von: Stefano Bossi 
<mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com>



Antworten an: 
<mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org>



Datum: Mittwoch, 29. Juli 2020 um 11:41



An: 
<mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org>



Betreff: Re: Reading Array of Int











I have adopted a workaround reading all the INT variable separated.







--connection-string 's7:tcp://192.168.1.192?controller-type=S7_1200' 
--field-addresses '%DB1:274.0:INT' '%DB1:276.0:INT' '%DB1:278.0:INT' 
'%DB1:280.0:INT'







In this way on the wire you have:



the query:







   

Re: Reading Array of Int

[Julian Feinauer]

Hi,

sorry for the delayed working on it but I just took a look and think I fixed 
the issue.

It seems that arrays where not properly implemented in the S7 Driver (?).

I opened up a PR (https://github.com/apache/plc4x/pull/175) and hope that 
@Christofer Dutz finds some time to have a quick look (as he did most of the 
work there) and merge it, if he agrees with it.

If you could try out the branch and give your feedback I would be happy.

Thanks for the excellent preparation of work! : )

Julian

Am 02.08.20, 20:40 schrieb "Julian Feinauer" :

Hi,

I'm looking into it : )

J

Am 01.08.20, 16:17 schrieb "Christofer Dutz" :

Hi Stefano,

I think such a Jira would be a good idea.

I’m currently working on the Beckhoff ADS and would try to have a look 
as soon as possible.

Chris



Von: Stefano Bossi 
Antworten an: 
Datum: Samstag, 1. August 2020 um 11:25
    An: , Julian Feinauer 

Betreff: Re: Reading Array of Int

Hi julian,

if you need or think could simplify the development I could open a jira 
ticket and upload a couple of pcap capture for you.

As I wrote I am using the 0.7.0 version from Maven and I am talking 
with a real Siemens 1200 with firmware 1.2 (pretty old but I didn't find a way 
to upgrade it ).

Let me know.

Thanks for help.

Regards,
Stefano

On 30/07/2020 07:49, Julian Feinauer wrote:

Hey Stefano, I will try to have a look later today. Are you using plc4x 
version 0.6 or 0.7?



Thank you!



Julian



Holen Sie sich Outlook für 
Android<https://aka.ms/ghei36><https://aka.ms/ghei36>





Von: Stefano Bossi 
<mailto:stefano.bo...@gmail.com>

Gesendet: Mittwoch, 29. Juli 2020, 12:32

An: dev@plc4x.apache.org<mailto:dev@plc4x.apache.org>; Christofer Dutz

Betreff: Re: Reading Array of Int



Thanks Chris,



yes definitely this is a workaround, I am experimenting and learning.



I really appreciate your time on the investigation of the issue.



Thanks,

Stefano Bossi







On 29/07/2020 12:08, Christofer Dutz wrote:



Well that’s a workaround, but not a fix …



We should focus on fixing this.



I’ll investigate the issue as soon as I’m done with the Beckhoff 
ADS/AMS stuff …



Perhaps Julian could find some time to investigate?



Chris







Von: Stefano Bossi 
<mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com>

Antworten an: 
<mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org>

Datum: Mittwoch, 29. Juli 2020 um 11:41

An: 
<mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org>

Betreff: Re: Reading Array of Int





I have adopted a workaround reading all the INT variable separated.



--connection-string 's7:tcp://192.168.1.192?controller-type=S7_1200' 
--field-addresses '%DB1:274.0:INT' '%DB1:276.0:INT' '%DB1:278.0:INT' 
'%DB1:280.0:INT'



In this way on the wire you have:

the query:



Frame 296: 111 bytes on wire (888 bits), 111 bytes captured (888 bits) 
on interface utun2, id 0



Null/Loopback



Internet Protocol Version 4, Src: 192.168.100.4, Dst: 192.168.1.192



Transmission Control Protocol, Src Port: 57188, Dst Port: 102, Seq: 48, 
Ack: 50, Len: 67



TPKT, Version: 3, Length: 67



ISO 8073/X.224 COTP Connection-Oriented Transport Protocol



S7 Communication



Header: (Job)



Parameter: (Read Var)



Function: Read Var (0x04)



Item count: 4



Item [1]: (DB 1.DBX 274.0 INT 1)



Item [2]: (DB 1.DBX 276.0 INT 1)



Item [3]: (DB 1.DBX 278.0 INT 1)



Item [4]: (DB 1.DBX 280.0 INT 1)



the answer:



Frame 297: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) on 
interface utun2, id 0



Null/Loopback



Internet Protocol Version 4, Src: 192.168.1.192, Dst: 192.168.100.4



Transmission Control Protocol, Src Port: 102, Dst Port: 57188, Seq: 50, 
Ack: 115, Len: 45



TPKT, Version: 3, Length: 45



ISO 8073/X.224 COTP Connection-Oriented Transport Protocol



S7 Communication



Header: (Ack_Data)



Parameter: (Read Var)



Function: Read Var (0x04)



Item count: 4



Data



Item [1]: (Success)



Item [2]: (Success)



Item [3]: (Success)



Item [4]: (Success)

Re: Reading Array of Int

[Julian Feinauer]

Hi,

I'm looking into it : )

J

Am 01.08.20, 16:17 schrieb "Christofer Dutz" :

Hi Stefano,

I think such a Jira would be a good idea.

I’m currently working on the Beckhoff ADS and would try to have a look as 
soon as possible.

Chris



Von: Stefano Bossi 
Antworten an: 
Datum: Samstag, 1. August 2020 um 11:25
An: , Julian Feinauer 
Betreff: Re: Reading Array of Int

Hi julian,

if you need or think could simplify the development I could open a jira 
ticket and upload a couple of pcap capture for you.

As I wrote I am using the 0.7.0 version from Maven and I am talking with a 
real Siemens 1200 with firmware 1.2 (pretty old but I didn't find a way to 
upgrade it ).

Let me know.

Thanks for help.

Regards,
Stefano

On 30/07/2020 07:49, Julian Feinauer wrote:

Hey Stefano, I will try to have a look later today. Are you using plc4x 
version 0.6 or 0.7?



Thank you!



Julian



Holen Sie sich Outlook für 
Android<https://aka.ms/ghei36><https://aka.ms/ghei36>





Von: Stefano Bossi <mailto:stefano.bo...@gmail.com>

Gesendet: Mittwoch, 29. Juli 2020, 12:32

An: dev@plc4x.apache.org<mailto:dev@plc4x.apache.org>; Christofer Dutz

Betreff: Re: Reading Array of Int



Thanks Chris,



yes definitely this is a workaround, I am experimenting and learning.



I really appreciate your time on the investigation of the issue.



Thanks,

Stefano Bossi







On 29/07/2020 12:08, Christofer Dutz wrote:



Well that’s a workaround, but not a fix …



We should focus on fixing this.



I’ll investigate the issue as soon as I’m done with the Beckhoff ADS/AMS 
stuff …



Perhaps Julian could find some time to investigate?



Chris







Von: Stefano Bossi 
<mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com>

Antworten an: 
<mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org>

Datum: Mittwoch, 29. Juli 2020 um 11:41

An: 
<mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org>

Betreff: Re: Reading Array of Int





I have adopted a workaround reading all the INT variable separated.



--connection-string 's7:tcp://192.168.1.192?controller-type=S7_1200' 
--field-addresses '%DB1:274.0:INT' '%DB1:276.0:INT' '%DB1:278.0:INT' 
'%DB1:280.0:INT'



In this way on the wire you have:

the query:



Frame 296: 111 bytes on wire (888 bits), 111 bytes captured (888 bits) on 
interface utun2, id 0



Null/Loopback



Internet Protocol Version 4, Src: 192.168.100.4, Dst: 192.168.1.192



Transmission Control Protocol, Src Port: 57188, Dst Port: 102, Seq: 48, 
Ack: 50, Len: 67



TPKT, Version: 3, Length: 67



ISO 8073/X.224 COTP Connection-Oriented Transport Protocol



S7 Communication



Header: (Job)



Parameter: (Read Var)



Function: Read Var (0x04)



Item count: 4



Item [1]: (DB 1.DBX 274.0 INT 1)



Item [2]: (DB 1.DBX 276.0 INT 1)



Item [3]: (DB 1.DBX 278.0 INT 1)



Item [4]: (DB 1.DBX 280.0 INT 1)



the answer:



Frame 297: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) on 
interface utun2, id 0



Null/Loopback



Internet Protocol Version 4, Src: 192.168.1.192, Dst: 192.168.100.4



Transmission Control Protocol, Src Port: 102, Dst Port: 57188, Seq: 50, 
Ack: 115, Len: 45



TPKT, Version: 3, Length: 45



ISO 8073/X.224 COTP Connection-Oriented Transport Protocol



S7 Communication



Header: (Ack_Data)



Parameter: (Read Var)



Function: Read Var (0x04)



Item count: 4



Data



Item [1]: (Success)



Item [2]: (Success)



Item [3]: (Success)



Item [4]: (Success)



[INFO ] 10:15:44.727 it.fox.datapicker.HelloPlc4x.printResponse() - 
Value[value-0]: 10



[INFO ] 10:15:44.733 it.fox.datapicker.HelloPlc4x.printResponse() - 
Value[value-1]: 11



[INFO ] 10:15:44.737 it.fox.datapicker.HelloPlc4x.printResponse() - 
Value[value-2]: 12



[INFO ] 10:15:44.741 it.fox.datapicker.HelloPlc4x.printResponse() - 
Value[value-3]: 13



Unfortunately my java knowledge are not so advanced to fix the bug in 
reading the array in a single command, anyway there’s a workaround.



Hope this mail help some newbies like me to find the right way to read data 
from the PLC.



Regards,

Stefano



On 28/07/2020 11:38, Stefano Bossi wrote:



Dear plc4x forum,



I have found a possible problem in reading an array of INT.

I am using the HelloPlc4x app for testing and I am trying to read the field 
addres

Re: Reading Array of Int

[Julian Feinauer]

Hey Stefano, I will try to have a look later today. Are you using plc4x version 
0.6 or 0.7?

Thank you!

Julian

Holen Sie sich Outlook für Android


Von: Stefano Bossi 
Gesendet: Mittwoch, 29. Juli 2020, 12:32
An: dev@plc4x.apache.org; Christofer Dutz
Betreff: Re: Reading Array of Int

Thanks Chris,

yes definitely this is a workaround, I am experimenting and learning.

I really appreciate your time on the investigation of the issue.

Thanks,
Stefano Bossi



On 29/07/2020 12:08, Christofer Dutz wrote:

Well that’s a workaround, but not a fix …

We should focus on fixing this.

I’ll investigate the issue as soon as I’m done with the Beckhoff ADS/AMS stuff …

Perhaps Julian could find some time to investigate?

Chris



Von: Stefano Bossi 
Antworten an: 
Datum: Mittwoch, 29. Juli 2020 um 11:41
An: 
Betreff: Re: Reading Array of Int


I have adopted a workaround reading all the INT variable separated.

--connection-string 's7:tcp://192.168.1.192?controller-type=S7_1200' 
--field-addresses '%DB1:274.0:INT' '%DB1:276.0:INT' '%DB1:278.0:INT' 
'%DB1:280.0:INT'

In this way on the wire you have:
the query:

Frame 296: 111 bytes on wire (888 bits), 111 bytes captured (888 bits) on 
interface utun2, id 0

Null/Loopback

Internet Protocol Version 4, Src: 192.168.100.4, Dst: 192.168.1.192

Transmission Control Protocol, Src Port: 57188, Dst Port: 102, Seq: 48, Ack: 
50, Len: 67

TPKT, Version: 3, Length: 67

ISO 8073/X.224 COTP Connection-Oriented Transport Protocol

S7 Communication

Header: (Job)

Parameter: (Read Var)

Function: Read Var (0x04)

Item count: 4

Item [1]: (DB 1.DBX 274.0 INT 1)

Item [2]: (DB 1.DBX 276.0 INT 1)

Item [3]: (DB 1.DBX 278.0 INT 1)

Item [4]: (DB 1.DBX 280.0 INT 1)

the answer:

Frame 297: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) on 
interface utun2, id 0

Null/Loopback

Internet Protocol Version 4, Src: 192.168.1.192, Dst: 192.168.100.4

Transmission Control Protocol, Src Port: 102, Dst Port: 57188, Seq: 50, Ack: 
115, Len: 45

TPKT, Version: 3, Length: 45

ISO 8073/X.224 COTP Connection-Oriented Transport Protocol

S7 Communication

Header: (Ack_Data)

Parameter: (Read Var)

Function: Read Var (0x04)

Item count: 4

Data

Item [1]: (Success)

Item [2]: (Success)

Item [3]: (Success)

Item [4]: (Success)

[INFO ] 10:15:44.727 it.fox.datapicker.HelloPlc4x.printResponse() - 
Value[value-0]: 10

[INFO ] 10:15:44.733 it.fox.datapicker.HelloPlc4x.printResponse() - 
Value[value-1]: 11

[INFO ] 10:15:44.737 it.fox.datapicker.HelloPlc4x.printResponse() - 
Value[value-2]: 12

[INFO ] 10:15:44.741 it.fox.datapicker.HelloPlc4x.printResponse() - 
Value[value-3]: 13

Unfortunately my java knowledge are not so advanced to fix the bug in reading 
the array in a single command, anyway there’s a workaround.

Hope this mail help some newbies like me to find the right way to read data 
from the PLC.

Regards,
Stefano

On 28/07/2020 11:38, Stefano Bossi wrote:

Dear plc4x forum,

I have found a possible problem in reading an array of INT.
I am using the HelloPlc4x app for testing and I am trying to read the field 
address: '%DB1:274.0:INT[3]'

In the request, captured via wireShark I can see the query:

Frame 3: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface 
utun2, id 0

Null/Loopback

Internet Protocol Version 4, Src: 192.168.100.4, Dst: 192.168.1.192

Transmission Control Protocol, Src Port: 54543, Dst Port: 102, Seq: 1, Ack: 1, 
Len: 31

TPKT, Version: 3, Length: 31

ISO 8073/X.224 COTP Connection-Oriented Transport Protocol

S7 Communication

Header: (Job)

Parameter: (Read Var)

Function: Read Var (0x04)

Item count: 1

Item [1]: (DB 1.DBX 274.0 INT 3)

Variable specification: 0x12

Length of following address specification: 10

Syntax Id: S7ANY (0x10)

Transport size: INT (5)

Length: 3

DB number: 1

Area: Data blocks (DB) (0x84)

Address: 0x000890

and the response:

Frame 4: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface 
utun2, id 0

Null/Loopback

Internet Protocol Version 4, Src: 192.168.1.192, Dst: 192.168.100.4

Transmission Control Protocol, Src Port: 102, Dst Port: 54543, Seq: 1, Ack: 32, 
Len: 31

TPKT, Version: 3, Length: 31

ISO 8073/X.224 COTP Connection-Oriented Transport Protocol

S7 Communication

Header: (Ack_Data)

Parameter: (Read Var)

Function: Read Var (0x04)

Item count: 1

Data

Item [1]: (Success)

Return code: Success (0xff)

Transport size: INTEGER (0x05)

Length: 6

Data: 000a000b000c

The 3 INT I would like to read are there: 000a, 000b, 

Re: s7URIPattern doesn't match

[Julian Feinauer]

Hi Gerardo,

Thanks for your mail!
This indeed is a bug as far as I see it.

Would you mind opening an issue for it?
I will try to fix it tomorrow.

Thanks!
Julian

Holen Sie sich Outlook für Android


From: Gerardo Melia 
Sent: Monday, July 20, 2020 5:02:58 PM
To: dev@plc4x.apache.org 
Subject: s7URIPattern doesn't match

Hi people, first of all thanks for the amazing project that you are doing. I 
have an issue with the 0.7.0 version when I'm using S7 driver. The regex of the 
pattern doesn't match so I got this error: Caused by: 
java.lang.IllegalArgumentException: 
s7://192.168.1.200/0/1 doesn't match


https://github.com/apache/plc4x/blob/1e6df7563ad909d365d1402729699b61c70019bd/plc4j/tools/connection-pool/src/main/java/org/apache/plc4x/java/utils/connectionpool/PoolKeyFactory.java#L46

[image.png]

This regex is correct but In version 0.7.0 I found this one in PoolKeyFactory 
class:

private final Pattern s7URIPattern = 
Pattern.compile("^(?s7://((?[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3})|(?[a-zA-Z0-9\\.\\-]+))(:(?[0-9]{1,5}))?)(?\\?.*)?");

that doesn't match : s7://192.168.1.200/0/1 (With no rack 
nor slot)

Do you know if there is an issue here?

Thanks in advance.

Gerardo Melia

Re: [DISCUSS] How about naming "first time contributors" in RELEASE_NOTES?

[Julian Feinauer]

I like it.

We have quite a big community of people who contributed "small" things but 
still they deserve it : )

Julian

Am 17.07.20, 14:43 schrieb "Christofer Dutz" :

Hi all,

I still remember how happy it made me to have my first contribution 
recognized in an open-source project. Even if it was a tiny one.

So I was thinking … how about we mention first time contributors in the 
RELEASE_NOTES? I wouldn’t mention what they did, how much it was, just list the 
names.

Of course, after asking them ;-)

Chris

Re: Have to run `mvn package` before running example codes in the repo

[Julian Feinauer]

Hey,

I think we cant as we use code generation.
Normally your mvn generate-sources should do the trick, we have to have a look 
why it didnt.

BUT we should definetly write it more prominent in the README.md, I think!

Julian

Am 16.07.20, 10:29 schrieb "Xiangdong Huang" :

Hi,

I just checkout to the develop branch and want to run the project in IDEA.

However,  the IDEA says, class not found
Class: RequirePcap
  Location:
org.apache.plc4x.java.utils.rawsockets.netty.RawSocketChannelTest

Actually, I can indeed find the RequirePcap source code from the repo.

I tried to run `mvn generate-sources` but it does not work.

Then I tried to run `mvn package -DskipTests`. Fortunately, it works. After
running the command, I can execute example codes in IDEA.

My question is, can we avoid to let new developers/users run the command?
(or leave the tips in a  conspicuous place).

Best,
---
Xiangdong Huang
School of Software, Tsinghua University

 黄向东
清华大学 软件学院

Re: Beer, Python and PLC4X

[Julian Feinauer]

Yes, that would be good (both, beer and having you around)

Am 06.07.20, 16:59 schrieb "Christofer Dutz" :

Depending on when you'll do it, I think I'll lurk around as Code-generation 
guru and stick to the beer ;-)

Chris

Am 06.07.20, 16:49 schrieb "Lukas Ott" :

+1 Oh yeah! This is what I was waiting for.

Am Mo., 6. Juli 2020 um 16:47 Uhr schrieb Julian Feinauer <
j.feina...@pragmaticminds.de>:

> Hi friends,
>
> as discussed in Slack we are ready (with regards to build tools) fort 
he
> initiative to work together on plc4py!
> So, no excuses for nobodfy (if python is to hard for you better stop 
right
> here, you are no coder!).
>
> So who is interested and when should we start an evening session 
with, as
> the title says, beer, python and plc4x?
> Probably we could also make a series out of it and do it step by step.
>
> WDYT?
> Julian
>

Beer, Python and PLC4X

[Julian Feinauer]

Hi friends,

as discussed in Slack we are ready (with regards to build tools) fort he 
initiative to work together on plc4py!
So, no excuses for nobodfy (if python is to hard for you better stop right 
here, you are no coder!).

So who is interested and when should we start an evening session with, as the 
title says, beer, python and plc4x?
Probably we could also make a series out of it and do it step by step.

WDYT?
Julian

Re: [DISCUSS] Release the build-tools asap?

[Julian Feinauer]

Yes!

Am 06.07.20, 16:28 schrieb "Christofer Dutz" :

Hi all,

I think it’s sort of time we start thinking about the next release. But 
before we can do that, we have to release the build tools as 0.8.0 requires 
some changes in here.

Would you all be ok with me kicking off the process for doing that?

Chris

Re: No registered handler found for message TPKTPacket[], , using default decode method

[Julian Feinauer]

Hi Anton,

first, welcome here! : )

Second, thanks fort he report, this is indeed some kind of "undefined" 
situation you run into (but we should handle it better!).

What happens ist hat the request takes longer than our predefined internal 
timeout (I think thats 1second or only 500ms) and then the Handler 
"deregisters" and the "request-reply" pattern cannot be finished successfully.
This also happens if you use some kind of VPN where latency is high.

We have to come up with a solution fort hat ASAP.
Would you mind opening an Issue in Jira, then I will try to provide a fix ASAP 
and we can discuss if we want to do a release 0.7.1 with this fix (and some 
others that were reported by the community).

Best!
Julian

Am 06.07.20, 16:02 schrieb "Engman Anton" :

Hello everybody,

I am using PLC4X to poll 29 signals from a Siemens S7-300 device,  all the 
signals are of data type REAL. Every second I send a request to the PLC asking 
for the values and then printing one of the values to the console:

PlcConnection conn = 
driverManager.getConnection("s7:tcp://?remote-rack=0=1=S7_300");
PlcReadRequest.Builder builder = conn.readRequestBuilder();
builder.addItem("value1", "DB.50.DBD0:REAL");
.
.
.
builder.addItem("value29", "DB.50.DBD116:REAL");
PlcReadRequest readRequest = builder.build();

while(true)
{
  PlcReadResponse r = readRequest.execute().get();
  System.out.println(r.getObject("value1"));

  Thread.sleep(1000);
}

Everything works fine for some time, but after >50K requests or 8-12 hours 
with the current polling rate at 1 second the code waits forever at the return 
value from PlcReadResponse r = readRequest.execute().get() and doesn't 
continue. I enabled Trace logging to see what's happening and every time this 
error occurs I get the following error message:

12:56:48.107 [nioEventLoopGroup-2-1] TRACE 
o.a.plc4x.java.spi.Plc4xNettyWrapper - Checking handler 
HandlerRegistration#65120 for Object of type TPKTPacket
12:56:48.107 [nioEventLoopGroup-2-1] TRACE 
o.a.plc4x.java.spi.Plc4xNettyWrapper - Handler HandlerRegistration#65120 has 
right expected type TPKTPacket, checking condition
12:56:48.107 [nioEventLoopGroup-2-1] TRACE 
o.a.plc4x.java.spi.Plc4xNettyWrapper - Registration HandlerRegistration#65120 
does not match object TPKTPacket (currently wrapped to S7MessageResponseData)
12:56:48.107 [nioEventLoopGroup-2-1] TRACE 
o.a.plc4x.java.spi.Plc4xNettyWrapper - Checking handler 
HandlerRegistration#65119 for Object of type TPKTPacket
12:56:48.107 [nioEventLoopGroup-2-1] TRACE 
o.a.plc4x.java.spi.Plc4xNettyWrapper - Handler HandlerRegistration#65119 has 
right expected type TPKTPacket, checking condition
12:56:48.107 [nioEventLoopGroup-2-1] TRACE 
o.a.plc4x.java.spi.Plc4xNettyWrapper - Registration HandlerRegistration#65119 
does not match object TPKTPacket (currently wrapped to S7MessageResponseData)
12:56:48.107 [nioEventLoopGroup-2-1] TRACE 
o.a.plc4x.java.spi.Plc4xNettyWrapper - No registered handler found for message 

Re: More Details regarding Scraper, Lack of Documentation

[Julian Feinauer]

<3 Thank you soo much Chris!

Julian

Am 06.07.20, 11:47 schrieb "Christofer Dutz" :

Hi all,

so I just wrote some documentation on the Scraper … it’s now available from 
here:
https://plc4x.apache.org/users/tools/scraper.html

I hope it helps and I hope even more that it’s accurate. If you happen to 
find some issues with it, please tell me about it.

Chris



Von: Stefano Bossi 
Antworten an: 
Datum: Freitag, 3. Juli 2020 um 17:56
An: 
Betreff: Re: More Details regarding Scraper, Lack of Documentation

Thanks for your effort.

I would be interest too in the documentation of the scraper; I will be stay 
tuned too.

Regards,
Stefano Bossi

On 03/07/2020 14:34, Christofer Dutz wrote:

Hi Wolfgang,



As the exact same question has come up multiple times In the last few days, 
I'll start writing it.



I was hoping the folks who wrote it would take care of this, but I 
understand there's a need for more documentation and we haven't been doing an 
extremely good job with that.



So please stay tuned.



Chris





Von: Wolfgang Huse 


Gesendet: Freitag, 3. Juli 2020 09:30

An: dev@plc4x.apache.org 


Betreff: More Details regarding Scraper, Lack of Documentation



Hello!

I have read a lot of Scraper-Functionality, as example in the 
Logstash-Plugin but I don’t find any high level Documentation.



How do I leverage scraper and what are the benefits compared to cyclic 
subscription of several values ?



In my use-case I need to fetch 16 Values from a S7-300 every 1second. What 
Is the best approach to do this ?



Mit freundlichen Grüßen – With kind regards



Wolfgang Huse

Re: Reading compress Data Block

[Julian Feinauer]

Hey Stefano,

you are welcome!
And if you have more PLC specific questions just come back here or ping me 
directly and we can give you some insights and probably best practices from our 
projects!

Best
Julian

Von: Stefano Bossi 
Antworten an: 
Datum: Sonntag, 5. Juli 2020 um 11:48
An: 
Cc: Daniele Rimoldi 
Betreff: Re: AW: Reading compress Data Block

Dear Julian,

thanks for your kind reply, I will study the video you post me and I will try 
to understand with the PLC expert if using "plain" block will be an issue or 
not.

Thanks,
Stefano Bossi

On 04/07/2020 23:13, Julian Feinauer wrote:

Dear Stefano,



first, welcome to this list and thank you for your kind words!



I, and many others here on the list would love to be able to read "optimized 
Data Blocks" from Siemens.

There are technical as well as legal reasons why we do not provide such a 
driver as of now.

I (and others as well) hope that we will be able to do it one day but so far we 
cant.



In our industrial applications we usually copy the block over to another 
unoptimized Block which we use as "exchange block".

Tim talks a little bit about that in the video we did together on PLC4X: 
https://www.youtube.com/watch?v=MIp_0OcDTr4

[https://i.ytimg.com/vi/MIp_0OcDTr4/maxresdefault.jpg]<https://www.youtube.com/watch?v=MIp_0OcDTr4><https://www.youtube.com/watch?v=MIp_0OcDTr4>

"Hands On": Reading Siemens S7 with 
PLC4X<https://www.youtube.com/watch?v=MIp_0OcDTr4><https://www.youtube.com/watch?v=MIp_0OcDTr4>

In our first (technical) webinar Julian Feinauer and Tim Mitsch as members of 
the Project Management Committee (PMC) of PLC4X will introduce the Apache 
PLC4X...

www.youtube.com<http://www.youtube.com>





If you have more questions we will try to help you with that or give you enough 
advice what to tell the PLC programmer guy : )



Best!

Julian







Von: Stefano Bossi

Gesendet: Samstag, 04. Juli 2020 15:31

Bis: dev@plc4x.apache.org<mailto:dev@plc4x.apache.org>

Betreff: Reading compress Data Block



Dear plc4x developer,



my name is Stefano and I am dealing with a project which is briefly reading 
data from a Siemens 1200 or 1500 and use these data to make some statistics.

I am writing a software in Java with your wonderful library but I didn't 
written the PLC software (some automation expert guy wrote that)

The PLC software has some DB I need to read but the PLC use "optimized Data 
Block".

Is there a way to read with PLC4X library an optimized Data Block ?



Many thanks for your work!



Regards,

Stefano Bossi

AW: Reading compress Data Block

[Julian Feinauer]

Dear Stefano,

first, welcome to this list and thank you for your kind words!

I, and many others here on the list would love to be able to read "optimized 
Data Blocks" from Siemens.
There are technical as well as legal reasons why we do not provide such a 
driver as of now.
I (and others as well) hope that we will be able to do it one day but so far we 
cant.

In our industrial applications we usually copy the block over to another 
unoptimized Block which we use as "exchange block".
Tim talks a little bit about that in the video we did together on PLC4X: 
https://www.youtube.com/watch?v=MIp_0OcDTr4
[https://i.ytimg.com/vi/MIp_0OcDTr4/maxresdefault.jpg]<https://www.youtube.com/watch?v=MIp_0OcDTr4>
"Hands On": Reading Siemens S7 with 
PLC4X<https://www.youtube.com/watch?v=MIp_0OcDTr4>
In our first (technical) webinar Julian Feinauer and Tim Mitsch as members of 
the Project Management Committee (PMC) of PLC4X will introduce the Apache 
PLC4X...
www.youtube.com


If you have more questions we will try to help you with that or give you enough 
advice what to tell the PLC programmer guy : )

Best!
Julian



Von: Stefano Bossi
Gesendet: Samstag, 04. Juli 2020 15:31
Bis: dev@plc4x.apache.org
Betreff: Reading compress Data Block

Dear plc4x developer,

my name is Stefano and I am dealing with a project which is briefly reading 
data from a Siemens 1200 or 1500 and use these data to make some statistics.
I am writing a software in Java with your wonderful library but I didn't 
written the PLC software (some automation expert guy wrote that)
The PLC software has some DB I need to read but the PLC use "optimized Data 
Block".
Is there a way to read with PLC4X library an optimized Data Block ?

Many thanks for your work!

Regards,
Stefano Bossi

Re: [RESULT] [VOTE] Rename our "master" branch to "release"

[Julian Feinauer]

Shouldn't rename or move do the trick?

J

Holen Sie sich Outlook für Android


From: Christofer Dutz 
Sent: Friday, July 3, 2020 6:19:25 PM
To: dev@plc4x.apache.org 
Subject: [RESULT] [VOTE] Rename our "master" branch to "release"

So the vote passes with

7 +1 votes (technically 5 binding and 2 non-binding)

I'll try to find out if it's just creating a new branch and deleting the old 
and then take care od actually doing it.

Chris


Am 30.06.20, 16:00 schrieb "Otto Fowler" :

 +1  because why not?

Most others are considering “main” or something, avoiding what you are (I
think) explicitly going for using release which as such meaning.

Can always change it back

On June 29, 2020 at 03:09:44, Christofer Dutz (christofer.d...@c-ware.de)
wrote:

Hi all,

we had already discussed that some days ago, but I’d like to formally have
you all vote on this … just to make it official.

I always thought “master”, “trunk” etc. were sub-ideal names as they don’t
explain what they are used for. We currently develop on “develop” and
therefore I propose to change the “master” branch to “release”.

While at it I would propose to call the release branches “release/x.y”
(instead of “rel/x.y”) and to tag the releases themselves with the full
three-digit numbers “release/x.y.z”).

This way I think we would have all in a very clean and concise naming
scheme where nobody has to ask himself, which branch is used for what.

Chris

Courses / Trainings for Open Source Projects

[Julian Feinauer]

Hi folks,

following up on Chris post here you know that we are starting something 
together (and also with other Partners from the community!).
Our next idea was to provide trainings and courses for the open source projects 
we list on the site (or even more) but we are not yet clear about the interest 
and demand.
And, as we are community driven this explicity INCLUDES free content and NOT 
only paid services. Thus I think ist reasonable to share the little survey we 
prepared on this list also.
The survey should help us to see if there is a demand or what exactly the 
community / communities may need and expect.

So we would be happy if you take the time to fill it out : )

Link to the survey: https://www.surveymonkey.de/r/CKZMTDL

Thanks already!
Julian

Re: S7 write test doubt

[Julian Feinauer]

And, as i shortly checked your company profile which looks pretty cool... if 
you like it, or use it, dont forget to enter your company on the adopters page 
: )

https://plc4x.apache.org/users/adopters.html

Julian

Am 02.07.20, 10:31 schrieb "Iñigo Angulo" :

Hi Chris,

Yes, using the 0.8.0-SNAPSHOT with the update you did the problem is solved 
now. 

Thank you for the help and the fast solution!

Iñigo

- 
Iñigo Angulo 

ZYLK.net :: consultoría.openSource 
Ribera de Axpe, 11 
Edificio A, modulo 201-203 
48950 Erandio (Bizkaia) 
+34 944272119 
-

- Mensaje original -
De: "Christofer Dutz" 
Para: "dev" 
Enviados: Miércoles, 1 de Julio 2020 13:18:34
Asunto: Re: S7 write test doubt

Hi all,

build passed locall, pushed the changes, build on ci passed  so you 
should be ready to give things a new try.

However keep in mind, if you built with 0.8.0-SNAPSHOT once today, please 
be sure to do a "mvn -U install" build or you won't get the update today.

Would be cool if you could reply if this helped.

Chris



Am 01.07.20, 12:30 schrieb "Julian Feinauer" :

Thanks both of you!
As I just wrote in Slack we can only grow and improve if we get 
feedback, Bug reports and usage scenarios.
And of course thanks Chris for that fast reply and fix <3

Julian

Am 01.07.20, 12:24 schrieb "Iñigo Angulo" :

Hi Chris,

No problem. I will keep track of the issue in Jira, and use the 
0.8.0-SNAPSHOT version.

Thank you for your help

iñigo

- 
Iñigo Angulo 

ZYLK.net :: consultoría.openSource 
Ribera de Axpe, 11 
Edificio A, modulo 201-203 
48950 Erandio (Bizkaia) 
+34 944272119 
-

- Mensaje original -
De: "Christofer Dutz" 
Para: "dev" 
Enviados: Miércoles, 1 de Julio 2020 12:06:28
Asunto: Re: S7 write test doubt

Hi Iñigo,

I will have to ask you to wait for a little while as you stumbled 
over a problem which goes a little deeper and is related to a major refactoring 
we did just before Christmas. I am pretty puzzled that no one ever noticed 
this, but I'll immediately start working on fixing this.

I'm tracking progress here: 
https://issues.apache.org/jira/browse/PLC4X-206


If that's done I would like to ask you to use the 0.8.0-SNAPSHOT 
till we've released the next version of PLC4X.

Chris


Am 01.07.20, 12:00 schrieb "Iñigo Angulo" :

Hi Chris,

Thanks for the fast answer!

I will keep your advice about not adding the cast to the 
values, and letting the driver do its work.

If you want me to try to reproduce any other test just let me 
know.

Iñigo


- 
Iñigo Angulo 

ZYLK.net :: consultoría.openSource 
Ribera de Axpe, 11 
Edificio A, modulo 201-203 
48950 Erandio (Bizkaia) 
+34 944272119 
-

- Mensaje original -
De: "Christofer Dutz" 
Para: "dev" 
Enviados: Miércoles, 1 de Julio 2020 11:48:48
Asunto: Re: S7 write test doubt

And let me give you a little more context ... with the INT type 
in S7 you happen to know that there an INT is a 16 Bit signed integer.

We wanted to abstract from that. Cause another PLC could define 
INT as 32 bit integer ... So you can generally just work with any numeric type 
and pass that in. The driver will inspect the value ranges for that particular 
protocol and give some sensible error messages (At least it should ;-) ).

But ... I just noticed that indeed I am seeing the same 
problems you are seeing and that my suggestion just causes a different error 
... I'll get working on fixing this right away.

I'm really a bit confused about this ... but it does prove that 
most people just care about reading ;-)

Will keep you and the others posted on any progress.

Chris



Am 01.07.20, 11:33 schrieb "Christofer Dutz" 
:

Hi Iñigo,

welcome to the party ... I really hope we'll be able to get 
you started asap ...

I just 

Re: [ApacheCon] Anyone planning on submitting something?

[Julian Feinauer]

Hi,

finally have to jump in (too much Beer Content in the morning).

We already had the Idea of doing "Beer Punkt Null" with a local brewery here 
(its a play of words as the 4.0 in german speaks pretty similar, 4 = vier which 
is roughly pronounced like "fear").

Do you know the https://web.craftbeerpi.com/?

Julian


Am 01.07.20, 19:59 schrieb "Cesar Garcia" :

Someday Chris, why not

I remember training in Mannheim where I had the opportunity to taste very
good German beers (Many beers!) ...

In the important thing. Why not have a solution for small breweries based
on open technologies, aka, Karaf + PLC4X + Graphana + CSS.

And so on ...

Best regards,


https://assets.new.siemens.com/siemens/assets/api/uuid:1d50c8bc9667e38e180a0ba36a3efa54f80e6d39/version:1529694435/us-cg-fb-tallgrass-brewery-and-custom-metalcraft-case-study.pdf

El mié., 1 jul. 2020 a las 12:57, Christofer Dutz (<
christofer.d...@c-ware.de>) escribió:

> Oh yeah ...
>
> But better not talk about it, better get together and drink it ;)
>
> Chris
>
>
> Am 01.07.20, 18:30 schrieb "Cesar Garcia" :
>
> Hi,
>
> It would be interesting to talk about automation of "CraftBeer".
>
> We are working in that direction,
>
> Best regards,
>
> El mié., 1 jul. 2020 a las 11:47, Christofer Dutz (<
> christofer.d...@c-ware.de>) escribió:
>
> > So would anyone here be interested in doing a pure PLC4X talk?
> >
> > I have been doing that for the past 3-4 years and would be happy to
> give
> > someone else the chance to do that.
> >
> > Of course, if no one wants to I could probably do it.
> >
> > Chris
> >
> >
> > Am 01.07.20, 16:06 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
> >
> > Hi all,
> >
> > as you might have gotten 1 or 2 … or 20 emails from Rich
> yesterday
> > regarding the virtual ApacheCon this year.
> >
> > We have 2 weeks to submit talks for the IoT tracks.
> >
> > Perhaps we should coordinate on what we want to submit?
> >
> >
> >   *   I know the StreamPipes folks already submitted something
> which
> > involves PLC4X which I would be helping out with.
> >   *   I was planning on something down the line of
> Home-Automation
> > built with Apache software … using PLC4X, IoTDB and perhaps Royale
> to build
> > some sort of  POC
> >
> > Any other ideas?
> >
> > Chris
> >
> >
> >
> >
>
> --
> *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: +58 414-760.98.95*
>
> *Hotline Técnica SIEMENS: 0800 1005080*
>
> *Email: support.aan.automat...@siemens.com
> *
>
>

-- 
*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: +58 414-760.98.95*

*Hotline Técnica SIEMENS: 0800 1005080*

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

Re: S7 write test doubt

[Julian Feinauer]

Thanks both of you!
As I just wrote in Slack we can only grow and improve if we get feedback, Bug 
reports and usage scenarios.
And of course thanks Chris for that fast reply and fix <3

Julian

Am 01.07.20, 12:24 schrieb "Iñigo Angulo" :

Hi Chris,

No problem. I will keep track of the issue in Jira, and use the 
0.8.0-SNAPSHOT version.

Thank you for your help

iñigo

- 
Iñigo Angulo 

ZYLK.net :: consultoría.openSource 
Ribera de Axpe, 11 
Edificio A, modulo 201-203 
48950 Erandio (Bizkaia) 
+34 944272119 
-

- Mensaje original -
De: "Christofer Dutz" 
Para: "dev" 
Enviados: Miércoles, 1 de Julio 2020 12:06:28
Asunto: Re: S7 write test doubt

Hi Iñigo,

I will have to ask you to wait for a little while as you stumbled over a 
problem which goes a little deeper and is related to a major refactoring we did 
just before Christmas. I am pretty puzzled that no one ever noticed this, but 
I'll immediately start working on fixing this.

I'm tracking progress here: 
https://issues.apache.org/jira/browse/PLC4X-206


If that's done I would like to ask you to use the 0.8.0-SNAPSHOT till we've 
released the next version of PLC4X.

Chris


Am 01.07.20, 12:00 schrieb "Iñigo Angulo" :

Hi Chris,

Thanks for the fast answer!

I will keep your advice about not adding the cast to the values, and 
letting the driver do its work.

If you want me to try to reproduce any other test just let me know.

Iñigo


- 
Iñigo Angulo 

ZYLK.net :: consultoría.openSource 
Ribera de Axpe, 11 
Edificio A, modulo 201-203 
48950 Erandio (Bizkaia) 
+34 944272119 
-

- Mensaje original -
De: "Christofer Dutz" 
Para: "dev" 
Enviados: Miércoles, 1 de Julio 2020 11:48:48
Asunto: Re: S7 write test doubt

And let me give you a little more context ... with the INT type in S7 
you happen to know that there an INT is a 16 Bit signed integer.

We wanted to abstract from that. Cause another PLC could define INT as 
32 bit integer ... So you can generally just work with any numeric type and 
pass that in. The driver will inspect the value ranges for that particular 
protocol and give some sensible error messages (At least it should ;-) ).

But ... I just noticed that indeed I am seeing the same problems you 
are seeing and that my suggestion just causes a different error ... I'll get 
working on fixing this right away.

I'm really a bit confused about this ... but it does prove that most 
people just care about reading ;-)

Will keep you and the others posted on any progress.

Chris



Am 01.07.20, 11:33 schrieb "Christofer Dutz" 
:

Hi Iñigo,

welcome to the party ... I really hope we'll be able to get you 
started asap ...

I just had a look at the code and PlcInteger does have the 
constructor ...

public PlcInteger(Short value) {
super(value.intValue(), true);
}

So I'll try to reproduce the problem ... but for now ... could you 
just remove the cast from your items?

builderWriter.addItem("mivariable-1", "%DB20:DBX6.7:BOOL", 
true); 
builderWriter.addItem("mivariable-4", "%DB20:DBW06.0:INT", 2);
builderWriter.addItem("mivariable-2", "%DB20:DBB06:BYTE", 0);

Cause PLC4X internally already ensures everything fits into the 
bounds and internally PLC4X handles the "(short) 2" as an "(int) 2" anyway ;-)


Chris




Am 01.07.20, 11:19 schrieb "Iñigo Angulo" :

Hi, 

I started doing some basic tests with the S7 protocol using a 
Siemens S7-300, and the latest 0.7.0 release. The tests consist of reading and 
writing several DB variables. I was able to read different datatypes, for 
instance: 

builder.addItem("mivariable-1", "%DB20:DBX05.0:BOOL"); 
builder.addItem("mivariable-4", "%DB20:DBW06:INT"); 

However, when I try to write the same memory addresses I only 
manage to write BOOL values, for example 

builderWriter.addItem("mivariable-1", "%DB20:DBX6.7:BOOL", 
true); //WORKS OK 
builderWriter.addItem("mivariable-4", "%DB20:DBW06.0:INT", 
(short)2); // FAILS 
builderWriter.addItem("mivariable-2", "%DB20:DBB06:BYTE", 
(byte)0); // FAILS 

I am unable to write any datatype different than BOOL. 

I am facing the following Error message: 

Exception in thread "main" 
org.apache.plc4x.java.api.exceptions.PlcRuntimeException: Error 

Re: [VOTE] Rename our "master" branch to "release"

[Julian Feinauer]

+1

Julian

Am 29.06.20, 09:09 schrieb "Christofer Dutz" :

Hi all,

we had already discussed that some days ago, but I’d like to formally have 
you all vote on this … just to make it official.

I always thought “master”, “trunk” etc. were sub-ideal names as they don’t 
explain what they are used for. We currently develop on “develop” and therefore 
I propose to change the “master” branch to “release”.

While at it I would propose to call the release branches “release/x.y” 
(instead of “rel/x.y”) and to tag the releases themselves with the full 
three-digit numbers “release/x.y.z”).

This way I think we would have all in a very clean and concise naming 
scheme where nobody has to ask himself, which branch is used for what.

Chris

Re: Serial port Connection

[Julian Feinauer]

Hey,

yes, its in the module scraper or plc-scraper.
Its easily configurable by yaml, json or programmatically.

Julian

Am 25.06.20, 10:30 schrieb "Niclas Hedhman" :

Thanks

Another question; is there any "loop" system that just continuously reads
until I tell it to stop?

On Thu, Jun 25, 2020, 15:16 Julian Feinauer 
wrote:

> Hi Nic,
>
> I have to dig in a bit later to give you good answers but AFAIR the
> connection can be left open and configuration should be as you wrote it.
> I also did some tests with it but that was some months ago...
>
> Hope to have some more information later.
>
> Julian
>
> Am 25.06.20, 05:58 schrieb "Niclas Hedhman" :
>
> Hi,
> IIUIC, the connection string for Serial Modbus would be something 
like;
>
>  modbus:serial:/dev/ttyS0?unit-identifier=7
>
> assuming I want to communicate with device with address 7.
>
> That would mean that I have one connection per device I talk to over a
> single serial port. Is that correct? (Personally, I would not made the
> device part of the connection abstraction, but realize that it is a 
bit
> late for that)
>
> Are there any issues here, regarding which connection has access to 
the
> port, or do I need to open and close the connection on each set of
> messages?
>
> Couldn't find info about this in the documentation.
>
>
> The serial port page is missing information on the configuration 
(data,
> parity, stop,...). The source code doesn't have the
> @ConfigurationParameter
> annotations, so will they still work or do I need to add that
> programmatically somehow?
>
>
> Cheers
> Niclas
>
>

Re: Serial port Connection

[Julian Feinauer]

Hi Nic,

I have to dig in a bit later to give you good answers but AFAIR the connection 
can be left open and configuration should be as you wrote it.
I also did some tests with it but that was some months ago...

Hope to have some more information later.

Julian

Am 25.06.20, 05:58 schrieb "Niclas Hedhman" :

Hi,
IIUIC, the connection string for Serial Modbus would be something like;

 modbus:serial:/dev/ttyS0?unit-identifier=7

assuming I want to communicate with device with address 7.

That would mean that I have one connection per device I talk to over a
single serial port. Is that correct? (Personally, I would not made the
device part of the connection abstraction, but realize that it is a bit
late for that)

Are there any issues here, regarding which connection has access to the
port, or do I need to open and close the connection on each set of messages?

Couldn't find info about this in the documentation.


The serial port page is missing information on the configuration (data,
parity, stop,...). The source code doesn't have the @ConfigurationParameter
annotations, so will they still work or do I need to add that
programmatically somehow?


Cheers
Niclas

Re: Driver S7. Step to 0.6.1

[Julian Feinauer]

Hi Cesar,

I wanted to take a look on your additions but I didnt find them in the rel/0.6 
branch.
Can you help me and point me to the place where you did your commits?

Thanks!
Julian

Am 06.06.20, 19:56 schrieb "Cesar Garcia" :

 Hello,

Julian, sorry for the inconvenience. Did you have the opportunity to browse
the information?

Grateful for any help or guidance on the subject,

Best regards,

El mié., 3 jun. 2020 a las 14:03, Julian Feinauer (<
j.feina...@pragmaticminds.de>) escribió:

> Hi Cesar,
>
> let me have a look tomorrow.
> Generally speaking every comitter should be able to do a release rather
> easy and if there are valuable improvements we are free to do one, so you
> have my +1 there.
>
> I can also offer you to RM the 0.6.1 release if you like?
>
> Julian
>
> Am 03.06.20, 18:59 schrieb "Cesar Garcia" :
>
> How are they?
>
> Some time ago, I put in Jira the points to be implemented for the S7
> driver
> version, in order to bring it to version 0.6.1.
>
> I am not an expert in Git, but according to your experience what would
> be
> the necessary steps to generate version 0.6.1? Is it feasible with the
> modifications? Can anyone on the team verify if this migration is
> feasible?
>
> For me it would be very useful to have this code consolidated in PLC4X
> since I have done a number of stability tests and new features.
>
> Thanking you for your guidance,
>
> Best regards,
> --
> *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: +58 414-760.98.95*
>
> *Hotline Técnica SIEMENS: 0800 1005080*
>
> *Email: support.aan.automat...@siemens.com
> *
>
>

-- 
*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: +58 414-760.98.95*

*Hotline Técnica SIEMENS: 0800 1005080*

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

Re: Karaf: Unable to find driver for protocol 'modbus'

[Julian Feinauer]

tep7) (60)
> > >
> > > The solution is to use the "BundleContext" with a filter and take the
> > field
> > > "org.apache.plc4x.driver.name " or  the field
> > > "org.apache.plc4x.driver.code" ( They are the same ). I think that is
> the
> > > way to do it in an OSGi environment.
> > >
> > > Loading the services with SPI is redundant, and it may happen that the
> > SPI
> > > service does not see the PlcDriver Services (typical OSGi problem).
> > >
> > > My grain of sand,
> > >
> > > Best regards,
> > >
> > >
> > >
> > >
> > > El lun., 8 jun. 2020 a las 15:41, Alessio Bernesco Làvore (<
> > > alessio.berne...@gmail.com>) escribió:
> > >
> > > > Thank you Julian,
> > > > i've tried to install th Aries SPI Bundle:
> > > >
> > > > 176 │ Active   │  80 │ 1.3.0  │ Apache Aries SPI Fly
> > Dynamic
> > > > Weaving Bundle
> > > >
> > > > But i'm still unable to resolve the drivers.
> > > >
> > > > Ale
> > > >
> > > > On Mon, Jun 8, 2020 at 8:13 PM Julian Feinauer <
> > > > j.feina...@pragmaticminds.de>
> > > > wrote:
> > > >
> > > > > Hi Alessio,
> > > > >
> > > > > if I remember correctly you need the Aries SPI Fly package loaded.
> > > > > In Plain PLC4X we use ServiceLoader to discover drivers.
> > > > > If you have nothing like Aries SPI Fly which mediates and
> "immitates"
> > > the
> > > > > ServiceLoader then you dont get a wiring between the DriverManager
> > and
> > > > the
> > > > > driver.
> > > > > But I don’t checked the lastst implementation to be honest.
> > > > >
> > > > > Perhaps @Robinet, Etienne can help?
> > > > >
> > > > > Julian
> > > > >
> > > > > Am 08.06.20, 20:00 schrieb "Alessio Bernesco Làvore" <
> > > > > alessio.berne...@gmail.com>:
> > > > >
> > > > > Hello everyone,
> > > > > i've created a simple class reading values from a ModBus PLC.
> > > > >
> > > > > I'm trying to use it inside Karaf, but at start the class is
> > unable
> > > > to
> > > > > find
> > > > > the modbus driver. I've compiled and installed in Karaf the
> > > > > "driver-s7-feature", with added the modbus driver:
> > > > >
> > > > > 
> > > > > http://karaf.apache.org/xmlns/features/v1.6.0
> "
> > > > > name="driver-s7-feature">
> > > > > 
> > > > > Implementation of the protocol adapters for
> > usage
> > > as
> > > > > Java
> > > > > library.
> > > > >
> > > >  mvn:org.apache.plc4x/plc4j-osgi/0.8.0-SNAPSHOT
> > > > > mvn:org.osgi/osgi.core/6.0.0
> > > > >
> > > >  mvn:org.apache.plc4x/plc4j-api/0.8.0-SNAPSHOT
> > > > >
> > > >  mvn:org.apache.plc4x/plc4j-spi/0.8.0-SNAPSHOT
> > > > > mvn:io.netty/netty-codec/4.1.47.Final
> > > > > 
mvn:io.netty/netty-common/4.1.47.Final
> > > > >
> >  mvn:io.netty/netty-transport/4.1.47.Final
> > > > >
>  mvn:io.netty/netty-resolver/4.1.47.Final
> > > > >
> > > >  mvn:commons-beanutils/commons-beanutils/1.9.4
> > > > >
>  mvn:commons-logging/commons-logging/1.2
> > > > >
> > > > > mvn:commons-collections/commons-collections/3.2.2
> > > > > mvn:com.github.jinahya/bit-io/1.4.3
> > > > > mvn:commons-codec/commons-codec/1.12
> > > > >
> > > > >
> mvn:org.apache.plc4x/plc4j-driver-s7/0.8.0-SNAPSHOT
> > > > >
> > > > >
> > > > >
> > >

Re: Karaf: Unable to find driver for protocol 'modbus'

[Julian Feinauer]

Hi Alessio,

if I remember correctly you need the Aries SPI Fly package loaded.
In Plain PLC4X we use ServiceLoader to discover drivers.
If you have nothing like Aries SPI Fly which mediates and "immitates" the 
ServiceLoader then you dont get a wiring between the DriverManager and the 
driver.
But I don’t checked the lastst implementation to be honest.

Perhaps @Robinet, Etienne can help?

Julian

Am 08.06.20, 20:00 schrieb "Alessio Bernesco Làvore" 
:

Hello everyone,
i've created a simple class reading values from a ModBus PLC.

I'm trying to use it inside Karaf, but at start the class is unable to find
the modbus driver. I've compiled and installed in Karaf the
"driver-s7-feature", with added the modbus driver:


http://karaf.apache.org/xmlns/features/v1.6.0;
name="driver-s7-feature">

Implementation of the protocol adapters for usage as Java
library.
mvn:org.apache.plc4x/plc4j-osgi/0.8.0-SNAPSHOT
mvn:org.osgi/osgi.core/6.0.0
mvn:org.apache.plc4x/plc4j-api/0.8.0-SNAPSHOT
mvn:org.apache.plc4x/plc4j-spi/0.8.0-SNAPSHOT
mvn:io.netty/netty-codec/4.1.47.Final
mvn:io.netty/netty-common/4.1.47.Final
mvn:io.netty/netty-transport/4.1.47.Final
mvn:io.netty/netty-resolver/4.1.47.Final
mvn:commons-beanutils/commons-beanutils/1.9.4
mvn:commons-logging/commons-logging/1.2
mvn:commons-collections/commons-collections/3.2.2
mvn:com.github.jinahya/bit-io/1.4.3
mvn:commons-codec/commons-codec/1.12
mvn:org.apache.plc4x/plc4j-driver-s7/0.8.0-SNAPSHOT

mvn:org.apache.plc4x/plc4j-driver-modbus/0.8.0-SNAPSHOT

mvn:org.apache.plc4x/plc4j-transport-tcp/0.8.0-SNAPSHOT

mvn:com.fasterxml.jackson.core/jackson-annotations/2.10.0
mvn:org.apache.commons/commons-lang3/3.9
mvn:io.netty/netty-buffer/4.1.47.Final
mvn:io.vavr/vavr/0.10.2
mvn:io.vavr/vavr-match/0.10.2



Inside Karaf i can find all the active bundles:

152 │ Active   │  80 │ 0.8.0.SNAPSHOT │ PLC4J: API
153 │ Active   │  80 │ 0.8.0.SNAPSHOT │ PLC4J: Driver: S7 (Step7)
154 │ Active   │  80 │ 0.8.0.SNAPSHOT │ PLC4J: OSGi
155 │ Active   │  80 │ 0.8.0.SNAPSHOT │ PLC4J: SPI
156 │ Active   │  80 │ 0.8.0.SNAPSHOT │ PLC4J: Transports: TCP
157 │ Active   │  80 │ 6.0.0.201403061837 │ osgi.core
164 │ Active   │  80 │ 1.0│ edgecontroller Bundle
165 │ Active   │  80 │ 0.8.0.SNAPSHOT │ PLC4J: Driver: Modbus

Anyway at startup the bundle doesnt find any driver:

2020-06-08T17:47:43,391 | INFO  | FelixStartLevel  | PlcDriverManager
  | 152 - org.apache.plc4x.plc4j-api - 0.8.0.SNAPSHOT |
Instantiating new PLC Driver Manager with class loader
sun.misc.Launcher$AppClassLoader@764c12b6
2020-06-08T17:47:43,391 | INFO  | FelixStartLevel  | PlcDriverManager
  | 152 - org.apache.plc4x.plc4j-api - 0.8.0.SNAPSHOT | Registering
available drivers...
2020-06-08T17:47:43,392 | ERROR | FelixStartLevel  | Activator
   | 164 - edgecontroller - 1.0.0 | Unable to find driver for
protocol 'modbus'

edgecontroller is my bundle, looking at the Karaf log the PlcDriverManager
is unable to find any driver.

I cannot understand were i'm failing, could anyone provide some insight?

Thank you,
Ale

Re: [Modbus] Querying Values from Holding Register

[Julian Feinauer]

In fact, when talking about modbus driver the question is rather if there is 
any code that was not changed between 0.6.0 and 0.7.0 : )

But we should have a closer look here.

Julian

Am 07.06.20, 18:55 schrieb "venki hadoop" :

Hi, after updating to 0.7 version am always getting value 0. Did you made
any code modifications after version update?

On Tuesday, June 2, 2020, udeho  wrote:

> Hi,
>
> This was a problem with my Maven configuration. I'm sorry, I'm very
> inexperienced with Maven.
> Anyway, reading values from the holding register now works fine with
> drivers of version 0.7.0.
>
> Best
> Tim
>
> -Original Message-
> From: Christofer Dutz 
> Sent: Montag, 1. Juni 2020 23:27
> To: udeho ; dev@plc4x.apache.org
> Subject: Re: [Modbus] Querying Values from Holding Register
>
> Hi,
>
> Are you perhaps mixing different versions? The api and driver versions
> should match.
>
> Chris
>
> 
> Von: udeho 
> Gesendet: Montag, 1. Juni 2020 14:58
> An: dev@plc4x.apache.org 
> Betreff: RE: [Modbus] Querying Values from Holding Register
>
> Hi,
>
> I've just tried to do the same as below with the newly released 0.7.0
> version.
> Unfortunately, I get the following errors:
>
> [main] INFO org.apache.plc4x.java.PlcDriverManager - Instantiating new
> PLC Driver Manager with class loader jdk.internal.loader.
> ClassLoaders$AppClassLoader@129a8472
> [main] INFO org.apache.plc4x.java.PlcDriverManager - Registering
> available drivers...
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/plc4x/java/spi/connection/GeneratedDriverBase
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(Unknown Source)
> at java.base/java.security.SecureClassLoader.defineClass(Unknown
> Source)
> at 
java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(Unknown
> Source)
> at java.base/jdk.internal.loader.BuiltinClassLoader.
> findClassOnClassPathOrNull(Unknown Source)
> at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Unknown
> Source)
> at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown
> Source)
> at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown
> Source)
> at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Unknown Source)
> at 
java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(Unknown
> Source)
> at 
java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(Unknown
> Source)
> at 
java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Unknown
> Source)
> at java.base/java.util.ServiceLoader$2.hasNext(Unknown Source)
> at java.base/java.util.ServiceLoader$3.hasNext(Unknown Source)
> at org.apache.plc4x.java.PlcDriverManager.(
> PlcDriverManager.java:53)
> at org.apache.plc4x.java.PlcDriverManager.(
> PlcDriverManager.java:44)
> at modbus.playground.main(playground.java:108)
> Caused by: java.lang.ClassNotFoundException: org.apache.plc4x.java.spi.
> connection.GeneratedDriverBase
> at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown
> Source)
> at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown
> Source)
> at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
> ... 19 more
>
> I added the new version as a dependency in Maven, but in the pom.xml  is
> also stated "Missing artifact org.apache.plc4x:plc4j-driver-
> modbus:jar:0.7.0".
> Used dependency in maven:
> 
>  org.apache.plc4x
>  plc4j-driver-modbus
>  0.7.0
> 
>
> Best
> Tim
>
> -Original Message-
> From: Christofer Dutz 
> Sent: Mittwoch, 20. Mai 2020 11:28
> To: dev@plc4x.apache.org
> Subject: Re: [Modbus] Querying Values from Holding Register
>
> Hi Tim,
>
> I guess you are using one of the "old generation" drivers (As you say it's
> working and the address seems to imply that).
> Perhaps you should either try the version 0.8.0-SNAPSHOT or wait for 2
> more days till we release the 0.7.0 version.
>
> In the 0.7.0 version we have completely deleted all existing drivers and
> replaced them by new ones.
> While at it I took the liberty of making the Modbus a little 

Re: [Proposal] Add a "commercial-support" page to the website.

[Julian Feinauer]

Hi Chris,

I think ist a good idea to model it as other projects do it BUT I don’t like 
the way this is setup.
One thing we take very high at apache is the "two hats" principle.
Thus I dislike that companies list "all" their employees that are comitters / 
pmcs like a "trophy", that feels un-apache-esque to me.

As you know probably better than myself at Apache we value the community and 
also non-pmc or non-committer contributors and contributions.
And thus I think a company can also have enough achievement or value to be 
listed without having a committer to present.

So I really object the name listing as this is too much "hat mixing" for me.

Julian

Am 05.06.20, 20:45 schrieb "Christofer Dutz" :

Hi all,

it seems we can rowspan in tables with asciidoc:

https://mrhaki.blogspot.com/2014/12/awesome-asciidoctor-span-cell-over-rows.html

So I would suggest to rowspan the logo name and the description of 
companies and to have the remaining columns one row per employee.

Chris


Am 05.06.20, 15:19 schrieb "Christofer Dutz" :

Hi Julian,

I had already sent an update ... I had initially just copied the text 
from the adopters page ... 
Well I thought that we would have multiple rows for multiple people 
involved and for each specify their involvement ... not sure if we should have 
a table in a table or similar.

    Chris


Am 05.06.20, 13:36 schrieb "Julian Feinauer" 
:

LGTM.

Although I suggest some changes in the table:
- More important than a company description would be what they 
offer (see e.g. Postgres Page: 
https://www.postgresql.org/support/professional_support/europe/)
- I would make it a bit smaler
- And Involvement level we should standardize a bit perhaps. You 
wrote "PMC Member ". But what does that mean? The company? No. One employee? 
Two?
- I would state "muliple Employees are PMC members" (which is also 
true for cc).

WDYT?

J

Am 05.06.20, 13:03 schrieb "Christofer Dutz" 
:

Hi all,

I have just added a new page to the PLC4X website, however it’s 
not yet linked in the navigation and therefore should remain invisible until 
Google indexes this email ;-)
It will be available soon from here (As soon as Jenkins is 
done):
https://plc4x.apache.org/users/commercial-support.html


What we have there is pretty inspired by the support page of 
the Apache Royale project:
https://royale.apache.org/royale-commercial-support/

However I used some different wording and a different proposal 
for a process to add entries.

I would suggest to use PRs as this way we can have the account 
of the PR creator on-file in git-blame. Which might come in handy if there 
should ever be problems.

We were told that in general everyone would be required to have 
him/herself added to that list no matter their involvement with the project. 
That’s why I decided to start with this in my proposal. I think with a column 
on the level of involvement should separate the true contributors from the 
others.

I think there were also voices that said that an alternative 
would be a PMC vote, but with very strict rules to how this vote should be done 
and all votes should have to be performed without any individual bias.

I asked the Royale project on how they dealt with entry 
requests to that list … they sort of laughed as they didn’t seem to really get 
any requests at all.

What’s your opinion on this … also the ASF’s opinion is greatly 
appreciated as we don’t want to do anything that could harm the ASF.

So I would really like to do it the way I proposed it, but 
that’s just my opinion … your other opinions are worth just as much (Well ok … 
the ASF’s opinion will probably weigh more ;-) )


Chris

Re: [Proposal] Add a "commercial-support" page to the website.

[Julian Feinauer]

LGTM.

Although I suggest some changes in the table:
- More important than a company description would be what they offer (see e.g. 
Postgres Page: https://www.postgresql.org/support/professional_support/europe/)
- I would make it a bit smaler
- And Involvement level we should standardize a bit perhaps. You wrote "PMC 
Member ". But what does that mean? The company? No. One employee? Two?
- I would state "muliple Employees are PMC members" (which is also true for cc).

WDYT?

J

Am 05.06.20, 13:03 schrieb "Christofer Dutz" :

Hi all,

I have just added a new page to the PLC4X website, however it’s not yet 
linked in the navigation and therefore should remain invisible until Google 
indexes this email ;-)
It will be available soon from here (As soon as Jenkins is done):
https://plc4x.apache.org/users/commercial-support.html


What we have there is pretty inspired by the support page of the Apache 
Royale project:
https://royale.apache.org/royale-commercial-support/

However I used some different wording and a different proposal for a 
process to add entries.

I would suggest to use PRs as this way we can have the account of the PR 
creator on-file in git-blame. Which might come in handy if there should ever be 
problems.

We were told that in general everyone would be required to have him/herself 
added to that list no matter their involvement with the project. That’s why I 
decided to start with this in my proposal. I think with a column on the level 
of involvement should separate the true contributors from the others.

I think there were also voices that said that an alternative would be a PMC 
vote, but with very strict rules to how this vote should be done and all votes 
should have to be performed without any individual bias.

I asked the Royale project on how they dealt with entry requests to that 
list … they sort of laughed as they didn’t seem to really get any requests at 
all.

What’s your opinion on this … also the ASF’s opinion is greatly appreciated 
as we don’t want to do anything that could harm the ASF.

So I would really like to do it the way I proposed it, but that’s just my 
opinion … your other opinions are worth just as much (Well ok … the ASF’s 
opinion will probably weigh more ;-) )


Chris

[jira] [Created] (PLC4X-203) GraalVM / Native Image support for PLC4J

[Julian Feinauer (Jira)]

Julian Feinauer created PLC4X-203:
-

 Summary: GraalVM / Native Image support for PLC4J
 Key: PLC4X-203
 URL: https://issues.apache.org/jira/browse/PLC4X-203
 Project: Apache PLC4X
  Issue Type: New Feature
Affects Versions: 0.70, 0.6.0
Reporter: Julian Feinauer
Assignee: Julian Feinauer


We would like to start native images / graal VM generally and want to have a 
look how compatible the PLC4X code is that we currently use.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Driver S7. Step to 0.6.1

[Julian Feinauer]

Hi Cesar,

let me have a look tomorrow.
Generally speaking every comitter should be able to do a release rather easy 
and if there are valuable improvements we are free to do one, so you have my +1 
there.

I can also offer you to RM the 0.6.1 release if you like?

Julian

Am 03.06.20, 18:59 schrieb "Cesar Garcia" :

How are they?

Some time ago, I put in Jira the points to be implemented for the S7 driver
version, in order to bring it to version 0.6.1.

I am not an expert in Git, but according to your experience what would be
the necessary steps to generate version 0.6.1? Is it feasible with the
modifications? Can anyone on the team verify if this migration is feasible?

For me it would be very useful to have this code consolidated in PLC4X
since I have done a number of stability tests and new features.

Thanking you for your guidance,

Best regards,
-- 
*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: +58 414-760.98.95*

*Hotline Técnica SIEMENS: 0800 1005080*

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

Re: [DRAFT] June Board Report

[Julian Feinauer]

Oh sorry, thats the hard part... let me see

- "Hands On": Reading Siemens S7 with PLC4X" was in German on April 1., and 
english was 9th of April
- (Industrial) IoT with Open Source - an Overview on "Monthly Industry 4.0 and 
IoT Meetup Stuttgart" was 21.04


Am 02.06.20, 09:20 schrieb "Christofer Dutz" :

Yeah ... that was what the "..." were for ... I didn't have the dates ... 
so if you could just list them here and I'll take them into the final version.


    Am 02.06.20, 09:18 schrieb "Julian Feinauer" :

Hi,

short notice.. I had two webinars about PLC4X (one in german one in 
english) and an appearance in the Stuttgart IoT Meetup (virtual) that we could 
also add.

J

Am 02.06.20, 09:17 schrieb "Christofer Dutz" 
:

Note: I’ll try to manually fill the ?? values in the stats as soon 
as I find out where to actually get the information or the reporting tool gets 
operational again. Also please add any online-talks you did.


## Description:
The mission of the Apache PLC4X project is creating a set of 
libraries for
communicating with industrial programmable logic controllers (PLCs) 
using a
variety of protocols but with a shared API.

## Issues:
None

## Membership Data:
Apache PLC4X was founded 2019-04-17 (a year ago)
There are currently 16 committers and 10 PMC members in this 
project.
The Committer-to-PMC ratio is exaclty 8:5.

Community changes, past quarter:
- Lukas Ott was added to the PMC on 2020-03-07
- Etienne Robinet was added as committer on 2020-03-22
- Otto Fowler was added as committer on 2020-04-30

## Project Activity:
- 0.7.0 was released on 2020-05-24

This quarter was pretty much dominated by us porting the last 
drivers to the
new generated drivers system. Also were we working hard on 
preparing things
for the 0.7.0 release which was our first release of the new 
generation of drivers.

Also did Chris start on his EU research funded project on porting 
PLC4X to the C
language with a final goal of running PLC4X drivers on Apache 
MyNewt.

This new initiative brought to the table a number of new 
contributors. Otto
who was invited to join the project was one of these.

In general the number of conference talks dropped to 0 in this 
period due to
COVID-19, but quite a number of online meetups have been talked 
about:


  *   IoTSydney: 2020-04-30
  *   …

We’re continuing to make good progress on most topics.

As it is one of the projects major barriers, that we usually aren’t 
allowed to
officially mention which companies are using PLC4X, we decided to 
add a
page of “adopters” to our website, where companies can get 
themselves
listed. We decided that the process should generally work via 
GitHub pull
requests as this way we would have the responsibility on file.

https://plc4x.apache.org/users/adopters.html

So far we haven’t had any requests to adding other companies.

## Community Health:

The community is in great shape and due to the increased diversity 
of the
codebase we have seen new folks join in on discussions or even 
joining the
project. We are hopeful that this trend will continue.

It also seems that in the past few weeks the inter-project 
cooperation has
increased. Here I’d especially like to point out the Apache 
StreamPipes and
the Apache IoTDB project.

Stats may be different, as at the time of creating the report the 
report tool
wasn't working so I had to compile them myself

- dev@plc4x.apache.org<mailto:dev@plc4x.apache.org> 87 
subscriptions (??% increase)
- ?? issues opened in JIRA, past quarter (??% increase)
- ?? issues closed in JIRA, past quarter (??% increase)
- ?? commits in the past quarter (??% increase)
- ?? code contributors in the past quarter (??% increase)
- ?? PRs opened on GitHub, past quarter (??% increase)
- ?? PRs closed on GitHub, past quarter (??% increase)
- 201 Github Stars (up by 29)
- 354 @ApachePLC4X Twitter account followers (up by 49)

Re: [DRAFT] June Board Report

[Julian Feinauer]

Hi,

short notice.. I had two webinars about PLC4X (one in german one in english) 
and an appearance in the Stuttgart IoT Meetup (virtual) that we could also add.

J

Am 02.06.20, 09:17 schrieb "Christofer Dutz" :

Note: I’ll try to manually fill the ?? values in the stats as soon as I 
find out where to actually get the information or the reporting tool gets 
operational again. Also please add any online-talks you did.


## Description:
The mission of the Apache PLC4X project is creating a set of libraries for
communicating with industrial programmable logic controllers (PLCs) using a
variety of protocols but with a shared API.

## Issues:
None

## Membership Data:
Apache PLC4X was founded 2019-04-17 (a year ago)
There are currently 16 committers and 10 PMC members in this project.
The Committer-to-PMC ratio is exaclty 8:5.

Community changes, past quarter:
- Lukas Ott was added to the PMC on 2020-03-07
- Etienne Robinet was added as committer on 2020-03-22
- Otto Fowler was added as committer on 2020-04-30

## Project Activity:
- 0.7.0 was released on 2020-05-24

This quarter was pretty much dominated by us porting the last drivers to the
new generated drivers system. Also were we working hard on preparing things
for the 0.7.0 release which was our first release of the new generation of 
drivers.

Also did Chris start on his EU research funded project on porting PLC4X to 
the C
language with a final goal of running PLC4X drivers on Apache MyNewt.

This new initiative brought to the table a number of new contributors. Otto
who was invited to join the project was one of these.

In general the number of conference talks dropped to 0 in this period due to
COVID-19, but quite a number of online meetups have been talked about:


  *   IoTSydney: 2020-04-30
  *   …

We’re continuing to make good progress on most topics.

As it is one of the projects major barriers, that we usually aren’t allowed 
to
officially mention which companies are using PLC4X, we decided to add a
page of “adopters” to our website, where companies can get themselves
listed. We decided that the process should generally work via GitHub pull
requests as this way we would have the responsibility on file.

https://plc4x.apache.org/users/adopters.html

So far we haven’t had any requests to adding other companies.

## Community Health:

The community is in great shape and due to the increased diversity of the
codebase we have seen new folks join in on discussions or even joining the
project. We are hopeful that this trend will continue.

It also seems that in the past few weeks the inter-project cooperation has
increased. Here I’d especially like to point out the Apache StreamPipes and
the Apache IoTDB project.

Stats may be different, as at the time of creating the report the report 
tool
wasn't working so I had to compile them myself

- dev@plc4x.apache.org 87 subscriptions (??% 
increase)
- ?? issues opened in JIRA, past quarter (??% increase)
- ?? issues closed in JIRA, past quarter (??% increase)
- ?? commits in the past quarter (??% increase)
- ?? code contributors in the past quarter (??% increase)
- ?? PRs opened on GitHub, past quarter (??% increase)
- ?? PRs closed on GitHub, past quarter (??% increase)
- 201 Github Stars (up by 29)
- 354 @ApachePLC4X Twitter account followers (up by 49)

Re: [PROPOSAL] Add better PLC4X-API support for Input Dialogs

[Julian Feinauer]

Hi,

totally agree with Chris position here.
This should be a first class citizen of the API!

@Phil: We could have a discussion about your / our current approaches and how 
we ideally could merge them together in the API

Julian

Am 30.05.20, 10:05 schrieb "Christofer Dutz" :

Hi Phillip,

In plc4x we always had the proposed functionality to browse remote plcs. 
This should be used to list remote resources. However this api part s never 
filed with life. I think we should start doing this. But I would consider this 
part a first class citizen in the api and not think of it as a utility function.

Chris

Von: Philipp Zehnder 
Gesendet: Freitag, 29. Mai 2020 23:40
An: d...@streampipes.apache.org 
Cc: dev@plc4x.apache.org 
Betreff: Re: [PROPOSAL] Add better PLC4X-API support for Input Dialogs

Hi,

this is a very cool idea and it would definitely improve the user 
experience for PLC4X.

Especially, the input validation and autocomplete for field addresses would 
be helpful for the StreamPipes integration.

Is it possible for some protocols to read a list of all available variables 
and if so, which ones?

So far, we decided to provide for each protocol an individual adapter. We 
thought this makes sense, because the naming and technical background of the 
protocols might differ.
(E.g. we provide a CSV upload for S7 PLCs, and I do not know if that would 
be possible for Modbus for example)
Does that make sense to you or do you have any alternative ideas?

Status of the PLC4X integration into StreamPipes:
Currently we support S7 and we are working on Modbus.
@Chris you implemented an adapter for BACnet/IP, right?

Any ideas or suggestions what we should integrate next?

Philipp


On 2020/05/29 08:50:18, Julian Feinauer  wrote:
> Hi folks,>
>
>
>
> this is an old Issue (see 
https://cwiki.apache.org/confluence/display/PLC4X/API+Extension+for+1.0).>
>
> What I generally would like to have is a way to communicate with the API 
/ the Driver without needing a Connection to e.g. „talk“ about the address 
input and probably also the connection parameters.>
>
>
>
> To give you an example, consider I want to have a mask where users could 
enter their url and address.>
>
> It would be nice to get all available protocols>
>
>
>
> Map map = driverManager.getAllRegisteredProtocols()>
>
>
>
> to show it in a drop down.>
>
> When user selects one I could generate a form to enter all connection 
parameters>
>
>
>
> driver.getConnectionParameters();>
>
>
>
> And then, when he wants to enter a Field Address I could go on like that 
and could do many things already with the Driver without hte need to have a 
Conneciton in Place already. Like:>
>
>
>
> driver.validate(„%DB.asdf“) <-- fails>
>
> driver.getValidatingRegex() <-- Could be used in my forms>
>
>
>
> or even get more detailed information, like an abstract address 
specification that I could use to build a form.>
>
> For S7 this could for example be>
>
>
>
> List driver.getAddressParts()>
>
>
>
> which could be something like>
>
>
>
> MemoryPart <- Enum-Like „DB, Q, I, ...“ and so on.>
>
>
>
> Tob e clear: I ONLY want to extend the current API and not change 
anything setup. So all APIs would stay in Place as is but this would help 
people who allow their users to input PLC4X Informations like we do or e.g. 
Streampipes (thus, added as CC here).>
>
>
>
> WDYT?>
>
>
>
> Julian>
>
>

[PROPOSAL] Add better PLC4X-API support for Input Dialogs

[Julian Feinauer]

Hi folks,

this is an old Issue (see 
https://cwiki.apache.org/confluence/display/PLC4X/API+Extension+for+1.0).
What I generally would like to have is a way to communicate with the API / the 
Driver without needing a Connection to e.g. „talk“ about the address input and 
probably also the connection parameters.

To give you an example, consider I want to have a mask where users could enter 
their url and address.
It would be nice to get all available protocols

Map map = driverManager.getAllRegisteredProtocols()

to show it in a drop down.
When user selects one I could generate a form to enter all connection parameters

driver.getConnectionParameters();

And then, when he wants to enter a Field Address I could go on like that and 
could do many things already with the Driver without hte need to have a 
Conneciton in Place already. Like:

driver.validate(„%DB.asdf“) <-- fails
driver.getValidatingRegex() <-- Could be used in my forms

or even get more detailed information, like an abstract address specification 
that I could use to build a form.
For S7 this could for example be

List driver.getAddressParts()

which could be something like

MemoryPart <- Enum-Like „DB, Q, I, ...“ and so on.

Tob e clear: I ONLY want to extend the current API and not change anything 
setup. So all APIs would stay in Place as is but this would help people who 
allow their users to input PLC4X Informations like we do or e.g. Streampipes 
(thus, added as CC here).

WDYT?

Julian

Re: S7 DATA_BLOCKS error

[Julian Feinauer]

Hi,

sorry for being late (ist still morning, right).
But @Joris Suppers you are missing the DB Number.
And I think we handle that pretty poorly with our exception.

It should be builder.addItem("value-4", "%DB{DB-Number}.DB1.4:INT");

Cheers!
Julian


Von: Joris Suppers 
Antworten an: "dev@plc4x.apache.org" 
Datum: Freitag, 29. Mai 2020 um 10:11
An: "dev@plc4x.apache.org" 
Cc: CloudPlug Development 
Betreff: S7 DATA_BLOCKS error

Hey Everyone,

We are currently testing the Siemens S7 connector (S7_1200) using the scrapper, 
and have come into an issue.

When testing the values as shown in the "Getting Started" page 
(https://plc4x.apache.org/users/plc4j/gettingstarted.html) we can successfully 
read the following values:
builder.addItem("value-1", "%Q0.4:BOOL");
builder.addItem("value-2", "%Q0:BYTE");
builder.addItem("value-3", "%I0.2:BOOL");

However when testing:
builder.addItem("value-4", "%DB.DB1.4:INT");
There is a Connection-Alias error:[cid:ii_karwzil70]

I have also tried the other syntax shown in 
"https://plc4x.apache.org/users/protocols/s7.html;  However, no luck.

We are using a 0.7.0-SNAPSHOT version, I have also tested with 0.7.0.

Is there something that still needs to be done? Any suggestions or comments 
would be appreciated.

Many thanks,
Joris




--
Joris Suppers | SOTEC | j.supp...@sotec.eu | T +49 
7033 5458 72


www.sotec.eu

SOTEC Software Entwicklungs GmbH + Co Mikrocomputertechnik KG

Calwer Straße 11, D-75395 Ostelsheim

Sitz Ostelsheim, Amtsgericht Stuttgart HRA 330821/HRB 330664, Geschäftsführer: 
Florian Holz

Re: [Modbus] Querying Values from Holding Register

[Julian Feinauer]

Indeed its not there yet.

@Christofer Dutz did you already release the maven repo?

Julian

Am 26.05.20, 10:23 schrieb "venki hadoop" :

Hi Chris,.
  Is  it will be part of maven central repo( I haven't
found 0.7 version in repository) or we have to build from source?

On Tuesday, May 26, 2020, Christofer Dutz  wrote:

> Hi Venki,
>
> Well I guess it would be an option ... I would give that a try and if you
> run into problems try with 0.6.0 in order to help track down if there's a
> regression.
>
> The Modbus driver is actually one we had an external driver in the past
> and which is now replaced by a full implementation by us.
>
> Chris
>
>
>
> Am 26.05.20, 09:36 schrieb "venki hadoop" :
>
> Hi Chris,.
> Shall we use 0.7.0 version to resolve this issue.
>   Regards,
>
> On Wednesday, May 20, 2020, Christofer Dutz  >
> wrote:
>
> > Hi Tim,
> >
> > I guess you are using one of the "old generation" drivers (As you
> say it's
> > working and the address seems to imply that).
> > Perhaps you should either try the version 0.8.0-SNAPSHOT or wait for
> 2
> > more days till we release the 0.7.0 version.
> >
> > In the 0.7.0 version we have completely deleted all existing drivers
> and
> > replaced them by new ones.
> > While at it I took the liberty of making the Modbus a little more
> robust.
> >
> > So it would be great if you could give us feedback if your problem
> goes
> > away magically when updating to these driver versions.
> >
> > Chris
> >
> >
> >
> > Am 20.05.20, 10:24 schrieb "udeho" :
> >
> > Hi all,
> >
> > I have tried to query values from the holding register of a
> simulated
> > modbus device and process them as integer using the following code:
> > // read integer / holding register
> > PlcDriverManager driverManager = new
> > PlcDriverManager();
> > String conString = "modbus:tcp://localhost";
> > PlcConnection plcCon =
> driverManager.getConnection(
> > conString);
> > PlcReadRequest.Builder builder =
> > plcCon.readRequestBuilder();
> > builder.addItem("value",
> "readholdingregisters:1");
> > PlcReadRequest readRequest = 
builder.build();
> > PlcReadResponse resp =
> readRequest.execute().get();
> >
> > This runs well, but when I try to handle the result as integer
> (using
> > resp.getInteger("value")) I always get null as result no matter
> what's in
> > the register.
> > For Boolean values in the coil this works without any problem
> (using
> > getBoolean() of course).
> > Another approach I tried is using the getAllByteArrays("value");
> > command, but I haven't found a way to get the returned collection of
> byte
> > arrays into integers.
> >
> > Can you give me an indication of what my problem may be or what
> I'm
> > doing wrong?
> >
> > Thank you very much in advance!
> >
> > Best
> > Tim
> >
> >
>
>

Re: [DISCUSS] Users page

[Julian Feinauer]

Hi,

yes. Just wanted to add my point here : )
But of course some feedback is very welcome about best practices.

Perhaps we could even hold a formal vote to give it the necessary attention on 
the list?

Julian

Am 26.05.20, 09:16 schrieb "Christofer Dutz" :

Hi Julian,

I like the name "adopters" ... sounds better than "users" especially if 
it's on the "users" part of the website.

I would like some feedback from some other ASF folks as in the past they 
have brought up concerns and I would prefer to hear if they are ok with this.

    Chris

Am 26.05.20, 09:07 schrieb "Julian Feinauer" :

Hi Chris,

thanks for tackling this.
I really like it and in fact I woul dprobably place it even more 
prominent.
I like how eclipse IoT Working Group did it:

https://iot.eclipse.org/adopters/

I see no reason why this would not comply with ASF policy.

Julian

Am 25.05.20, 21:43 schrieb "Christofer Dutz" 
:

Hi all,

I think we discussed this multiple times but never actually 
continued. So I took the liberty of adding a new page to our website:
https://plc4x.apache.org/users/users.html

However this page isn’t linked in the navigation as I want to 
discuss this first.

It’s the plan to allow any company to be listed there. The 
mechanism on how to get added is by providing a PR. This way we have someone 
who is in git-blame and which we can say is responsible for having a company 
added.

I updated all links to be “nofollow” links and to open new browser 
tabs.

Would such a page be in-line with the ASF policies?

Chris

Re: [DISCUSS] Users page

[Julian Feinauer]

Hi Chris,

thanks for tackling this.
I really like it and in fact I woul dprobably place it even more prominent.
I like how eclipse IoT Working Group did it:

https://iot.eclipse.org/adopters/

I see no reason why this would not comply with ASF policy.

Julian

Am 25.05.20, 21:43 schrieb "Christofer Dutz" :

Hi all,

I think we discussed this multiple times but never actually continued. So I 
took the liberty of adding a new page to our website:
https://plc4x.apache.org/users/users.html

However this page isn’t linked in the navigation as I want to discuss this 
first.

It’s the plan to allow any company to be listed there. The mechanism on how 
to get added is by providing a PR. This way we have someone who is in git-blame 
and which we can say is responsible for having a company added.

I updated all links to be “nofollow” links and to open new browser tabs.

Would such a page be in-line with the ASF policies?

Chris

[jira] [Created] (PLC4X-199) Request future never returns when ResponseCode not OK for Siemes S7

[Julian Feinauer (Jira)]

Julian Feinauer created PLC4X-199:
-

 Summary: Request future never returns when ResponseCode not OK for 
Siemes S7
 Key: PLC4X-199
 URL: https://issues.apache.org/jira/browse/PLC4X-199
 Project: Apache PLC4X
  Issue Type: Bug
  Components: Driver-S7
Affects Versions: 0.7.0
Reporter: Julian Feinauer
Assignee: Julian Feinauer


When a request is made against a PLC which returns a ResponseCode other than OK 
the future will never complete and hang forever.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] Apache PLC4X 0.7.0 RC2

[Julian Feinauer]

Hi,

my Vote is +1 (binding).

I did.
- Downloaded all artefacts - OK
- Verify Signature - OK
- Verify Hash - OK
- Verify existence and Content fo LICENSE, NOTICE, README, RELEASE_NOTES - OK
- No unexpected binaries - OK
- Build (macOS) - OK

Julian

Am 21.05.20, 11:05 schrieb "Dominik Riemer" :

Hi,

+1 (non-binding)

I checked:

Download all staged artifacts - OK
Verify the signature is correct - OK
Verify the SHA512 hashes - OK
Verify the existence and content of LICENSE, NOTICE, README, RELEASE_NOTES- 
OK
Search for SNAPSHOT references - OK
Build - OK

Some comments: 
The RELEASE_NOTES file 
(https://dist.apache.org/repos/dist/dev/plc4x/0.7.0/rc2/RELEASE_NOTES) states 
"Apache PLC4X 0.7.0-SNAPSHOT" in the first line and for the previous release 
0.6.0 the headline is " (Unreleased) Apache PLC4X 0.6.0-SNAPSHOT"

I was using the Docker-based build and had a few minor problems:

- I had to change the base image to use Java 11: FROM azul/zulu-openjdk:11 
as build
- I got two compile errors in plc4j-hello-integration-iotdb:

[ERROR] Failed to execute goal 
com.offbytwo.maven.plugins:maven-dependency-plugin:3.1.1.MDEP568:go-offline 
(default-cli) on project plc4j-hello-integration-iotdb: Failed to resolve 
artifact: com.sun.istack:istack-commons-runtime:jar:3.0.6:compile: Could not 
find artifact com.sun.istack:istack-commons-runtime:jar:3.0.6 in central 
(https://repo.maven.apache.org/maven2) -> [Help 1]

[ERROR] Failed to execute goal 
com.offbytwo.maven.plugins:maven-dependency-plugin:3.1.1.MDEP568:go-offline 
(default-cli) on project plc4j-hello-integration-iotdb: Failed to resolve 
artifact: com.sun.xml.fastinfoset:FastInfoset:jar:1.2.14:compile: Could not 
find artifact com.sun.xml.fastinfoset:FastInfoset:jar:1.2.14 in central 
(https://repo.maven.apache.org/maven2) -> [Help 1] 

I excluded this module to get the build working.

Probably this can be considered minor as it only affects the Docker build.

Dominik


-Original Message-
From: Robinet, Etienne <43...@etu.he2b.be> 
Sent: Thursday, May 21, 2020 9:23 AM
To: dev@plc4x.apache.org
Subject: Re: [VOTE] Apache PLC4X 0.7.0 RC2

+1

Checklist:
- Download all staged artifacts under the url specified in the release vote 
email
- Verify the signature is correct
- Check if the signature references an Apache email address.
- Verify the SHA512 hashes
- Unzip and verify existence and content of LICENSE, NOTICE, README, 
RELEASE_NOTES
- Run RAT externally to ensure there are no surprises (also 7 unknown
Licences)


apache-plc4x-0.7.0/build-utils/protocol-base-mspec/src/main/antlr4/org/apache/plc4x/plugins/codegenerator/language/mspec/expression/Expression.g4


apache-plc4x-0.7.0/build-utils/protocol-base-mspec/src/remote-resources/UNLICENSE
  apache-plc4x-0.7.0/licenses/UNLICENSE
  apache-plc4x-0.7.0/plc4j/examples/hello-webapp/client/asconfig.json
  apache-plc4x-0.7.0/plc4j/tools/scraper/src/test/resources/config.json
  apache-plc4x-0.7.0/sandbox/code-gen/src/main/resources/example.json
  apache-plc4x-0.7.0/sandbox/code-gen/src/main/resources/example2.json
-Search for "SNAPSHOT" and "Copyright" reference
- Build the project according to the information in the README.md 
file(./mvnw -P with-sandbox install)

OS: Windows 10 Pro.
Java: OpenJDK 11.02
Maven: 3.6.0


Le mer. 20 mai 2020 à 08:08, Christofer Dutz  a 
écrit :

> +1 Binding
>
> Chris
>
>
> [OK] Download all staged artifacts under the url specified in the 
> release vote email into a directory we’ll now call download-dir.
> [OK] Verify the signature is correct: Additional Apache tutorial on 
> how to verify downloads can be found here.
> [OK] Check if the signature references an Apache email address.
> [OK] Verify the SHA512 hashes:
> [OK] Unzip the archive:
> [OK] Verify the existence of LICENSE, NOTICE, README, RELEASE_NOTES 
> files in the extracted source bundle.
> [OK] Verify the content of LICENSE, NOTICE, README, RELEASE_NOTES 
> files in the extracted source bundle.
> [OK] [RM] Verify the staged source README, RELEASE_NOTE files 
> correspond to those in the extracted source bundle.
> [OK] [RM] Run RAT externally to ensure there are no surprises.
> [OK] Search for SNAPSHOT references: Only found in commented out 
> dependencies and disabled parts of the project (Parts not yet deleted) 
> [OK] Search for Copyright references, and if they are in headers, make 
> sure these files containing them are mentioned in the LICENSE file: No 
> findings in a bad form, however it seems some files use other apache 
> headers as others (Some files have apache headers containing the word 
> "copyright" but most don't) [OK] Build the project according to the 
> information in the README.md file [OK] [RM] Build the 

Re: [DISCUSS] Apache PLC4X 0.7.0 RC1

[Julian Feinauer]

Hi,

I would ship the RC as I fully agree with your argumentation.
My opinion.

Julian

Am 19.05.20, 08:20 schrieb "Christofer Dutz" :

Hi all,

so I tracked down the problem Otto found.

It seems that the setting we are using in surefire and failsafe to allow 
illegal access, is unknown to Java 8.
The strange thing is that we have this setting in all modules and only in 
the mspec module it seems to be causing problems.
I moved the setting into a self-activating profile that enables itself for 
java 9 and higher. Now I can build with Java 8.

So in the future this problem is solved.

So now the question ... should we cancel the RC or continue?

As this issue has absolutely no effect on the end-product and only occurs 
at build time if using Java 8, I would feel comfortable with treating it as a 
documentation issue and just release the next version 0.8.0 a lot sooner than 
0.7.0.

But I'll leave that up to you.

Chris



Am 16.05.20, 09:05 schrieb "Christofer Dutz" :

Hi folks,

let’s take discussions here :-)

One thing I would like to point out, is that you should enable the 
“with-sandbox” profile as one of the examples references a driver in the 
sandbox which it can’t find if you don’t enable that.

Chris

Re: [VOTE] Apache PLC4X 0.7.0 RC1

[Julian Feinauer]

Hi,

my vote is +1 (binding).

I did:
- Download all artefacts
- Checked Signatures and Hashes
- Checked staged README and RELEASE NOTES is similar to Version in Repo
- Checked content of README, RELEASE_NOTES, NOTICE and LICENSE (Minor: 
References 0.7.0 as Snapshot)
- Checked no unexpected binaries
- Build project according to docu (macOS)

Thank you for the work Chris, well done!
Julian

Am 16.05.20, 23:58 schrieb "Cesar Garcia" :

Hi Chris,

1+

1. Download all staged artifacts under the url specifie, OK
2. Verify the signature is correct , OK
3. Check if the check is successful. OK
4. Check if the signature references an Apache email address. OK
5. Verify the SHA512 hashes: OK
6. Verify the existence of LICENSE, NOTICE, README, RELEASE_NOTES files in
the extracted source bundle. OK
7. Run RAT externally to ensure there are no surprises. OK, but 7 Unknown
Licenses.
8. Search for SNAPSHOT references: OK
./plc4j/drivers/ads/pom.xml
./plc4j/examples/dummy-driver/pom.xml
./plc4j/examples/hello-webapp/client/pom.xml
./plc4j/examples/hello-webapp/pom.xml
./plc4j/examples/hello-webapp/webapp/pom.xml
./plc4j/examples/pom.xml
./plc4j/integrations/apache-camel/pom.xml
./plc4j/integrations/apache-edgent/pom.xml
./plc4j/integrations/apache-kafka/pom.xml
./plc4j/integrations/apache-nifi/nifi-plc4x-nar/pom.xml
./plc4j/integrations/logstash-plugin/pom.xml
./plc4j/karaf-features/camel/pom.xml
./plc4j/karaf-features/eip/pom.xml
./plc4j/karaf-features/karaf-itest/pom.xml
./plc4j/karaf-features/pom.xml
./plc4j/karaf-features/s7/pom.xml
./plc4j/protocols/ads/pom.xml
./plc4j/protocols/benchmarks/pom.xml
./plc4j/protocols/delta-v/pom.xml
./plc4j/protocols/pom.xml

9. Search for Copyright references, and if they are in headers, make sure
these files containing them are mentioned in the LICENSE file., OK
10. Build the project according to the information in the README.md file.
Using: ">mvn -P with-sandbox install", OK


OS: Windows 10 Pro.
Java: openjdk 11.0.4 2019-07-16
Maven: openjdk 11.0.4 2019-07-16



El vie., 15 may. 2020 a las 12:52, Christofer Dutz (<
christofer.d...@c-ware.de>) escribió:

> Apache PLC4X 0.7.0 has been staged under [2] and it’s time to vote
> on accepting it for release. All Maven artifacts are available under [1].
> Voting will be open for 72hr.
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1
> are required to pass.
>
> Release tag: release/0.7.0
> Hash for the release tag: c06b73473383405a550ac4f4cee7dd8636325a35
>
> Per [3] "Before voting +1 PMC members are required to download
> the signed source code package, compile it as provided, and test
> the resulting executable on their own platform, along with also
> verifying that the package meets the requirements of the ASF policy
> on releases."
>
> You can achieve the above by following [4].
>
> [ ]  +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [4])
> [ ]  -1 reject (explanation required)
>
>
> [1] https://repository.apache.org/content/repositories/orgapacheplc4x-1027
> [2] https://dist.apache.org/repos/dist/dev/plc4x/0.7.0/rc1
> [3] https://www.apache.org/dev/release.html#approving-a-release
> [4] https://plc4x.apache.org/developers/release/validation.html
>
>
>

-- 
*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: +58 414-760.98.95*

*Hotline Técnica SIEMENS: 0800 1005080*

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

Re: Missing Drivers in fat JAR

[Julian Feinauer]

Hey,

this is an issue that multiple people here faced... (cdutz, sruehl, myself at 
least).
Can we do anything to document that better?
I guess not?

Julian

Am 14.05.20, 15:59 schrieb "Wolfgang Huse" :

Thanks a lot Chris...

There was the Service transformer missing. I only had used the 
ManifestResourceTransformer (which is included in the pom.xml in the 
examples-folder). The Service transformer is inherited from the project root 
pom.xml

Works now as expected

Mit freundlichen Grüßen – With kind regards

Wolfgang Huse

On 5/14/20, 2:11 PM, "Christofer Dutz"  wrote:

Hi Wolfgang,

if you are speaking about a project of yours where you are using the 
shade plugin, then you need to add a transformer to your plugin configuration.
Every driver has a 
META-INF/services/org.apache.plc4x.java.api.PlcDriver file, which lists that 
particular driver.
If you run the shade plugin without any transformer only one of these 
are packaged in the jar the others are omitted. 
That's why you have only one driver availale.

In order to fix this please update your plugin configuration like we 
did in the examples:

  
org.apache.maven.plugins
maven-shade-plugin

  
generate-uber-jar
package

  shade


  


  ${app.main.class}

  

  

*:*

  META-INF/*.SF
  META-INF/*.DSA
  META-INF/*.RSA

  


  

  

Hope that helps.


Chris



  

Am 14.05.20, 10:31 schrieb "Wolfgang Huse" :

Hi,
i am builing a fat jar with maven shade plugin but if I run the 
application an error occurs:

17:32.651 [main] INFO  o.apache.plc4x.java.PlcDriverManager - 
Instantiating new PLC Driver Manager with class loader 
jdk.internal.loader.ClassLoaders$AppClassLoader@55054057
10:17:32.653 [main] INFO  o.apache.plc4x.java.PlcDriverManager - 
Registering available drivers...
10:17:32.658 [main] INFO  o.apache.plc4x.java.PlcDriverManager - 
Registering driver for Protocol modbus (Modbus)
Exception in thread "main" 
org.apache.plc4x.java.api.exceptions.PlcConnectionException: Unable to find 
driver for protocol 'opcua'

Any hint how to include the needed classes for the drivers ?

Mit freundlichen Grüßen – With kind regards

Wolfgang Huse

Re: [PLC4C] Summary of API discussion on slack

[Julian Feinauer]

You have my +1 there : )

Am 12.05.20, 12:15 schrieb "Christofer Dutz" :

Hi all,

so I think we have the C-API in a quite nice state now and I'd like to 
merge the c-api branch back to develop ... it shouldn't have any negative 
effect on the rest of the build. Just wanted to ask if you are cool with me 
doing that.

Chris



Am 06.05.20, 11:05 schrieb "Christofer Dutz" :

Hi all,

thanks to Otto's efforts now the C-API has it's equivalent to PlcValues 
...
Also has the API sort of matured to some state I think we no longer 
have to work on the "feature/c-api" branch and would like to merge this back to 
develop.

In the end it's still in the sandbox alongside a lot of unfinished 
stuff ... so we're not treating it as a first-class citizen yet.

What do you think?

Chris



Am 04.05.20, 19:44 schrieb "Christofer Dutz" 
:

Ok ... after several days of working in the garden a new day with 
updates on PLC4C :-)

So today I managed to finish and commit some changes that perform a 
full roundtrip of connection, read, disconnect using the "simulated" driver.
Right now that only parses the address strings and returns a random 
int for every item .. this is not yet on-par with the java version of the 
simulated driver, but more a preview of the API we are planning to use for 
PLC4C.

All asynchronous operations: 
- Connect
- Read
- Disconnect

Are implemented using something we call "system-tasks" which I 
described in my last summary.

All seems to be working nicely and I really like the structure of 
the code ... I know it will need quite a bit of cleaning up and I would be 
super grateful, if some C professionals could review what I have created. 
Constructive feedback is essential here for the continued work on this.

Chris




Am 29.04.20, 19:57 schrieb "Christofer Dutz" 
:

Aaaand another update :-)

So today I continued adding code-flesh to the empty API body.

I implemented two basic data-structures: List and Queue 
(Noticing at the end that my queue isn't even needed).

Starting from today the functionality for: connecting, reading, 
writing, etc. is implemented by callback functions generating so-called 
system_tasks.

These are data-structures consisting of 4 properties:
- a state-machine-function callback
- an int representing the state-machine state the task is 
currently in
- a pointer to a context data-structure (The state-machine 
controls what's in there)
- a completed-flag that tells the system if a task is finished

So now if a driver for example is asked to connect, it 
generates a system-task and that's added to the task-list.

Then as soon as the system_loop function is called, this 
function goes through the list of queued system-tasks and for each calls the 
state-machine function if comes with and passes in the task as an argument.

In the end the system loop checks If after executing the 
state-machine-function the task is marked as "completed" ... if it is it 
removes this task form the queue and continues with the next task in the list.

The cool thing is that this way we can even ensure the 
system_loop function doesn't hog too much processing time ... so we could give 
the loop a maximum execution time and as soon as that's exceeded the function 
returns and the following tasks will be executed the next time the system_loop 
function is called. In this case I would probably change the task-list into a 
ring data-structure.

Right now my example hello world program if correctly loading 
the "simulated" driver and a "dummy" transport and correctly connecting using 
the above mechanisms. 

Guess tomorrow I'll be writing string-parsers again to continue 
working on implementing the read/write operations on the simulated-driver.

So far the update from today,

Chris


Am 28.04.20, 19:38 schrieb "Christofer Dutz" 
:

Hi folks,

even if this wasn't discussed as much as the other things 
we discussed, I still think it's important.

So I was a strong advocate of the "promised land" ... I 
wanted to use promises and register callbacks for async execution.
Theoretically this I cool ... however I had to notice it's 
cool as long as you have someone cleaning up for you.
In most of the languages I encountered heavy usage of this 
pattern there are garbage collection mechanisms in place and then this is a 
great feature.

In C however this is not the case. Here you have to 
manually free 

Re: PlcConnectionException

[Julian Feinauer]

Hi Tim,

sorry fort he issue.
Indeed, the URL of your connection string is wrong (because our docu is really 
bad).
You should try: modbus:tcp://localhost

Hope that helps!

Julian

Am 11.05.20, 09:55 schrieb "udeho" :

Dear PLC4X-Community,

I tried to do my first steps with modbus in PLC4X using the modbus 
simulator referenced in your getting-started guide.
Following your instructions, I executed the following code to establish a 
connection:

public static void main(String [] args) {

   String conString = "modbus://localhost";

   try(PlcConnection plcCon = new
PlcDriverManager().getConnection(conString)){

   System.out.println("Hello 
Modbus");
   }

   catch (Exception e) {
   e.printStackTrace();
   }
}

Unfortunately, I get the following error:

org.apache.plc4x.java.api.exceptions.PlcConnectionException: Connection url 
doesn't match the format 'modbus:{type}//{port|host}'
at

org.apache.plc4x.java.modbus.ModbusPlcDriver.connect(ModbusPlcDriver.java:69)
at

org.apache.plc4x.java.PlcDriverManager.getConnection(PlcDriverManager.java:72)
at plc4x.playground.main(playground.java:12)

Could you please give me a hint what I'm doing wrong or what is missing?
As far as I can see, I did it the same way you proposed in your virtual 
modbus section.

Thanks a lot!

Best regards
Tim

Re: SPI Module - OSGi Bundle

[Julian Feinauer]

 so take my
> >>> recommendations into consideration or throw them away. I just got the
> >>> impression that you didn't really get what I suggested.
> >>>
> >>>
> >>> // Niclas
> >>>
> >>>
> >>>
> >>> On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki 
> >> wrote:
> >>>
> >>>> Hey Etienne, that's awesome piece of work. I can test it! :-)
> >>>>
> >>>> I believe that's what Etienne code does it in a valid OSGi way. And I
> >> do
> >>>> believe not because he mentioned me by name, but due to below
> >>>> argumentation.
> >>>>
> >>>> Proposed code uses extender pattern to grab specific 
META-INF/services
> >>>> entries and register them in OSGi service registry. If you will take 
a
> >>>> look on following line:
> >>>>
> >>>>
> >>
> 
https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> >>>> you will find that bundle is an jar which changes state to ACTIVE.
> >>>> Additionally that bundle classloader is used to find services and 
that
> >>>> bundle context is used to register services. In the end service which
> >>>> appears looks like one registered by driver/transport module.
> >>>>
> >>>> The main point for above implementation is basic - getting the
> standard
> >>>> PLC4X driver JAR working in OSGi without forcing it to knowing too
> much
> >>>> about OSGi. Driver needs to ship manifest with import/export
> statements
> >>>> and that's it. Additionally driver does not have to have a XML
> >>>> descriptor which registers service. Quite many third parties might be
> >>>> supplying drivers without any or with limited knowledge of OSGi.
> >>>> Do drivers have to be a service? Well, it they can still be a valid
> >> OSGi
> >>>> service, registered using any other way! OSGi aware driver manager
> uses
> >>>> OSGi services instead of static list own classloader to find
> >>>> META-INF/services entries:
> >>>>
> >>>>
> >>
> 
https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
> >>>>
> >>>> JDBC JARs are handled in such a way already in pax-jdbc. Take a look
> >> here:
> >>>>
> >>>>
> >>
> 
https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc/src/main/java/org/ops4j/pax/jdbc/impl/Activator.java#L72
> >>>> Same or very similar code can be found in apache-camel, which brought
> >>>> hundreds of components to OSGi, so I believe their way can be seen as
> >>>> high level guide.
> >>>> What Etienne did is a pattern implementation.
> >>>>
> >>>> With regard to capabilities/requirements - this is a resolver puzzle.
> >> It
> >>>> relies on additional information. As an unbaptized, non-religious 
osgi
> >>>> guy (I take it as a tool and not act of faith), I often do skip it. I
> >> do
> >>>> find it useful, however quite often problematic and hard to 
understand
> >>>> (yet another non-trivial syntax in manifest to follow). On older
> >>>> runtimes capabilities are not even considered. For never ones there
> are
> >>>> already existing namespaces:
> >>>> https://www.osgi.org/capability-namespaces-reference/
> >>>> including, one for services:
> >>>>
> >>
> 
https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html
> >>>> My point is that capabilities are used to attest that runtime will
> >>>> consist all necessary things in place after provisioning operation. 
It
> >>>> does not say HOW given capabilities should be made, cause resolver is
> >>>> hit before bundle gets active. It is a safety check. I'm fine with
> >>>> having one, however we need to make it right to do not narrow use of
> >>>> driver bundles only with our

Re: [Introduction] Christofer Dutz

[Julian Feinauer]

Hey friends,

first, thanks for starting this excellent initiaive (we should probably place 
the texts even on the "team" part oft he homepage).

I am Julian, 32 years old, married to my lovely wide Constanze and have three 
kids (two of them know toddy personally and like him, the third is too small, 
yet).
We live in Kirchheim which is about 40km south of Stuttgart and at the 
"Schwäbische Alb" a very nice and rural area.
I studied math and I really am mathematician by heart. I did my PhD in an 
applied math project and worked (together with my fellow Tim) on lithium ion 
batteries for mobile applications at a Daimler. But I felt too young and 
dynamic to stay in a corporate, thus I started a company.

We initially foused on data analysis and BI stuff but moved more and more to 
technical data and ended up in the "digitalization" or "Industrie 4.0" world. 
We joined the PLC4X project pretty early as we decided to abandon our home made 
stack to polish PLC4X for our purposes. Thus, we have it in production since 
way over a year now and have a lot of hands on experience (especially Tim). 
Thus, we often focus on "boring" things like scraper, pools and stability 
related stuff (like Netty) and do not so much implement new drivers (AB 
Ethernet we did together with Chris). But as we are really deep in the 
community and love it we do way more in the project then we would probably need 
for our business application, solely : )

But generally speaking, you can always ping us with usage scenario questions 
(mostly Siemens S7) and integrations. Currently we see ourselves as the main 
maintainers oft he 0.6 branch at least until one can migrate safely and stable 
to 0.7 (when it will be out) as we have too much stuff in production nowadays 
to play games (Cesar may surely know what happens when stuff in production does 
not work as expected... : D).

So, thanks all of you for making our little community so lovely and enyojable. 
I feel very happy tob e part o fit and to hang out with you guys. And we are 
really making an impact, more and more!
Julian


Am 07.05.20, 11:36 schrieb "Strljic, Matthias Milan" 
:

Hi,

I am a research assistant at the University of Stuttgart at the Institute 
of Control Engineering (ISW) and work there in the areas of 
communication/service concepts for automation systems and cloud manufacturing.
Among other things with projects like RetroNet I got in contact with 
several older automation protocols (ADS, S7, Profinet/bus..) and also more 
recent ones like OPC UA and their diversity despite the common goal. That's how 
I got to know Chris, Julian and the initial PLC4X crew :)

Before that I completed a study in software engineering. My main 
programming language would be Java, but I already had a lot of stacks in my 
hands (Javascript, C++, Python, Go, C#, Ada, PHP).

I like to sharpen knives and sometimes distil some schnapps. So if someone 
wants to forget a bug, you can choose between 40 - 80% alcohol content and 5 
flavours ;) If Toddy leaves some.


At the moment I'm working on the OPC UA integration of Milo into PLC4J with 
the documentation (Pls Toddy stop hurting me! ) and a bridge server for the OPC 
UA representation of other protocols in an extra integrated OPC UA server. Our 
institute is quite experienced in TSN and OPC Companion specifications. 
Therefore I try to integrate the project into publicly funded research projects 
to make PLC4X more known and to support the community.

Greetings Matthias



Von: Christofer Dutz 
Gesendet: Dienstag, 5. Mai 2020 13:23:42
An: dev@plc4x.apache.org
Betreff: [Introduction] Christofer Dutz

Hi all,

I have noticed that our tram has grown quite a bit in the last year and 
most of you I have never met personally.
We have been discussing a lot of things here on the list and on slack, but 
I only have little background on who you folks actually are.

So I would like to ask anyone interested to just introduce himself in this 
thread.

I’ll start:

My name is Christofer Dutz, I’m currently 42 years old and studied 
computer-science at the University of Darmstadt.
I’m the son of an Electro-Engineer and therefore already had contact with 
all of this automation stuff when I was a kid, but somehow lost contact when I 
discovered my interest in computers.

Being an IT guy living near Frankfurt (Germany) there is almost no chance 
to not work for Banks and Insurance companies. So I guess I’ve been working for 
about 12 different Banks and Insurance companies in the last 15 years. I always 
like to compare working for a bank like asking Picasso to paint a portrait, but 
to have him wear a mental-institution restraining jacket and have him paint 
with a brush in his mouth. End of the first quarter of 2017 it was getting so 
unbearable for me, that I was thinking about giving up my profession as an IT 
specialist and even starting to 

Re: Big and littleendian fields in one mspec

[Julian Feinauer]

That is really good news, thanks to both of you Lukasz and Chris.

Not only that we got a technical solution but that we manage it time after time 
to come to joint solutions in the project (which is way more important than 
finding technical solutions IMHO).
Hope to be able to contribute more, soon : )

Julian

Am 06.05.20, 01:33 schrieb "Łukasz Dywicki" :

Last Saturday I promised to Chris I will confirm the case and I just did.

As suggested - I rearranged field order in State type and made a test to
proof myself, that it works:

https://github.com/apache/plc4x/commit/3010fdd15524410dfd55746562ed44bcee0fe80f

I've closed related issue (PLC4X-193) and created pull requests. Changes
in mspec are not needed for that case.

It took quite long, but we managed to find solution.

Cheers,
Łukasz


On 01.05.2020 10:53, Christofer Dutz wrote:
> Hi folks,
> 
> so Lukasz just sent me a little pcap file with some AMS packets in there 
and my assumption was correct:
> 
> for example in the byte-stream I can see the "flags" being 0x0400 ... 
However wireshark read this as unsigned short LE and therefore re-aranged the 
bytes:
> StateFlags: 0x0004
>    ...0 = RESPONSE: Not set
>    ..0. = NO RETURN: Not set
>    .1.. = ADS COMMAND: Set
>    0... = SYSTEM COMMAND: Not set
>   ...0  = HIGH PRIORITY COMMAND: Not set
>   ..0.  = TIMESTAMP ADDED: Not set
>   .0..  = UDP COMMAND: Not set
>   0...  = INIT COMMAND: Not set
> 0...    = BROADCAST: Not set
> 
> So in above example only one field is true: "ADS COMMAND" ... so if I 
decode 0x0400 to binary that’s: 0100 
> 
> So this exactly fits my proposed mspec definition of: 
> 
> [type 'State'
> [simple bit 'initCommand'   ]
> [simple bit 'updCommand']
> [simple bit 'timestampAdded']
> [simple bit 'highPriorityCommand'   ]
> [simple bit 'systemCommand' ]
> [simple bit 'adsCommand']
> [simple bit 'noReturn'  ]
> [simple bit 'response'  ]
> [simple bit 'broadcast' ]
> [reserved   int 7 '0x0' ]
> ]
> 
> So I strongly object introducing any special endianness "feature" for 
this (in this case) ... 
> we might encounter something where we need it, but for this we don't.
> 
> Chris
> 
> 
> 
> Am 30.04.20, 23:02 schrieb "Christofer Dutz" :
> 
> Hi Lukasz,
> 
> I wasn't suggesting to look how WireShark decodes things. Cause I 
would assume that they read a short in little endian and then (on the 
rearranged bytes) apply some bit checks. 
> 
> I was more suggesting that you look into the bytes Wireshark shows 
you and to check their exact position.
> 
> When implementing drivers, I used the Mac's Calculator tool quite 
often to see the bits for a given byte value.
> 
> In your example I can't see any need for endianness at all ... it's 
all just bits and one empty block which forms a full byte together with the 
first bit.
> As this block doesn't cross any byte boundaries I can't see any 
problems with this.
> 
> Assuming I understand what you are implying with 
> 
> [type little endian 'State'
> [simple bit 'broadcast' ]
> [reserved   int 7 '0x0' ]
> [simple bit 'initCommand'   ]
> [simple bit 'updCommand']
> [simple bit 'timestampAdded']
> [simple bit 'highPriorityCommand'   ]
> [simple bit 'systemCommand' ]
> [simple bit 'adsCommand']
> [simple bit 'noReturn'  ]
> [simple bit 'response'  ]
> ]
> 
> Then it should be equal to:
> 
> [type 'State'
> [simple bit 'initCommand'   ]
> [simple bit 'updCommand']
> [simple bit 'timestampAdded']
> [simple bit 'highPriorityCommand'   ]
> [simple bit 'systemCommand' ]
> [simple bit 'adsCommand']
> [simple bit 'noReturn'  ]
> [simple bit 'response'  ]
> [simple bit 'broadcast' ]
> [reserved   int 7 

Re: SPI Module - OSGi Bundle

[Julian Feinauer]

gt; >>>> layer its shouldn't be used for adhoc fixes.
>> > > > >>>>
>> > > > >>>> We can try to turn drivers into services (see here
>> > > > >>>>
>> > > >
>> > >
>> >
>> 
https://github.com/splatch/plc4x/commit/5ce379cf8d2f5dc91fdfb6d8a8e2c0531906e69f
>> > > > )
>> > > > >>>> in order to cut concrete class dependency and rely on
>> isolated
>> > > > APIs.
>> > > > >>>> This code was done before new abstractions over netty were
>> > > > introduced,
>> > > > >>>> but it should cut in half API and caller side (not sure if
>> > we're
>> > > > on
>> > > > >>>> declarative services).
>> > > > >>>>
>> > > > >>>> My tip to you Etienne - please verify which class loader 
is
>> > used
>> > > > in your
>> > > > >>>> polling cycle. You can do that by making breakpoint in
>> faulty
>> > > > method of
>> > > > >>>> S7Driver and evaluating expression
>> > > > >>>> "Thread.currentThread().getContextClassLoader()".
>> > > > >>>> Once you know that you can either fix classloading in the
>> > > calling
>> > > > class
>> > > > >>>> loader or override classloader for thread to proper one.
>> > > > >>>>
>> > > > >>>> Best,
>> > > > >>>> Łukasz
>> > > > >>>>
>> > > > >>>>
>> > > > >>>> On 03.04.2020 10:27, Etienne Robinet wrote:
>> > > > >>>>> Hi Christian,
>> > > > >>>>> you mean the code used in the Camel route? It is an
>> > blueprint:
>> > > > >>>>>
>> > > > >>>>> 
>> > > > >>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>> > "
>> > > > >>>>>   xmlns:xsi="
>> > http://www.w3.org/2001/XMLSchema-instance
>> > > "
>> > > > >>>>>   xsi:schemaLocation= "
>> > > > http://www.osgi.org/xmlns/blueprint/v1.0.0
>> > > > https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>> > > > >>>>>http://camel.apache.org/schema/blueprint
>> > > > http://camel.apache.org/schema/blueprint/camel-blueprint-2.24.2.xsd
>> ">
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>http://camel.apache.org/schema/blueprint; streamCache="true" >
>> > > > >>>>>
>> > > > >>>>>> > > > uri="timer://plcFetch?fixedRate=true=1000"/>
>> > > > >>>>>
>> > > > >>>>>plc4x:s7:tcp://
>> > > > 192.168.178.10?address=#fields
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>   > class="org.apache.plc4x.camel.TagData">
>> > > > >>>>>   
>> > > > >>>>>   > > value="%DB1.DBW254:INT"/>
>> > > > >>>>>   
>> > > > >>>>>   > class="org.apache.plc4x.camel.TagData">
>> > > > >>>>>   

Re: Add a list of companies using PLC4X without links back?

[Julian Feinauer]

Hey,

yes. So then, get it started. You get my logo for free : )

Julian

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

Hi all,

yes I agree ... and I was currently just talking about companies "using" 
plc4x. As quite often I am asked: "do people use PLC4X" and I usually say: 
"sure quite a lot, unfortunately I can't tell you who" ... so if we had such a 
list, we would have something to refer to.

And yes ... let's discuss "products and services" separately ... here 
always a vote on the PLC should be required.

Chris

Am 04.05.20, 12:30 schrieb "Strljic, Matthias Milan" 
:

Hi,


I would agree with Julian's position there and I think that this would 
further promote acceptance in the industry.
After all, the field of automation protocols is a rather delicate area 
in which trust is an essential point.


If this helps, I would also like to place my university institute or 
rather my employer (my is such a big word :D ) as a user. But as Julian 
mentioned, I would only accept any entry by PMC vote.


+1


Greetings

Mathi

    ____
Von: Julian Feinauer 
Gesendet: Donnerstag, 30. April 2020 21:49:25
An: dev@plc4x.apache.org
Betreff: Re: Add a list of companies using PLC4X without links back?

Hi,

I think we have to differentiate.
If its just a "users" list or "powered by" list then its fine and PR is 
the way to go!

Before we discussed about "companies that offer products / services 
around PLC4X" which is a different thing. Here, I still am convinced that we 
should always do it via PMC Vote to really ensure that no one "sneaks" in or 
someone is embarrassed that he is not on the list or whatever.

But I am +1 here (and would ofc place our logo there and get one or two 
of clients of us that now run solutions powered by PLC4X)

Julian

Am 30.04.20, 21:08 schrieb "Christofer Dutz" 
:

Hi folks,

I like the mode the Airflow folks are doing it ...
by not adding them manually, but only via PRs, I guess they are on 
the safe side.

What do you think folks?
Should we just create such a page?
(I'm taking about the "who's using" list)

If we had some use-cases or success-stories, I'd also like to have 
something like that, but not sure if companies are currently willing so share 
stuff like that and just having 1-2 of them would probably be 
counter-productive. We could start collecting them and add them to the 
navigation as soon as we have a critical mass of stories.

Chris


Am 30.04.20, 18:02 schrieb "Tomasz Urbaszek" :

Other projects have this as well:
https://spark.apache.org/powered-by.html
https://druid.apache.org/druid-powered

Of course, I agree with Łukasz that this should be done with the
consent of those companies. Probably best if done by those 
comapnies.

T.


On Thu, Apr 30, 2020 at 5:55 PM Łukasz Dywicki 
 wrote:
>
> Apache Karaf does that via stories page:
> https://karaf.apache.org/stories.html
> also has a "commercial support" section on the community page:
> https://karaf.apache.org/community.html
>
> Apache Camel has site dedicated only to commercial offerings:
> 
https://camel.apache.org/manual/latest/commercial-camel-offerings.html
>
> I think that major complain is listing a company without 
their consent
> or using their logo without a consent, simply due to possible 
trademark
> missuse disputes. It is much easier the other way around - 
when
> companies say "we would like to..". As you can see 
organizations are
> keen to "announce" they do something with above projects.
>
> I believe PLC4X doesn't have to be shy. :-)
>
> Cheers,
> Łukasz
>
> On 30.04.2020 14:54, Christofer Dutz wrote:
> > Hi Tomek,
> >
> > Yeah ... I would love something like that, but I remember 
when we had this discussion before, it might be that it's sort of frowned about.
> > I would only like to do this similarly if it's in line with 
ASF policies.
> >
> > Chris
> >
> >

Re: Symbol metadata for connections

[Julian Feinauer]

Yes, that's the most important thing. In the end, the leads should be addressed 
that you simply add to request builder. But we should really carefully think 
about the api.

Would like to have @Matthias Milan 
Strljic<mailto:matthias.strl...@isw.uni-stuttgart.de> on board here. He knows 
lots of protocols.

Julian

Holen Sie sich Outlook für Android<https://aka.ms/ghei36>


From: Christofer Dutz 
Sent: Saturday, May 2, 2020 2:38:29 PM
To: dev@plc4x.apache.org 
Subject: Re: Symbol metadata for connections

Hi,

but we should make it compatible with all protocols (in theory) so we shouldn't 
name things with OPC UA as reference and try to map things to that.
Would be cool if someone could describe how this mechanism works in the 
different protocols and how the operations are named.

Chris

Am 02.05.20, 11:06 schrieb "Julian Feinauer" :

Hi,

this is a very good point.
You mean something like "getAllSymbols()" (which would only be possible in 
S7 case with either TIA File or S7Comm+ Protocol).
But totally makes sense for ADS or OPC UA.

Would love to see a Design Doc for that (starting with OPC UA and ADS gives 
quite a wide range of needs).

Julian

Von: Christofer Dutz 
Gesendet: Donnerstag, 30. April 2020 22:32
An: dev@plc4x.apache.org 
Betreff: Re: Symbol metadata for connections

Hi Lukasz,

Initially we were planning on supporting a "browse" functionality alongside 
the "read", "write" and "subscribe" ...
might that be more what you are referring to?

Chris


Am 30.04.20, 21:54 schrieb "Łukasz Dywicki" :

Hey,
I been going through some ideas what could be improved here and there
after doing my ADS try outs and come to following.

Current API for PlcConnectionMetadata offers few basic canRead,
canWrite, canSubscribe methods. It does not offer any api to read plc
kind or symbol, even if some drivers do discover device kind. For
comparison, with JDBC, we have few more options when we fetch metadata -
ie. java.sql.DataBaseMetadata#getTypeInfo, #getTables, #getColumns and
so on. I tend to opt for TypeInfo and Columns (symbols) as first class
citizens which we can make.

Currently protocols which can handle metadata requests can not support
discovery of available symbols cause there is no way to supply that.
This is something possible with ADS, for sure also with OPC UA. It
shouldn't be to hard to provide one.

Best regards,
Łukasz

AW: Symbol metadata for connections

[Julian Feinauer]

Hi,

this is a very good point.
You mean something like "getAllSymbols()" (which would only be possible in S7 
case with either TIA File or S7Comm+ Protocol).
But totally makes sense for ADS or OPC UA.

Would love to see a Design Doc for that (starting with OPC UA and ADS gives 
quite a wide range of needs).

Julian

Von: Christofer Dutz 
Gesendet: Donnerstag, 30. April 2020 22:32
An: dev@plc4x.apache.org 
Betreff: Re: Symbol metadata for connections

Hi Lukasz,

Initially we were planning on supporting a "browse" functionality alongside the 
"read", "write" and "subscribe" ...
might that be more what you are referring to?

Chris


Am 30.04.20, 21:54 schrieb "Łukasz Dywicki" :

Hey,
I been going through some ideas what could be improved here and there
after doing my ADS try outs and come to following.

Current API for PlcConnectionMetadata offers few basic canRead,
canWrite, canSubscribe methods. It does not offer any api to read plc
kind or symbol, even if some drivers do discover device kind. For
comparison, with JDBC, we have few more options when we fetch metadata -
ie. java.sql.DataBaseMetadata#getTypeInfo, #getTables, #getColumns and
so on. I tend to opt for TypeInfo and Columns (symbols) as first class
citizens which we can make.

Currently protocols which can handle metadata requests can not support
discovery of available symbols cause there is no way to supply that.
This is something possible with ADS, for sure also with OPC UA. It
shouldn't be to hard to provide one.

Best regards,
Łukasz

Re: Add a list of companies using PLC4X without links back?

[Julian Feinauer]

Hi,

I think we have to differentiate.
If its just a "users" list or "powered by" list then its fine and PR is the way 
to go!

Before we discussed about "companies that offer products / services around 
PLC4X" which is a different thing. Here, I still am convinced that we should 
always do it via PMC Vote to really ensure that no one "sneaks" in or someone 
is embarrassed that he is not on the list or whatever.

But I am +1 here (and would ofc place our logo there and get one or two of 
clients of us that now run solutions powered by PLC4X)

Julian

Am 30.04.20, 21:08 schrieb "Christofer Dutz" :

Hi folks,

I like the mode the Airflow folks are doing it ... 
by not adding them manually, but only via PRs, I guess they are on the safe 
side.

What do you think folks? 
Should we just create such a page? 
(I'm taking about the "who's using" list)

If we had some use-cases or success-stories, I'd also like to have 
something like that, but not sure if companies are currently willing so share 
stuff like that and just having 1-2 of them would probably be 
counter-productive. We could start collecting them and add them to the 
navigation as soon as we have a critical mass of stories.

Chris


Am 30.04.20, 18:02 schrieb "Tomasz Urbaszek" :

Other projects have this as well:
https://spark.apache.org/powered-by.html
https://druid.apache.org/druid-powered

Of course, I agree with Łukasz that this should be done with the
consent of those companies. Probably best if done by those comapnies.

T.


On Thu, Apr 30, 2020 at 5:55 PM Łukasz Dywicki  
wrote:
>
> Apache Karaf does that via stories page:
> https://karaf.apache.org/stories.html
> also has a "commercial support" section on the community page:
> https://karaf.apache.org/community.html
>
> Apache Camel has site dedicated only to commercial offerings:
> https://camel.apache.org/manual/latest/commercial-camel-offerings.html
>
> I think that major complain is listing a company without their consent
> or using their logo without a consent, simply due to possible 
trademark
> missuse disputes. It is much easier the other way around - when
> companies say "we would like to..". As you can see organizations are
> keen to "announce" they do something with above projects.
>
> I believe PLC4X doesn't have to be shy. :-)
>
> Cheers,
> Łukasz
>
> On 30.04.2020 14:54, Christofer Dutz wrote:
> > Hi Tomek,
> >
> > Yeah ... I would love something like that, but I remember when we 
had this discussion before, it might be that it's sort of frowned about.
> > I would only like to do this similarly if it's in line with ASF 
policies.
> >
> > Chris
> >
> >
> > Am 30.04.20, 14:50 schrieb "Tomasz Urbaszek" :
> >
> > Hi,
> >
> > Apache Airflow has such a list[1] and it's growing steadily. We 
have
> > also use-cases on our website[2] (with logos). In both cases, 
it's up
> > to the company/user to add this info (via PR). I think this 
really
> > helps. From a company perspective, it's one more place where 
you can
> > "shout out" about yourself. The problem is that sometimes 
companies
> > "would love to do this but someone has to do / write this"...
> >
> > [1] https://github.com/apache/airflow#who-uses-apache-airflow
> > [2] https://airflow.apache.org/use-cases/
> >
> > Tomek
> >
> >
> > On Thu, Apr 30, 2020 at 2:38 PM Christofer Dutz
> >  wrote:
> > >
> > > Hi all,
> > >
> > > as one of our biggest problems is usually not being allowed 
to talk about the awesome stuff we do in projects it’s sort of a 
hen-egg-problem.
> > > We can’t claim people are using it but not tell who …
> > >
> > > If there are companies willing to openly announce they are 
using it, would it be in line with the ASF if we had a list on our website with 
company names and perhaps logos with companies openly stating they are or have 
been using PLC4X.
> > >
> > > I know this is usually a problem with Apache’s non-profit 
charity thing.
> > > But I would expect if there aren’t any links back to the 
companies this issue should be weakened.
> > >
> > > Would it be possible to compile such a list / logo-wall?
> > >
> > > What do you generally think about this?
> > >
> > > Chris
> > >
> >

Re: [DISCUSS] Finally release 0.7.0?

[Julian Feinauer]

Not from my side (well but I mostly cover 0.6.0 still...).

Julian

Am 30.04.20, 20:56 schrieb "Christofer Dutz" :

Hi all,

So is there anything that someone is working on/needing soon that still 
needs to go into 0.7.0?
Otherwise I'd probably cut the release branch in the next 1-2 days.

Chris


Am 30.04.20, 11:35 schrieb "Joris Suppers" :

No complaints so far.
We still need to do some more endurance tests and error handling tests, 
but
so far so good :-)

On Thu, 30 Apr 2020 at 11:21, Julian Feinauer 

wrote:

> Ah, cool.
> Does it work well, so far?
>
> Am 30.04.20, 11:06 schrieb "Joris Suppers" :
>
> Sure did, we are currently using/testing plc4x for our s7 
connections
> using
> the scraper functionality with the 0.7.0 SNAPSHOT.
    >
    > On Thu, 30 Apr 2020 at 10:48, Julian Feinauer <
> j.feina...@pragmaticminds.de>
> wrote:
>
> > Hey Joris,
> >
> > did you try 0.6.0 yet?
> >
> > Julian
> >
> > Am 30.04.20, 10:38 schrieb "Joris Suppers" :
> >
> > Hey,
> >
>     > We at Sotec would also like this, so +1 from us as well.
> >
> >
> > On Thu, 30 Apr 2020 at 10:11, Julian Feinauer <
> > j.feina...@pragmaticminds.de>
> > wrote:
> >
> > > Hi,
> > >
> > > I wholeheartedly agree with your suggestion.
> > > I really like to bring the drivers to staging and test 
them
> in-deep
> > to
> > > gather feedback for next iterations.
> > >
> > > So big +1.
> > >
> > > Julian
> > >
> > > Am 30.04.20, 09:04 schrieb "Christofer Dutz" <
> > christofer.d...@c-ware.de>:
> > >
> > > Hi folks,
> > >
> > > I think we should release soon so first people can 
start
> using
> > our new
> > > generated drivers.
> > >
> > > What do you think?
> > >
> > > I know we’re currently missing an ADS driver, but I 
think
> we’ve
> > waited
> > > long enough.
> > >
> > > Chris
> > >
> > >
> >
> > --
> > Joris Suppers | SOTEC | j.supp...@sotec.eu | T +49 7033 
5458 72
> >
> > --
> >
> >
> >
> >
> >
> >
> > www.sotec.eu <http://www.sotec.eu/>
> >
> > SOTEC Software Entwicklungs GmbH
> > + Co Mikrocomputertechnik KG
> >
> > Calwer Straße 11, D-75395 Ostelsheim
> >
> > Sitz
> > Ostelsheim, Amtsgericht Stuttgart HRA 330821/HRB 330664,
> > Geschäftsführer:
> > Florian Holz
> >
> >
> >
> >
> >
>
> --
> Joris Suppers | SOTEC | j.supp...@sotec.eu | T +49 7033 5458 72
>
> --
>
>
>
>
>
>
> www.sotec.eu <http://www.sotec.eu/>
>
> SOTEC Software Entwicklungs GmbH
> + Co Mikrocomputertechnik KG
>
> Calwer Straße 11, D-75395 Ostelsheim
>
> Sitz
> Ostelsheim, Amtsgericht Stuttgart HRA 330821/HRB 330664,
> Geschäftsführer:
> Florian Holz
>
>
>
>
>

-- 
Joris Suppers | SOTEC | j.supp...@sotec.eu | T +49 7033 5458 72

-- 






www.sotec.eu <http://www.sotec.eu/>

SOTEC Software Entwicklungs GmbH 
+ Co Mikrocomputertechnik KG 

Calwer Straße 11, D-75395 Ostelsheim 

Sitz 
Ostelsheim, Amtsgericht Stuttgart HRA 330821/HRB 330664, 
Geschäftsführer: 
Florian Holz