AW: [DISCUSS] Rename PLC4DOTNET to PLC4CSHARP?

[Bjoern Hoeper]

Some people are masochistic... ;)
Joking aside I think the more relevant option is F# which could be a good match 
for some use cases

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Freitag, 3. April 2020 16:30
An: dev@plc4x.apache.org
Betreff: Re: [DISCUSS] Rename PLC4DOTNET to PLC4CSHARP?

But VB?!?!?!?!

Am 03.04.20, 16:12 schrieb "Bjoern Hoeper" :

Hi,

in my opinion the runtime is the more relevant thing in this context 
because if you take a .NET Lib you could use it with VB or F# or any other 
language that is compatible with the .NET Runtime. So the language is only the 
language in which it is written (which could also be intermixed). Furthermore 
it is quite common to use something like NET e.g. log4j had an equivalent of 
log4net.

Björn

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Freitag, 3. April 2020 15:43
An: dev@plc4x.apache.org
Betreff: [DISCUSS] Rename PLC4DOTNET to PLC4CSHARP?

Hi,

I just wanted to bring this to discussion … I have now encountered in 
several projects that support different languages that the naming convention we 
follow seems to match:


  *   C : xyz_c
  *   C++: xyz_cpp
  *   Python: xyz_py

However when it comes to C# we sort of named it “plc4dotnet” … I would 
propose to change it to “plc4csharp” as this is the language … “dotnet” is sort 
of more the runtime.

What do you think?

Chris

AW: [DISCUSS] Rename PLC4DOTNET to PLC4CSHARP?

[Bjoern Hoeper]

Hi,

in my opinion the runtime is the more relevant thing in this context because if 
you take a .NET Lib you could use it with VB or F# or any other language that 
is compatible with the .NET Runtime. So the language is only the language in 
which it is written (which could also be intermixed). Furthermore it is quite 
common to use something like NET e.g. log4j had an equivalent of log4net.

Björn

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Freitag, 3. April 2020 15:43
An: dev@plc4x.apache.org
Betreff: [DISCUSS] Rename PLC4DOTNET to PLC4CSHARP?

Hi,

I just wanted to bring this to discussion … I have now encountered in several 
projects that support different languages that the naming convention we follow 
seems to match:


  *   C : xyz_c
  *   C++: xyz_cpp
  *   Python: xyz_py

However when it comes to C# we sort of named it “plc4dotnet” … I would propose 
to change it to “plc4csharp” as this is the language … “dotnet” is sort of more 
the runtime.

What do you think?

Chris

AW: Getting you others involved (again)?

[Bjoern Hoeper]

Hi Chris,
on my side it is just being busy with other work not directly related to PLC4X. 
So it has nothing to do with the project.
I hope to have some spare time to contribute again around Christmas.

Björn

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Montag, 18. November 2019 14:20
An: dev@plc4x.apache.org
Betreff: Getting you others involved (again)?

Hi all,

I just had a look at the commit statistics for the last month.
In this statistic it seems that only Julian and me are the only people I would 
call active.
So what could I/we do to get you others involved again? I know we had a time 
where things were really going forward.
I would really like to see more diverse commit history.

If It’s something I’m doing/not doing, please tell me … if it’s something I 
could be doing, please tell me too.

Looking forward to some activity here ;)

Chris

AW: [VOTE] Apache PLC4X 0.5.0 RC3

[Bjoern Hoeper]

Hi all,
+1 (binding)

Minor issues:
* Tests needing libpcap loopback not runnable because libpcap does not support 
loopback interface on Windows (RawSocketChannelTest). Already addressed in 
PLC4X-150.

- Downloaded and extracted staged artifacts
- Checked README, RELEASE_NOTES, LICENSE and NOTICE
- No unexpected binaries
- Built on Windows 10 x86-64 using (Test suppression due to minor issue above):
'.\mvnw.cmd -P 
with-python,with-proxies,with-boost,with-java,with-cpp,with-dotnet -DskipTests 
install'

Björn

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Dienstag, 29. Oktober 2019 14:04
An: dev@plc4x.apache.org
Betreff: [VOTE] Apache PLC4X 0.5.0 RC3

Apache PLC4X 0.5.0 RC3 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.5.0-rc3
Hash for the release tag: 59cd9d3839dcb6083350144802142360182c59c1

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-1018
[2] https://dist.apache.org/repos/dist/dev/plc4x/0.5.0/rc3
[3] https://www.apache.org/dev/release.html#approving-a-release
[4] 
https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release

AW: [PLC-Simulator] Thoughts on the "Context" for our simulator

[Bjoern Hoeper]

Hi Chris,
It allows building modular libraries (we already have quite a lot ready to use) 
which would  also imply logic.
The thing with the system is that C is only the implementation language for the 
current runtime. Everything that is modelled on top of it is generated from 
abstract model descriptions. Nevertheless to alter the logic you still need C.
The only option would be to build a generator that allows running java code in 
the context of the C program using an adapter automatically generated from the 
model description (which should be doable but rather complex).
The inner workings are definitely worth a look. There are some pretty neat 
ideas inside.

Björn

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Freitag, 18. Oktober 2019 11:38
An: dev@plc4x.apache.org
Betreff: Re: [PLC-Simulator] Thoughts on the "Context" for our simulator

Hi Björn,

thanks for that ... just had a short look ... it seems to be technologically 
integratable as it seems to require the installation of the usual suspects we 
already have for building C++ and Thirft.
However I doubt integrating this into the PLC4X system would be a good idea - 
If we wanted to use it for testing also ... 

Does it allow to define logic modules which can then be run in it? ... I'm sort 
of thinking of building tutorials with matching mock PLC simulations. A java 
based system might be more publicly acceptable.

Perhaps it's inner workings could be a good inspiration though ... as I'm not 
very looking forward to writing C code ;-)

Chris

Am 18.10.19, 08:11 schrieb "Bjoern Hoeper" :

Hey everyone,
sorry for joining the party this late. But it is rather busy times at the 
moment.
Depending on the context maybe I can help with an existing solution: There 
is the runtime environment provided by the Chair of Process Control Engineering 
in Aachen. It is a rather complete RTE for PLCs which can also be manipulated 
during runtime. The neat thing about this is that it is available as open 
source under Apache 2.0 license. Our company has several extensions (mostly 
also open source) which can be used to manipulate the internal state of the PLC 
during runtime. If we would like to add other communication protocols (at the 
moment ACPLT/KS and OPC-UA are available) the communication is modularized. 
Furthermore everyone may customize what is running inside the RTE by writing 
own libraries in C.
Regarding the ACPLT/KS solution we have a ReST API in C# which can be used 
like the low-level API sketched out by Tim. At the moment this is not open 
source but we could think about it. So it would be an easy start because we 
have already quite a lot available.
Maybe you guys just check it out under: https://github.com/acplt/rte.
Next week at ApacheCon I could also give a little introduction because it 
is not  all to obvious how everything fits together.
Best Regards
Björn

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Donnerstag, 17. Oktober 2019 16:24
An: dev@plc4x.apache.org
Betreff: Re: [PLC-Simulator] Thoughts on the "Context" for our simulator

Hi all,

Just had another idea what the Simulator could be good for (or at least the 
server modules)

If we want to simulate bad behavior for integration tests ... with these we 
can sort of implement any form of bad behavior ;-)
- Invalid responses
- Slow responses
- Dropping connections
- ...

The more I think about it, the better it gets ;-)

Chris

Am 17.10.19, 11:08 schrieb "Christofer Dutz" :

The intended user of the simulator (Perhaps we should really call it 
PLC-Mock)
Is definitely people wanting to learn how to use PLC4X. 

Poor documentation and the availability of no tutorials, how-tos or 
trainings is one thing many people have complained about.

Using an OPC-UA simulator could potentially help, but it would only 
cover one of the communication options. 
For me OPC-UA is not a usable reality in the real world yet (Lack of 
availability of OPC-UA capable PLCs and the bad performance of the existing 
ones).

Usually a PLC has multiple options to communicate (My S7 can do (I 
think): S7-STEP7, S7-TIA, Modbus, ProfiNet) ... each protocol has its 
advantages and disadvantages.
So with the simulator supporting all the protocols we support as 
clients, a user could experiment on all of this.

It will currently be a pretty restricted thing ... so it will probably 
not be able to simulate every type of S7 or other hardware, 
but we could make sure it supports everything we want to demonstrate in 
tutorials (Just like a good Mock ... you don't use that in production ... well 
... ok ... 
there was this one Bank that actually had Mokito in the compile path, 
because one service in product

AW: [PLC-Simulator] Thoughts on the "Context" for our simulator

[Bjoern Hoeper]

Hey everyone,
sorry for joining the party this late. But it is rather busy times at the 
moment.
Depending on the context maybe I can help with an existing solution: There is 
the runtime environment provided by the Chair of Process Control Engineering in 
Aachen. It is a rather complete RTE for PLCs which can also be manipulated 
during runtime. The neat thing about this is that it is available as open 
source under Apache 2.0 license. Our company has several extensions (mostly 
also open source) which can be used to manipulate the internal state of the PLC 
during runtime. If we would like to add other communication protocols (at the 
moment ACPLT/KS and OPC-UA are available) the communication is modularized. 
Furthermore everyone may customize what is running inside the RTE by writing 
own libraries in C.
Regarding the ACPLT/KS solution we have a ReST API in C# which can be used like 
the low-level API sketched out by Tim. At the moment this is not open source 
but we could think about it. So it would be an easy start because we have 
already quite a lot available.
Maybe you guys just check it out under: https://github.com/acplt/rte.
Next week at ApacheCon I could also give a little introduction because it is 
not  all to obvious how everything fits together.
Best Regards
Björn

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Donnerstag, 17. Oktober 2019 16:24
An: dev@plc4x.apache.org
Betreff: Re: [PLC-Simulator] Thoughts on the "Context" for our simulator

Hi all,

Just had another idea what the Simulator could be good for (or at least the 
server modules)

If we want to simulate bad behavior for integration tests ... with these we can 
sort of implement any form of bad behavior ;-)
- Invalid responses
- Slow responses
- Dropping connections
- ...

The more I think about it, the better it gets ;-)

Chris

Am 17.10.19, 11:08 schrieb "Christofer Dutz" :

The intended user of the simulator (Perhaps we should really call it 
PLC-Mock)
Is definitely people wanting to learn how to use PLC4X. 

Poor documentation and the availability of no tutorials, how-tos or 
trainings is one thing many people have complained about.

Using an OPC-UA simulator could potentially help, but it would only cover 
one of the communication options. 
For me OPC-UA is not a usable reality in the real world yet (Lack of 
availability of OPC-UA capable PLCs and the bad performance of the existing 
ones).

Usually a PLC has multiple options to communicate (My S7 can do (I think): 
S7-STEP7, S7-TIA, Modbus, ProfiNet) ... each protocol has its advantages and 
disadvantages.
So with the simulator supporting all the protocols we support as clients, a 
user could experiment on all of this.

It will currently be a pretty restricted thing ... so it will probably not 
be able to simulate every type of S7 or other hardware, 
but we could make sure it supports everything we want to demonstrate in 
tutorials (Just like a good Mock ... you don't use that in production ... well 
... ok ... 
there was this one Bank that actually had Mokito in the compile path, 
because one service in production was a Mock ... but usually you don't expect 
this).

Hope that explains things a bit more.

Chris


Am 17.10.19, 05:45 schrieb "Otto Fowler" :

Who is the intended user of the simulator, or users and what do they 
want
to accomplish? Maybe if that were spelled out or people could suggest 
those
cases, some number of cases could be agreed upon, allowing the initial
effort to be done with plans for later expansion to the remaining uses
cases down the road.

In my own case:

In the past I have used PLC simulators that I have written or from open
source projects to stand in for real devices when I could not acquire 
the
hardware.  I am not sure that that use case should be high on PLC4X’s 
list
since that is a lot to chase.

With PLC4x, I have thought that I would need or like a simulator or 
“sample
system app->driver->simulator” in order for me, as a developer to debug 
and
trace through the PLC4X workings, such that I could then understand the
system well enough to either work on it or develop against it.  These 
types
of systems can stand in leu of, or augment extensive developer
documentation.

At the rate that Chris and others are progressing with refactoring and
extending the libraries, it would be helpful to have such a system
maintained as those refactoring went along.





On October 16, 2019 at 21:07:02, Strljic, Matthias Milan (
matthias.strl...@isw.uni-stuttgart.de) wrote:

Hi Chris,

yeah i see the benefits of doing all this simulated PLC endpoints for a
nice testing.

AW: [DISCUSS] Rename CRUNCH to something different

[Bjoern Hoeper]

Hi Everyone,
as Chris already mentioned a logic analyzer is quite a nice tool and in (loose) 
analogy to plc4x I would propose something like "Analyze4PLC" Or "PLCAnalyze4J" 
it would keep the logic in the naming convention somehow and make clear what 
the intention of the framework is.
Just my 50 cents.
Best,
Björn

-Ursprüngliche Nachricht-
Von: Julian Feinauer  
Gesendet: Dienstag, 17. September 2019 00:03
An: dev@plc4x.apache.org; megachu...@gmail.com
Betreff: Re: [DISCUSS] Rename CRUNCH to something different

Hi Kai,

I understand your point. But I dislike to call things like "process" or 
"compute" as these are such overused words. Windows calc does compute, 
Mainframes do compute, Hadoop nodes do compute... 

Target audience is PLC4X users so something between IT and OT. And in fact, as 
the lib is quite a bit specialiced and think its reasonable to have people look 
at the docs first : )

But, I mean we are (as Chris pointed out) still in the process of consent 
building, so its good to get so many opinions here.

Julian

Am 16.09.19, 13:43 schrieb "Kai Wähner" :

The question is "who should understand what the component does" when he
reads the component name (without any further descriptions)?

If it is software developers, then they will have no idea what
"osciloscope" means (I don't either). I only understand simple words like
Connect, Process, Store, etc. :-)

Even if osciloscope is more accurate, the question is who is the audience
for potential users of PLC4X and its sub-components.

Kai

On Mon, Sep 16, 2019 at 10:14 AM Christofer Dutz 
wrote:

> Hi Julian,
>
> A common pattern of modern ASF duels seems to be writing longer and longer
> emails till someone finally gives up ;-)
>
> Chris
>
>
> Am 16.09.19, 18:51 schrieb "Julian Feinauer" <
> j.feina...@pragmaticminds.de>:
>
> Hi,
>
> ist not that i disagree with you, I just don’t agree : D
> Logic Analyzer sounds weird for me (but I'm also not so used to that).
>
> So we should go on discussing.. and if no consensus is found we meet
> somewhere, two men, nobody else, no guns (and no bears!). Knifes are
> probably okay (have to check the Apache Policy on consensus finding
> again...) : )
>
> Julian
>
> Am 16.09.19, 09:45 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
>
> Hi julian,
>
> Well  coming back to your explanation:
> I would never use an oszyloscope to analyze such plc signals they
> have a far to low frequency for oszylloscope analysis. Especially an
> oszylloscope requires things to have a frequency and you couldn't detect
> simple low frequent logic level shifts.
> Thinking about how I usually analyze signals in the IoT space, I
> always use my Logic-Analyzer which is much more suited for such tasks.
> So if we would stick to your reasoning, I would prefer "logic
> analyzer" instead of "oszylloscope".
>
> Chris
>
>
> Am 16.09.19, 17:37 schrieb "Julian Feinauer" <
> j.feina...@pragmaticminds.de>:
>
> Hi,
>
> although I agree with Chris and Kai (better name things
> functionally) I personally prefer something like 'osciloscope' as it
> transpoets the intent of the lib better than 'process' or 'compute'-
>
> Oscilloscopes are known to help you with analyzing signals, in
> fact Wikipedia states:
>
> "The waveform can then be analyzed for properties such as
> amplitude, frequency, rise time, time interval, distortion, and others.
> Modern digital instruments may calculate and display these properties
> directly. Originally, calculation of these values required manually
> measuring the waveform against the scales built into the screen of the
> instrument.[3]"
>
> So I think this is the name I prefer most, especially because
> it brings the intent as close as possible.
>
> Julian
>
>
> Am 16.09.19, 02:36 schrieb "Strljic, Matthias Milan" <
> matthias.strl...@isw.uni-stuttgart.de>:
>
> +1 for that. I am not a fan of fancy cool names . So
> Processing / Filter / SignalWatchDog would be better for me.
>
> Greetings Mathi
> Matthias Strljic, M.Sc.
>
> Universität Stuttgart
> Institut für Steuerungstechnik der Werkzeugmaschinen und
> Fertigungseinrichtungen (ISW)
>
> Seidenstraße 36
> 70174 Stuttgart
> GERMANY
>
> Tel: +49 711 685-84530
> Fax: +49 711 685-74530
>
> E-Mail: 

AW: [VOTE] Accept CRUNCH as subproject for PLC4X

[Bjoern Hoeper]

+1 (binding)

Björn

-Ursprüngliche Nachricht-
Von: Julian Feinauer  
Gesendet: Montag, 2. September 2019 20:57
An: dev@plc4x.apache.org
Betreff: [VOTE] Accept CRUNCH as subproject for PLC4X

Hi all,

as the discussion seems to slow down and to stabilizes in [1] I take the 
freedom to start a vote.
The vote is ONLY about accepting the project CRUNCH [2] as a subproject to 
PLC4X (its not about changing the TLPs Name, or changing the scope of the 
project or other things that came up during the DISCUSS).

Before CRUNCH could be integrated it has to go through clearance from the 
incubator before being integrated into the project but also a PMC Vote is 
required. Also a name change is very likely as the current name conflicts with 
Apache Crunch [3].

As usual the vote will be open for at least 72hours and the options are

+1 – accept CRUNCH as a subproject for PLC4X
0 – no opinion
-1 – do not accept CRUNCH as a subproject for PLC4X (please give reasons for 
that)

Thanks
Julian

[1] 
https://lists.apache.org/thread.html/444ce99b0495e94177203ec4aff55dc91b8d78d8d9758ad0f8bb484f@%3Cdev.plc4x.apache.org%3E
[2] https://github.com/pragmaticminds/crunch
[3] http://crunch.apache.org/

Re: Next PLC4X Meetup on 22.08.2019 in the codecentric Office in Frankfurt

[Bjoern Hoeper]

Hi everyone,
I sadly cannot participate because I am still on holiday on Thursday.
I wish all of you a productive meeting and I am really sad not seeing you all 
again.
Greetings from Hallig Hooge
Björn

Outlook für Android herunterladen


From: Christofer Dutz 
Sent: Sunday, August 18, 2019 4:32:35 PM
To: dev@plc4x.apache.org 
Subject: Re: Next PLC4X Meetup on 22.08.2019 in the codecentric Office in 
Frankfurt

Sure that's possible.

I'll be there starting 9:00-9:15 :-)

Chris

Holen Sie sich Outlook für Android


From: Strljic, Matthias Milan 
Sent: Sunday, August 18, 2019 3:23:25 PM
To: dev@plc4x.apache.org 
Subject: AW: Next PLC4X Meetup on 22.08.2019 in the codecentric Office in 
Frankfurt

Hi Chris,


for the meetup would it be possible to start even earlier at you place?

Because for me it would not make a big difference if we start at 10- 10:30 and 
so we would have more time together ❤


Greetings

Mathi


Von: Christofer Dutz 
Gesendet: Mittwoch, 14. August 2019 10:38:54
An: dev@plc4x.apache.org
Betreff: Re: Next PLC4X Meetup on 22.08.2019 in the codecentric Office in 
Frankfurt

Hi Markus,

I feel really sorry for you  NOT! :-P

Enjoy.

Hope you're planning in ApacheCon EU in Berlin in October ...

Chris

Am 14.08.19, 10:27 schrieb "Markus Sommer" :

Hi all,

I would have liked to get to know everyone.

Unfortunately I can't attend the meeting because I'm lying on the beach in 
Greece at the moment.

Best regards

Markus

Freundliche Grüße

Markus Sommer
Geschäftsführer

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

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

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

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


-Ursprüngliche Nachricht-
Von: Julian Feinauer 
Gesendet: Dienstag, 13. August 2019 11:15
An: dev@plc4x.apache.org; Lukas Ott 
Betreff: Re: Next PLC4X Meetup on 22.08.2019 in the codecentric Office in 
Frankfurt

Hi Lukas,

awesome that you will be there!
We didn’t manage to meet in Stuttgart in-between.
But perhaps we can organize some common cars to go to Ffm as we are quite 
few people from Stuttgart, or?

Julian

Am 13.08.19, 11:04 schrieb "Ott, Lukas" :

Hi Chris,

Call me in + 1 Developer.

- My Focus on documentation and learning to setup.


Lukas Ott
Associate Consultant Business
Industry Consulting Manufacturing - North and Central Europe
DXC Technology

Hewlett-Packard-Str. 1, 61352 Bad Homburg, Germany
M: +49.173.705.2298 | lo...@dxc.com | LinkedIn | Twitter Me
Notice of temporary leave: 1 September 2019 – 29 September 2019, 1 
October 2019 – 4 October 2019

DXC Technology • This is a PRIVATE message. If you are not the intended 
recipient, please delete without copying and kindly advise us by e-mail of the 
mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate 
to bind DXC to any order or other contract unless pursuant to explicit written 
agreement or government initiative expressly permitting the use of e-mail for 
such purpose• Registered Office: Hewlett-Packard-Str. 1, 61352 Bad Homburg, 
Germany• Board of Directors: Michael Eberhardt (Chairman), Chairman of the 
Supervisory Board: William L. Deckelman • Registered in Germany: HRB 11307

-Original Message-
From: Christofer Dutz 
Sent: Montag, 12. August 2019 17:03
To: dev@plc4x.apache.org
Subject: Next PLC4X Meetup on 22.08.2019 in the codecentric Office in 
Frankfurt

Hi all,

I would like to announce the next PLC4X meetup, which is planned on 
22.08.2019.
We will be hosting the meetup in the codecentric office in Frankfurt 
where the carpet still has a big stain from our graduation party ;-) 
codecentric AG Kreuznacher Str. 30
60486 Frankfurt
(Near the train-station Frankfurt West)

As some of you would be coming from further away, we’ll start a little 
earlier than with normal meetups.
It’s planned 

Re: [KAFKA] Refactoring the Kafka Connect plugin?

[Bjoern Hoeper]

Hi Chris,
No we are not using any existing solution. So you can proceed as outlined by 
you.
It was just a remark for future direction.
Greetings (now from Sylt)
Björn

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


From: Christofer Dutz 
Sent: Thursday, August 15, 2019 5:26:13 PM
To: dev@plc4x.apache.org 
Subject: Re: [KAFKA] Refactoring the Kafka Connect plugin?

Hi Björn,

But you weren't using the existing solution, we're you? So me removing that 
wouldn't cause you any pain. But us adding one later on, would make you happy?

Chris

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

____
From: Bjoern Hoeper 
Sent: Thursday, August 15, 2019 11:30:34 AM
To: dev@plc4x.apache.org 
Subject: Re: [KAFKA] Refactoring the Kafka Connect plugin?

Hi everyone,
I am on holiday currently so just a short note:
We have a use case at our customer that would need the sink functionality to 
exchange data between distinct DCSes controlling different areas. In a current 
implementation that provides this exchange the receiving dcs is an active pull 
component getting the data from the remote DCS.
I see two possible options for sink implementation. Some proxy component 
actively throttles writing to the DCS/PLC or the DCS pulling data itself as a 
custom Kafka Consumer. The only option that could be implemented independent of 
the control vendor addressed would be the first one.
After my holiday I will ask our customer if I can share some details.
Greetings from the Harbor of Rømø
Björn

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


From: Julian Feinauer 
Sent: Tuesday, August 13, 2019 9:05:26 PM
To: dev@plc4x.apache.org ; megachu...@gmail.com 

Subject: AW: [KAFKA] Refactoring the Kafka Connect plugin?

Hi,

I agree with what you say.
We use Kafka and plc4x exactly the same way in prod :)

Prepaid Björn can also comment here as he also consists a Kafka based plc 
communication layer..

Julian

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: Re: [KAFKA] Refactoring the Kafka Connect plugin?
Von: Kai Wähner
An: dev@plc4x.apache.org
Cc:

Hi Chris,

here a few thoughts:

*I haven't seen a single use case of someone writing to a PLC with PLC4X *
=> This sounds similar to most IoT MQTT scenarios I see today. The main
challenge is to get data out of machines to analyze and use it. Writing
back (e.g. to control the systems) is the second step which comes later,
sometimes years later - or even never if not needed.

* I doubt such a scenario is ideal for the Kafka setup*
=> If you don't see it in other PLC4X projects, then I would not worry
about it too much for Kafka integration today.
However, I would not think too much about Kafka here. Either you see many
use cases for Sinks in general today for PLC4X, or you don't see them yet.
Some use Kafka, some use Java, some use Nifi or whatever.

*A PLC is not able to consume a lot of data until it chokes and stops
working*
=> This is an argument we hear often in Kafka community. Often it is *not*
valid (and we see more and more use cases where Kafka is just used for
transactional data like bank payments which are very low volume).
Therefore, Kafka is not just used for big data sets. In IoT scenarios (like
connected cars), we see more and more use cases where people also want to
send information back to the device (e.g. alerts or recommendations to the
driver, though, this is just a few messages, not comparable to sensor
egress messages).
In IoT scenarios, in almost all cases, you ingest a lot of IoT data from
the devices / machines to other clusters (kafka, spark, cloud, AI,
whatever), but if you send data back to the device / machine, it is just
control data or other limited, small data sets. So a high throughput egress
from IoT devices does not imply a high throughput ingress. Therefore, I
recommend to not use this argument.

* So in a first round I'll concentrate on implementing a robust
Scraper-based PLC4X Kafka Connect Source, but drop the Sink entirely. If we
find out that a Sink makes sense we'll be able to add it in a later version*
I would recommend exactly the same. Focus on the important direction, and
implement the other direction later (if people ask for it and share their
use cases). Confluent did exactly the same for many other connectors, e.g.
AWS S3 Sink or MQTT Source. Then we also built MQTT Sink and S3 Source
later because we saw more demand for these, too.

Best regards,
Kai Waehner

On Tue, Aug 13, 2019 at 3:52 PM Christofer Dutz 
wrote:

> Hi all,
>
> so while I was working on the Kafka Sink I sort of started thinking if
> such a thing is a good idea to have at all.
> A Kafka system would be able to provide a vast stream of data that would
> have to be routed to a PLCs.
> On the one side, I haven't seen a single usecase of someone writing to a
> 

Re: [KAFKA] Refactoring the Kafka Connect plugin?

[Bjoern Hoeper]

Hi everyone,
I am on holiday currently so just a short note:
We have a use case at our customer that would need the sink functionality to 
exchange data between distinct DCSes controlling different areas. In a current 
implementation that provides this exchange the receiving dcs is an active pull 
component getting the data from the remote DCS.
I see two possible options for sink implementation. Some proxy component 
actively throttles writing to the DCS/PLC or the DCS pulling data itself as a 
custom Kafka Consumer. The only option that could be implemented independent of 
the control vendor addressed would be the first one.
After my holiday I will ask our customer if I can share some details.
Greetings from the Harbor of Rømø
Björn

Outlook für Android herunterladen


From: Julian Feinauer 
Sent: Tuesday, August 13, 2019 9:05:26 PM
To: dev@plc4x.apache.org ; megachu...@gmail.com 

Subject: AW: [KAFKA] Refactoring the Kafka Connect plugin?

Hi,

I agree with what you say.
We use Kafka and plc4x exactly the same way in prod :)

Prepaid Björn can also comment here as he also consists a Kafka based plc 
communication layer..

Julian

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: Re: [KAFKA] Refactoring the Kafka Connect plugin?
Von: Kai Wähner
An: dev@plc4x.apache.org
Cc:

Hi Chris,

here a few thoughts:

*I haven't seen a single use case of someone writing to a PLC with PLC4X *
=> This sounds similar to most IoT MQTT scenarios I see today. The main
challenge is to get data out of machines to analyze and use it. Writing
back (e.g. to control the systems) is the second step which comes later,
sometimes years later - or even never if not needed.

* I doubt such a scenario is ideal for the Kafka setup*
=> If you don't see it in other PLC4X projects, then I would not worry
about it too much for Kafka integration today.
However, I would not think too much about Kafka here. Either you see many
use cases for Sinks in general today for PLC4X, or you don't see them yet.
Some use Kafka, some use Java, some use Nifi or whatever.

*A PLC is not able to consume a lot of data until it chokes and stops
working*
=> This is an argument we hear often in Kafka community. Often it is *not*
valid (and we see more and more use cases where Kafka is just used for
transactional data like bank payments which are very low volume).
Therefore, Kafka is not just used for big data sets. In IoT scenarios (like
connected cars), we see more and more use cases where people also want to
send information back to the device (e.g. alerts or recommendations to the
driver, though, this is just a few messages, not comparable to sensor
egress messages).
In IoT scenarios, in almost all cases, you ingest a lot of IoT data from
the devices / machines to other clusters (kafka, spark, cloud, AI,
whatever), but if you send data back to the device / machine, it is just
control data or other limited, small data sets. So a high throughput egress
from IoT devices does not imply a high throughput ingress. Therefore, I
recommend to not use this argument.

* So in a first round I'll concentrate on implementing a robust
Scraper-based PLC4X Kafka Connect Source, but drop the Sink entirely. If we
find out that a Sink makes sense we'll be able to add it in a later version*
I would recommend exactly the same. Focus on the important direction, and
implement the other direction later (if people ask for it and share their
use cases). Confluent did exactly the same for many other connectors, e.g.
AWS S3 Sink or MQTT Source. Then we also built MQTT Sink and S3 Source
later because we saw more demand for these, too.

Best regards,
Kai Waehner

On Tue, Aug 13, 2019 at 3:52 PM Christofer Dutz 
wrote:

> Hi all,
>
> so while I was working on the Kafka Sink I sort of started thinking if
> such a thing is a good idea to have at all.
> A Kafka system would be able to provide a vast stream of data that would
> have to be routed to a PLCs.
> On the one side, I haven't seen a single usecase of someone writing to a
> PLC with PLC4X and I doubt such a scenario is ideal for the Kafka setup.
> A PLC is not able to consume a lot of data until it chokes and stops
> working.
>
> So in a first round I'll concentrate on implementing a robust
> Scraper-based PLC4X Kafka Connect Source, but drop the Sink entirely.
>
> If we find out that a Sink makes sense we'll be able to add it in a later
> version.
>
> What do you think?
>
> Chris
>
>
> Am 02.08.19, 11:24 schrieb "Julian Feinauer" <
> j.feina...@pragmaticminds.de>:
>
> Hi,
>
> I think that's the best way then.
>
> I agree with your suggestion.
>
> Julian
>
> Von meinem Mobiltelefon gesendet
>
>
>  Ursprüngliche Nachricht 
> Betreff: Re: [KAFKA] Refactoring the Kafka Connect plugin?
> Von: Christofer Dutz
> An: dev@plc4x.apache.org
> Cc:
>
> Hi all,
>
> Ok so it seems that Kafka only 

AW: [Draft] July Board Report

[Bjoern Hoeper]

Looks fine. Thanks for the effort!
Björn

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Donnerstag, 4. Juli 2019 12:02
An: dev@plc4x.apache.org
Betreff: [Draft] July Board Report 

Hi all,

I just added a new board report draft here:
https://cwiki.apache.org/confluence/display/PLC4X/2019-July

Will add the GitHub star, twitter numbers after lunch … please check if I 
missed anything significant.

Chris

AW: [DISCUSS] Retire Daffodil and SCXML?

[Bjoern Hoeper]

+1 cleaning up is always good
Björn

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Dienstag, 25. Juni 2019 09:42
An: dev@plc4x.apache.org
Betreff: [DISCUSS] Retire Daffodil and SCXML?

Hi all,

I would like to start to move the new code generation outside the sandbox.
For this I would like to replace the existing code-generation modules.

We currently have the dynamic driver modules, which were a proof of concept and 
have proven to be technically interesting, but performance-wise dead ends.

I would like to tag the revision with “last-dafodil” and get rid of them.

What do you think?

Chris

AW: Please welcome Matthias Strljic as new Apache PLC4X PMC and Committer

[Bjoern Hoeper]

Hey Matthias,
really nice to have you on board!
Björn

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Montag, 3. Juni 2019 11:28
An: dev@plc4x.apache.org
Betreff: Please welcome Matthias Strljic as new Apache PLC4X PMC and Committer

Hi all,

I would like to take the opportunity to officially welcome Matthias as new 
member of the Apache PLC4X PMC.

He has already provided important work by providing a first OPC-UA driver for 
PLC4X and are looking forward to hopefully a lot of great contributions from 
his side.

Matthias: Welcome in Team Toddy! :-)

Chris

AW: [BUILDS] What build system to use?

[Bjoern Hoeper]

Hey everyone,

I would also opt for Maven being at least the triggering build system because 
it also integrates well with Jenkins and the mechanisms behind it are quite 
understandable.
I think the main point we need to solve is to get some kind of documentation 
which build step in which profile triggers what, with which set of parameters 
to make it easier for people not working on the native parts to debug stuff. I 
think Chris Preflight check already adds a lot to this point.
I think for .NET we found quite a nice solution because it integrates well. For 
C++ it is always difficult to get everything working with different 
architectures and stuff. But I think the current Maven / CMake Integration is 
as good as it gets.

One question that remains open for me is if it is really necessary to build 
Thrift and all of Boost during the C++ compilation because both take a lot of 
time and are quite error prone.

So on the bottom line +1 for the integrated Maven solution. But I think it is 
not a real yes/no question but more of a "yes...but" kind of thing.

Best Regards
Björn



-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Montag, 27. Mai 2019 14:42
An: dev@plc4x.apache.org
Betreff: [BUILDS] What build system to use?

Hi all,

as the discussion had come up multiple times now … mainly on Slack, I would 
like to do a dedicated discussion here on the list about the topic.

Up to now we had built the build to generally build every module with maven, 
utilizing plugins to enable triggering builds with things like CMake.
The maven build then took care of packing the results and handling the 
dependencies (At least this was how I built things for the C++ module) With the 
plc4net however we’re using an execution of “dotnet” to build a solution.
In this case the build is entirely handled by dotnet and all maven does is 
trigger the build and fail if the execution fails with any non 0 return code.
We are currently doing something similar with python: where we’re just calling 
python to execute the setup.py script.

What is your opinion on how we should do our builds?
If we go down the path like I initially setup C++, we have the benefit of 
utilizing the maven ecosystem and we will not have any problems during releases.
It however comes with some comfort disadvantages for the “native” guys. But 
things like code-generation will work nicely.

If we go down a non-maven path we will have to deal with all of this ourselves 
… we will have to come up with a way to handle everything ourselves Or learn 
how to do it in python and CMake and dotnet, and … The other thing is that we 
can’t integrate the driver generation as easy as with maven.
Either we manually execute the code generation multiple times with maven to 
generate multiple output directories before executing the individual build 
system Or we have to build custom generators for every build-system we are 
using.

Even if I like the way I setup the C++ build, I doubt all people will like it 
as it requires them to do things differently than they are used to.
But I would strongly object implementing multiple code-generators.

One option would be to split up the plc4x git repo into multiple repos – each 
one for one language … so we’d have a plc4j, plc4cpp, plc4net and plc4python.
Each of these would be dedicated to one particular language and have build 
tools that fit them. However I strongly object this option, as it would require 
the Release manager to understand and setup each of these environments.

Another option which I think would be a valid compromise, would be to have all 
languages in one repo the way we currently have it and Maven as triggering 
build system.
The code is generated by maven but the build itself is handled by the 
particular build system.
This will require people working exclusively in VisualStudio or some Python 
IDE, to manually run a “mvn generate-sources” first, but I think that’s a 
reasonable restriction.

The benefit is that releasing this should be possible with our current release 
process which has a limited setup cost for the Release Manager.

I would opt for the hybrid option with Maven as initiating build system for 
releases and code generation and CI stuff but to have the native build system 
for every language to build the individual parts.
Namely this would be:

  *   Plc4cpp: CMake
  *   Plc4net: dotnet
  *   Plc4Python: python setup.py

Not quite sure how we can get the test-results to be reported correctly.

What are your thoughts on this?

Chris

AW: [VOTE] Apache PLC4X 0.4.0 RC1

[Bjoern Hoeper]

Hi,

I checked:
- no incubating in name or DISCLAIMER file
- all sources have ASF headers using rat plugin
- can compile from source

I ran 

mvnw.cmd -P with-java -P with-python -P with-proxies -P with-dotnet -P with-cpp 
-P with-python install

On Windows 10 64-Bit (Version 1803).

So +1 for the release.

Best Regards
Björn

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Mittwoch, 22. Mai 2019 00:08
An: dev@plc4x.apache.org
Betreff: [VOTE] Apache PLC4X 0.4.0 RC1

   Apache PLC4X 0.4.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.4.0
   Hash for the release tag: 10739fd4a6d201364d5021c78e7e1c529f04336d

   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-1009
   [2] https://dist.apache.org/repos/dist/dev/plc4x/0.4.0/rc1
   [3] https://www.apache.org/dev/release.html#approving-a-release
   [4] 
https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release

AW: [ANNOUNCE] Björn Höper joins PLC4X PMC

[Bjoern Hoeper]

Hey everyone,
I am very happy and honoured to join the PMC. I really enjoy the work with the 
project team and I am really looking excited to really advance the project.
I also like to especially thank Chris, Julian and Tim for the warm welcome and 
the support in getting started quickly with the project.
Best Regards
Björn

-Ursprüngliche Nachricht-
Von: Julian Feinauer  
Gesendet: Montag, 13. Mai 2019 17:32
An: dev@plc4x.apache.org
Betreff: [ANNOUNCE] Björn Höper joins PLC4X PMC

Hi all,

I am pleased to announce that Björn Höper has accepted an invitation to join 
the PLC4X PMC.
Although Björn is not so long with the Project yet, he has shown a lot of 
energy and willingness to bring the project forward.
And he also quickly became a very well-integrated part of our community.

Please join me in congratulating Björn, I’m very happy to have you on board!

Julian (on behalf of the PLC4X PMC)

AW: [Python] Adding build support for Python

[Bjoern Hoeper]

Hey Chris,
as far as I am informed the more modern standard for distribution in Python is 
python wheels. Which already contains the precompiled sources for the platforms 
in case of C extensions and is more or less a plain ZIP for pure Python 
(https://pypi.org/project/wheel/).

The mechanisms for building though are more or less the same as with eggs.

I personally would prefer the 2nd option even if it is slightly more 
uncomfortable for Python users but we avoid confusion with versions and other 
stuff.

Björn

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Dienstag, 30. April 2019 16:04
An: dev@plc4x.apache.org
Betreff: [Python] Adding build support for Python

Hi all,

After streamlining the build for C++ I now started to have a look at the Python 
part.

So in the python world it seems as if usually a setup.py is created and then 
python executes that script to build the project.
From a look at some sample python projects, it looks as if it generally 
contains some information we already have in the maven metadata.

When executing an example build and looking at the result, it looked as if the 
build generates a “egg” (Zip with ending “egg”) that contains unmodified 
versions of the sources and resources. In addition the script seems to generate 
a “egg-info” directory which contains a lot of different text files, these are 
then also included in the egg-zip.

So I think we have multiple options here:

  *   Have maven generate the egg-files from Maven exclusively
  *   Have maven generate a setup.py (by including data from maven to that 
file) and then run “python setup.py install” which then generates everything
  *   Write a setup.py (duplicating data from the pom) and executing a python 
build in the maven build

The last option has the benefit of working out of the box with Python and 
probably any Python IDE (If there is such a thing) but would have the drawback 
that we need to manually adjust it to pom changes (Version during releases) The 
first option would eliminate the need for another build tool (but would also 
eliminate the running of tests or other fancy python stuff) The middle option 
would be a compromise … it wouldn’t work out of the box, but after running 
“mvnw generate-resources” it could generate the missing files and the Python 
IDEs would pick it up.

I think the middle approach sort of feels like the sweet spot at the moment … 
or am I missing something here?
Are there other options, I didn’t mention?

What do you think?


Chris

AW: [DISCUSS ] PLC4X Teamware

[Bjoern Hoeper]

+1 like the idea

Björn
-Ursprüngliche Nachricht-
Von: Julian Feinauer  
Gesendet: Samstag, 27. April 2019 14:27
An: dev@plc4x.apache.org
Betreff: [DISCUSS ] PLC4X Teamware

Hi all,

As some of you may have heard, the plc4x project will be very well represented 
next weekend on a hackathon organized by the European commission.
As of today it seems like we will have Chris, Tim and myself from the pmc and 
even cooler Björn and Lukasz will be joining us from the community.
So it looks like this will be an awesome representation of our community and 
kind of a meetup.

And I thought for myself this would be a great opportunity (and also to 
celebrate the graduation) to order some team ware to show off that we all are 
members of "team toddy".

So I suggest to order some (zip) hoodies and shirts.
Of course everybody has to pay them for himself but if we order in batch the 
price will be party good.

For the hoodies it should be around 25 to 35€ each and for the shirts well 
below (calculated for 25 pc).

If we order them this weekend they will come on Friday and I could bring them 
to Brussel.
I will prepare an example with the right logo later today.

I also contacted Sally to check that we comply with all asf regulations.

What do you think?

Julian

PS if enough people agree I will prepare an order thread which closes tomorrow 
in the evening and place the order to get the stuff in time.

Von meinem Mobiltelefon gesendet

AW: [DISCUSS] The State and Future of PLC4X

[Bjoern Hoeper]

Hi erveryone,
I agree with Markus because OPC UA is somewhat universal. If we want something 
open source there is a stack which is quite evolved already: 
https://github.com/open62541/open62541 it is maintained by a bunch of 
institutes (one of them is the Process Control Institute in Aachen). So we 
should at least think about an adapter to OPC UA. The thing we would need to 
prove is that we can really get faster than the vendor OPC UA server.

Another thing that I think is promising and needed is adaptation to field bus 
systems like Profinet and EtherCAT because they provide good performance and a 
quite general applicability. And are at least not vendor specific.

Best Regards
Björn

-Ursprüngliche Nachricht-
Von: Markus Sommer  
Gesendet: Donnerstag, 18. April 2019 09:06
An: dev@plc4x.apache.org
Betreff: AW: [DISCUSS] The State and Future of PLC4X

Hi all,

I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x 
could realize a very fast OPC UA, this would be a massive advantage over other 
manufacturers.

Best regards

Markus

Freundliche Grüße

Markus Sommer
Geschäftsführer

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

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

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

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


-Ursprüngliche Nachricht-
Von: Julian Feinauer 
Gesendet: Mittwoch, 17. April 2019 09:07
An: dev@plc4x.apache.org
Betreff: [DISCUSS] The State and Future of PLC4X

Hi all,

as we had a lot of non-technical discussions and topics the last time (the 
coming of age of a software project, I guess) it’s time for us to go back to 
the real fun part and do technical shit.
I had a lot of discussions (on list and off list) with several people like 
Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the 
future of PLC4X as I see it (from a solely technical perspective).

Currently, I see several “fronts” or centers of activity (or where I think we 
should spend it).

  *   Language adoption – We should define and deliver APIs and bindings for 
other languages to bring what we currently have to other people and other 
communities. The activities we have there are currently (from my head): Markus 
and C++, Björn who wanted to investigate C# and the “Interop Server” which I 
played around a bit (in fact, Matthias made a python binding yesterday…)
  *   Driver Generation – This is a well-known Topic which is currently driven 
by Chris. This is a large topic, which includes
 *   Model Generation (currently dfdl and state-xml)
 *   Templates for many languages (will partially derive from above)
 *   A build process, to wire both together
 *   Some kind of Test Suite to check the correct generation of drivers
 *   Automated Documentation / Spec Generation (!!
  *   Ecosystem / Tools – We have a set of tools that are based on PLC4X and 
which enable to do things which where unthinkable before. Some are
 *   Scraper – A tool to scrape massive amounts of data from multiple PLCs 
based on a yml configuration, this is mostly driven by Tim
 *   OPC UA Server – Yet to come. Maps OPC UA requests to PLC4X requests 
which then go native to the PLCs. Matthias started some work on this, Tim 
looked over it and I think Chris plans on implementing something here also
 *   We had multiple discussions about tools that “guess” something about 
locations of variables or their types. Chris brought that up yesterday and 
plans to do something there, Matthias and I discussed this several times and we 
plan to also do something with one or two students there
  *   New programming models – As plc4x is open, it allows us to implement new 
programming models on top of it. The best example I can give is OPM, the JPA 
equivalent of PLC4X. The idea is to work with POJOs and annotations and 
EntityManagers (as Beans) and have a “type safe” and Business-esque way to 
communicate with PLCs.

Here I see a lot of potential and possible next steps could be (discussed by 
Matthias and me)

 *   “Richer” Typesystem (not just primitives and Arrays as currently) 
which covers complex objects
 *   Mapping of complex objects from POJOs to PLC segments (Like structs in 
S7 or ADS)
 *   Auto-generation of annotated POJOs from PLC 

AW: Next PLC4X Meetup

[Bjoern Hoeper]

As already mentioned Frankfurt would be perfectly okay for me.

I personally think that the presentation by Chris is needed to start the 
discussion about the driver generation.

The thing I could offer is to give a presentation about the architecture we 
currently use at our customers site to retrieve data from the SCADA. The 
presentation is not directly related to plc4x but may provide some 
"inspiration" for implementations as this architecture is running for more than 
20 years now quite reliably.
But to be honest I personally would opt for a presentation about running plc4x 
in production because it may offer some insights regarding implementation 
details for other languages as well.

Björn

-Ursprüngliche Nachricht-
Von: Julian Feinauer  
Gesendet: Sonntag, 14. April 2019 17:08
An: dev@plc4x.apache.org
Betreff: Next PLC4X Meetup

Hi all,

we already had some discussions about that, but I think its time to become a 
bit more concrete.
I propose to have the next (South-)German PLC4X Meetup soon.
From the discussion, already pragmatic industries (Nürtingen) and Codecentric 
(Frankfurt/Main) offered to be the host.
As Frankfurt is more central, I think this is a good location (and the 
codecentric office is really nice AND there is the PLC4X IoT Lab...).

So  I suggest to start to find a Date for the Meetup ASAP.
For this time, I would suggest to have like one or two "small" presentations 
and the rest of the time discussion.

Good Presentation candidates for me would be:
- Chris with the driver generation and some details about that
- We (Tim or I) with our experiences from running PLC4X in prod for about halb 
a year now
- The Landscape of PLC4J with all the tools and utils around the "main" 
programm like OPM, Scraper, ...

What do the others think?

@Chris: If we do it in Ffm you are the host, so it should be up to you to start 
a doodle, as you know when you and you're room is available and when not. 
Otherwise I would have it already started with this mail : )

Julian

AW: [jira] [Created] (PLC4X-110) Implement Basic .NET API

[Bjoern Hoeper]

I already started implementing the basic outer parts today.

I like Julians Idea regarding the Thrift server. I already commented in JIRA 
that it may be a good idea to have it as a separate issue to make it more clear 
/ easier to find for users of other languages.

Apart from that would it be of help to you Chris if I implement one of the 
drivers (S7 would be quite good because it is quite common and I have a device 
ready)?

Björn

-Ursprüngliche Nachricht-
Von: Julian Feinauer  
Gesendet: Sonntag, 14. April 2019 17:02
An: dev@plc4x.apache.org
Betreff: Re: [jira] [Created] (PLC4X-110) Implement Basic .NET API

Also, big +1 from me!
I would love to see this happen soon.
As we will still need some time to get the driver generation working, I 
suggest, as I suggested once back in the days to implement a Thrift based Java 
Server as temporary solution to already implement these interfaces for C# and 
Python or so (and perhaps even Javascript, only because its so crazy to control 
a PLC from a webbrowser).

This would help us to first, get a borader community on board and second, to 
already develop these APIs.

Julian 

On 2019/04/14 11:33:41, Christofer Dutz  wrote: 
> Hi Björn,
> 
> a strong and enthusiastic +1 for this one.
> 
> Perhaps as a simple way to get started (the same we did it with c++), would 
> be for you to have a look at the Java or C++ API for understanding the 
> functional requirements and to implement a C# version in your IDE of choice. 
> As soon as you've got something to integrate you could attach that project to 
> the Issue and we'll work on integrating this into the build together.
> 
> I also added you to the PLC4X Contributors group in Jira, so you could assign 
> this issue to yourself.
> 
> Chris
> 
> Am 14.04.19, 11:27 schrieb "Björn Höper (JIRA)" :
> 
> Björn Höper created PLC4X-110:
> -
> 
>  Summary: Implement Basic .NET API
>  Key: PLC4X-110
>  URL: https://issues.apache.org/jira/browse/PLC4X-110
>  Project: Apache PLC4X
>   Issue Type: New Feature
>   Components: API, Core
> Reporter: Björn Höper
> 
> 
> In order to extend PLC4X to also include .NET as target framwork a basic 
> API should be implemented that may serve as a starting point for the 
> integration of (possibly generated) drivers with .NET
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
> 
> 
> 

AW: Integration of other Languages / Daffodil

[Bjoern Hoeper]

Hey,
ok I agree that we should have enough time to discuss this quite important 
topic so a separate meeting is much better.

I would be fine going to Frankfurt and I am quite flexible still in May.

Best Regards
Björn

-Ursprüngliche Nachricht-
Von: Christofer Dutz  
Gesendet: Mittwoch, 10. April 2019 10:22
An: dev@plc4x.apache.org
Betreff: Re: Integration of other Languages / Daffodil

Hi Björn,

while this would be possible, we planned on doing some initial heavy lifting 
for Edgent on that day. 
So I would suggest a separate date for a PLC4X multi-language-kick-off meeting 
...

What do you think? I definitely can offer our Frankfurt office as location as 
it's intentionally planned to have meetups here.
Just know that it's really good to reach for all ... But I'm also fine with 
alternate locations.

Chris

 

Am 10.04.19, 10:14 schrieb "Bjoern Hoeper" :

Hey,
I am also glad to join the team and I am really happy that the discussion 
took off this well.

I would +1 Julians Proposal for a personal meeting at due time for 
discussing the code generation. Something that came to my mind was to join this 
meeting with the Apache Edgent Meetup you mentioned at the conference (6th May 
if I remember this correctly). Would this be an option?

Regarding the C# API I can work out a draft with just classes and 
interfaces.
I have a bit of experience using CMake with .NET so I could also work out a 
way for integrating the C# parts into the build. 
My ultimate goal would be to have the .NET Libraries compatible to .NET 
Standard 2.0 so that it is usable with .NET Core and .NET Full. One implication 
of this would be that we need to think about the exact driver integration 
(Native code gets a little bit harder but is possible; but I would prefer a 
full .NET based solution).

Best Regards
Björn


-Ursprüngliche Nachricht-
Von: Julian Feinauer  
Gesendet: Mittwoch, 10. April 2019 09:21
An: dev@plc4x.apache.org
Betreff: Re: Integration of other Languages / Daffodil

Hi,

I did not intend to hurry you in any way, chris : ) You are the one to set 
the next steps... I just wanted to bring the topic back (after all that 
paperwork).
And after your statements here, I would even more like to have a meetup 
where you present this a bit more detailed.

What do you think?
Perhaps in a month or so?

Julian

PS.: With the growing community, we should consider to do this perhaps more 
regularly, or?

Am 10.04.19, 09:15 schrieb "Christofer Dutz" :

Hi Julian,

I agree with bringing this topic more back to the core ... as you can 
imagine it feels like I have not been working on this to 
100% as about 90% of my time and energy was consumed with 
pre-graduation work. I think this will be over about 08:45 CET tomorrow ;-)

I guess I still will need a few more days to get back in the saddle and 
finish a first fully working draft of the code-generator.
Currently it generates empty java class files ... guess I'll still have 
to do some tweaking and adjusting, but should not be too much work.
Till that I doubt working on templates makes too much sense as I think 
it would take more time to do the transfer needed to 
join in, than I would need to finish it. Of course would I document 
everything, but I didn't up to now as I was building, tearing apart, 
rebuilding, refactoring, ... didn't want to keep the documentation up 
to date.

Also that will currently generated the model classes as well as the 
serializers and de-serializers ... after that I need to get started on the
Driver logic (State-Machine) itself. But I guess having the class 
generation for the messages would be a great first start.

But what we really need, is an API module (which is not generated) with 
a beautiful C# API module. Then integrating that into 
Our build will also be a manageable challenge (As I mentioned CMake 
does seem to support C# and .NET builds) ... would be great 
if someone could work on that. 

I guess till I've finished a first working prototype of the model 
generation, we could then start porting these templates to other languages.

In parallel me and some people interested, could work on the logic 
generation (with java templates) and as soon as that's done,
Hopefully the language templates for the model are done, we could 
create the logic templates for the other languages ...

You think that's a good idea and approach?

Chris



Am 10.04.19, 08:53 schrieb "Julian Feinauer" 
:

Hi Björn,

I'm very happy to see you here on the list!

Currently, this "generat

AW: Integration of other Languages / Daffodil

[Bjoern Hoeper]

s is usually quite challenging ... but I have read that CMake 
does have options for this ... but we'll work that our as soon as it comes up.

The step after that would be to manually port a driver from one 
existing language to C# (ideally the generated classes) and create templates 
from that code ... or directly start writing templates, however I think that's 
more challenging as you don't have content assist of your IDE in Freemarker (I 
think).

I hope that explains things and I really hope this email goes 
through (better save it first)

    Chris


On 2019/04/08 13:44:35, Bjoern Hoeper  wrote: 
> Hi everyone,
> I got in touch with Chris and Julian during the buildingIoT 
Conference in Cologne and I would like to participate in the further 
development of PLC4X. Our main interest is to extend PLC4X to make it usable 
with .NET / C#.
> 
> So after looking at the sources and the discussions in the 
mailing list I was wondering what would be the best move forward regarding the 
integration of other languages in general and the decoupling of the protocol 
definition from the actual API implementation in a particular language. As far 
as I understand the current status Apache Daffodil is  a candidate technology 
for generating the adapter code. But at the current moment Daffodil does not 
support templating of classes. Furthermore there are existing APIs for Java and 
Scala but no implementation for languages not executed on the JVM so we would 
need to have an implementation of the Daffodil APIs in every language we want 
to support in the future.
> Are there any Ideas existing already about an Architecture to 
support languages besides Java? If not I would like to encourage a discussion 
about this topic because I think it will get quite fundamental as soon as the 
adoption of further languages gains some traction.
> Best Regards
> Björn
> 
> =
> Dipl.-Ing. B. Höper
> Geschäftsführer
> 
> LTSoft - Agentur für Leittechnik-Software GmbH
> Veilchenweg 37a
> 51107 Köln
> 
> Telefon:   +49 (0) 221 - 79 00 35 31
> Telefax:   +49 (0) 221 - 79 00 35 35
> Mobil:  +49 (0) 173 - 28 36 904
> Email:  hoe...@ltsoft.de<mailto:hoe...@ltsoft.de>
> =
> 
> 

Integration of other Languages / Daffodil

[Bjoern Hoeper]

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

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

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

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

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