Please welcome César García as our new VP/Chair

[Christofer Dutz]

Hi all,

in yesterday’s board meeting César García was accepted as new Chair of the 
Apache PLC4X project.

Thanks for stepping up, Cesar.

Chris

AW: Switching from asciidoctor to docusaurus for improving / changing our website setup

[Christofer Dutz]

I think we have setup the website to always reflect the state of “develop” … if 
we simply switch it to the “release” branch, then the website will magically 
update every time we release.

I think this was a relic of the times when things moved so quickly, that we 
always wanted the most recent stuff out in the wild.
I do think it would make sense to have the page reflect the latest version on 
the “release” branch and to possibly have a second copy of the site under 
“plc4x.apache.org/dev/”.

And regarding the weekend stuff … it’s just that it happened in the past that 
things were not finished and broke and I was stuck having to fix them … so I 
just wanted to make it clear, that I’m not going to do that in case of a switch 
of website tools.

Chris

Von: Lukas Ott 
Datum: Montag, 16. September 2024 um 17:01
An: dev@plc4x.apache.org , Dominik Riemer 

Betreff: Re: Switching from asciidoctor to docusaurus for improving / changing 
our website setup
Totally agreeing with your statement. As far as I understand
the streampipes setup works in a similar way. The website updates when you
push code changes to https://github.com/apache/streampipes if I understand
Dominiks statement correctly?

Of course we can also just wait until the 4.0.0 site plugin release and the
fixes.

And additionally I want to highlight that nobody wants you to spend your
weekend on fixing stuff!

I just like the way all the docs and stuff updates on the website when
StreamPipes does a new release.

@Dominik Riemer   Please elaborate how the setup works
and how much effort it would be to switch to Docusaurus from your
perspective.

If this change implies a lot more effort then we just stay with the current
setup. At least we have then documented on the mailing list about this
option :-)

Cheers
Lukas

Am Mo., 16. Sept. 2024 um 16:35 Uhr schrieb Christofer Dutz <
christofer.d...@c-ware.de>:

> Admittedly the thing I love about our setup, is that you can simply update
> the website for our stuff in the development environment we’ve already got
> open.
> Current everything is working fine, and I don’t actually see the need to
> change anything right now.
> The Maven folks will finish the site plugin 4.0.0 some day and then the
> asciidoctor folks will provide an updated plugin.
> I know we suck at updating our documentation … for that I just updated at
> least the updating of our driver options to run automatically.
>
> Would this still work with docsaurus?
>
> I’m definitely not blocking any change, if the team wants to … I just
> don’t really see a need to do so and I’m not going to invest more weekends
> in fixing stuff because of such a switch.
>
> Chris
>
>
>
> Von: Lukas Ott 
> Datum: Montag, 16. September 2024 um 14:56
> An: dev@plc4x.apache.org 
> Betreff: Switching from asciidoctor to docusaurus for improving / changing
> our website setup
> Hi PLC4X developers,
>
> After Chris did a great job on cleaning up dependencies and trying to
> update a lot of POMs it ended up in this comment related to
> https://github.com/apache/plc4x/pull/1423 and
> https://github.com/apache/plc4x/pull/1419
>
> "Yeah ... updating asciidoctor and the site plugin is a HUGE mess ...
> especially with the update of the doxia tools ... This seems to break
> EVERYTHING. Unfortunately the asciidoctor folks are planning on updating
> and releasing the asciidoctor plugin as soon as the site plugin in version
> 4 is finally released.
> asciidoctor/asciidoctor-maven-plugin#685
> See also related PR for updating the site plugin: #1419" - cdutz
>
> IMHO Dominik Riemer from the https://streampipes.apache.org/ team have
> neat
> setup with:
> https://github.com/facebook/docusaurus
>
> As soon as they push things to https://github.com/apache/streampipes
> It updates documentation on the website:
> https://github.com/apache/streampipes-website which is then deployed:
> https://streampipes.apache.org/
>
> Dominik offered to support us with the initial setup and I would vote for
> it.
>
> If this mail gets no objections after 72 hours I would ask Dominik to spin
> up a PR request to get started migrating to the docusaurus approach.
>
> Please comment and give feedback! Thank you!
>
> Cheers
> Lukas
>

AW: Switching from asciidoctor to docusaurus for improving / changing our website setup

[Christofer Dutz]

Admittedly the thing I love about our setup, is that you can simply update the 
website for our stuff in the development environment we’ve already got open.
Current everything is working fine, and I don’t actually see the need to change 
anything right now.
The Maven folks will finish the site plugin 4.0.0 some day and then the 
asciidoctor folks will provide an updated plugin.
I know we suck at updating our documentation … for that I just updated at least 
the updating of our driver options to run automatically.

Would this still work with docsaurus?

I’m definitely not blocking any change, if the team wants to … I just don’t 
really see a need to do so and I’m not going to invest more weekends in fixing 
stuff because of such a switch.

Chris



Von: Lukas Ott 
Datum: Montag, 16. September 2024 um 14:56
An: dev@plc4x.apache.org 
Betreff: Switching from asciidoctor to docusaurus for improving / changing our 
website setup
Hi PLC4X developers,

After Chris did a great job on cleaning up dependencies and trying to
update a lot of POMs it ended up in this comment related to
https://github.com/apache/plc4x/pull/1423 and
https://github.com/apache/plc4x/pull/1419

"Yeah ... updating asciidoctor and the site plugin is a HUGE mess ...
especially with the update of the doxia tools ... This seems to break
EVERYTHING. Unfortunately the asciidoctor folks are planning on updating
and releasing the asciidoctor plugin as soon as the site plugin in version
4 is finally released.
asciidoctor/asciidoctor-maven-plugin#685
See also related PR for updating the site plugin: #1419" - cdutz

IMHO Dominik Riemer from the https://streampipes.apache.org/ team have neat
setup with:
https://github.com/facebook/docusaurus

As soon as they push things to https://github.com/apache/streampipes
It updates documentation on the website:
https://github.com/apache/streampipes-website which is then deployed:
https://streampipes.apache.org/

Dominik offered to support us with the initial setup and I would vote for
it.

If this mail gets no objections after 72 hours I would ask Dominik to spin
up a PR request to get started migrating to the docusaurus approach.

Please comment and give feedback! Thank you!

Cheers
Lukas

AW: [DISCUSS] How should the browse api handle arrays?

[Christofer Dutz]

But nevertheless …

as the amount of feedback here on this list is quite low … If I don’t hear any 
objections, I’ll just go ahead implementing it.
it would however be great to actively get consent, as that shows active 
approval and continuously doing things with timeouts is just stupid and slows 
things down.

Chris


Von: Christofer Dutz 
Datum: Montag, 16. September 2024 um 10:42
An: dev@plc4x.apache.org 
Betreff: AW: [DISCUSS] How should the browse api handle arrays?
Hi all,

I just came up with a different idea … we could add an “resolveArrays” method, 
that returns a browseItem, where the arrays are resolved as children.
So as in below example the BrowseItem would have been a
SomeMultiDimensionalArrayVariable ([1..4][3..5])

  *   ChildProp1
  *   ChildProp2

Then the resolve array would return as below, where for example “[3]” is a 
child of “SomeMultiDimensionalArrayVariable”

I am just trying to avoid clients from having to implement the resolving of 
addresses in a too complex way.
I think my UI experiment is a great example of such a tool and how people would 
use our API.
If we had an implementation such as the one, I mentioned, I think things would 
be a lot simpler.

The original would be the more formally correct version, the resolved version 
would be the more usable version.


Chris

Von: Christofer Dutz 
Datum: Montag, 9. September 2024 um 19:22
An: dev@plc4x.apache.org 
Betreff: AW: [DISCUSS] How should the browse api handle arrays?
Soo,

Currently trying to think of ways how to return things correctly in our browse 
API. Assuming we’re following option 2 and we want to do all the work in the 
browse part of the driver.
When we have non-array items it’s pretty trivial and in case of a struct type, 
the children simply reflect the child structure of the parent.

However, how should we handle arrays? I currently am leaning towards 
considering the array dimensions as “children” … so if we have a 
two-dimensional array of a struct, it would look something like this:


SomeMultiDimensionalArrayVariable ([1..4][3..5]):

  *   [1]: ([3..5])
 *   [3]:
*   ChildProp1
*   ChildProp2
 *   [4]:
*   ChildProp1
*   ChildProp2
 *   [5]:
*   ChildProp1
*   ChildProp2
  *   [2]: ([3..5])
 *   [3]:
*   ChildProp1
*   ChildProp2
 *   [4]:
*   ChildProp1
*   ChildProp2
 *   [5]:
*   ChildProp1
*   ChildProp2
  *   [3]: ([3..5])
 *   [3]:
*   ChildProp1
*   ChildProp2
 *   [4]:
*   ChildProp1
*   ChildProp2
 *   [5]:
*   ChildProp1
*   ChildProp2
  *   [4] : ([3..5])
 *   [3]:
*   ChildProp1
*   ChildProp2
 *   [4]:
*   ChildProp1
*   ChildProp2
 *   [5]:
*   ChildProp1
*   ChildProp2

Each node would have array information so some more advanced tooling could make 
use of it (in round braces)

Chris

Von: Christofer Dutz 
Datum: Montag, 9. September 2024 um 10:17
An: dev@plc4x.apache.org 
Betreff: AW: [DISCUSS] How should the browse api handle arrays?
I just remembered another bonus of option 2 that I had been thinking about 
yesterday:

If the client needs to build the address based on templates sent from the API 
(like in option 1), the client needs to know the assembly rules of the 
corresponding protocol.
Simply using a “.” as separator might not be valid for all protocols. By 
sending fully exploded browse items, we give the driver implementation 100% 
control, over this (and keep this complexity away from our users).

Chris

Von: Christofer Dutz 
Datum: Montag, 9. September 2024 um 10:10
An: dev@plc4x.apache.org 
Betreff: [DISCUSS] How should the browse api handle arrays?
Hi all,

While working on my little side-project (which actually puts together all the 
APIs for me for the first time) I noticed that currently the browse API has 
it’s shortcomings when it comes to handling arrays.

For example, the fully qualified address:
MAIN.hurz_STRUCT_ARRAY[2].hurz_DATE

Is returned as:
MAIN.hurz_STRUCT_ARRAY.hurz_DATE

Omitting the array portion.

Now I could think of multiple ways to handle this:


  1.  We return one item with the full dimensions: 
MAIN.hurz_STRUCT_ARRAY[1…3].hurz_DATE
  2.  We return one item per array item:

MAIN.hurz_STRUCT_ARRAY

MAIN.hurz_STRUCT_ARRAY[1].hurz_DATE

MAIN.hurz_STRUCT_ARRAY[2].hurz_DATE

MAIN.hurz_STRUCT_ARRAY[3].hurz_DATE



I would assume option 2 makes integration into other systems a LOT simpler, but 
extend the size of the response dramatically.



Considering that the browse functionality would only be used occasionally, I 
would lean more towards option 2 … mainly because this way users of the API 
don’t have to post-process the responses.

Hereby they can do less errors or misinterpret things.



What do you think?



If I don’t hear any feedback, I’ll start working on implementing option 2 this 
Friday.



Chris

AW: [DISCUSS] How should the browse api handle arrays?

[Christofer Dutz]

Hi all,

I just came up with a different idea … we could add an “resolveArrays” method, 
that returns a browseItem, where the arrays are resolved as children.
So as in below example the BrowseItem would have been a
SomeMultiDimensionalArrayVariable ([1..4][3..5])

  *   ChildProp1
  *   ChildProp2

Then the resolve array would return as below, where for example “[3]” is a 
child of “SomeMultiDimensionalArrayVariable”

I am just trying to avoid clients from having to implement the resolving of 
addresses in a too complex way.
I think my UI experiment is a great example of such a tool and how people would 
use our API.
If we had an implementation such as the one, I mentioned, I think things would 
be a lot simpler.

The original would be the more formally correct version, the resolved version 
would be the more usable version.


Chris

Von: Christofer Dutz 
Datum: Montag, 9. September 2024 um 19:22
An: dev@plc4x.apache.org 
Betreff: AW: [DISCUSS] How should the browse api handle arrays?
Soo,

Currently trying to think of ways how to return things correctly in our browse 
API. Assuming we’re following option 2 and we want to do all the work in the 
browse part of the driver.
When we have non-array items it’s pretty trivial and in case of a struct type, 
the children simply reflect the child structure of the parent.

However, how should we handle arrays? I currently am leaning towards 
considering the array dimensions as “children” … so if we have a 
two-dimensional array of a struct, it would look something like this:


SomeMultiDimensionalArrayVariable ([1..4][3..5]):

  *   [1]: ([3..5])
 *   [3]:
*   ChildProp1
*   ChildProp2
 *   [4]:
*   ChildProp1
*   ChildProp2
 *   [5]:
*   ChildProp1
*   ChildProp2
  *   [2]: ([3..5])
 *   [3]:
*   ChildProp1
*   ChildProp2
 *   [4]:
*   ChildProp1
*   ChildProp2
 *   [5]:
*   ChildProp1
*   ChildProp2
  *   [3]: ([3..5])
 *   [3]:
*   ChildProp1
*   ChildProp2
 *   [4]:
*   ChildProp1
*   ChildProp2
 *   [5]:
*   ChildProp1
*   ChildProp2
  *   [4] : ([3..5])
 *   [3]:
*   ChildProp1
*   ChildProp2
 *   [4]:
*   ChildProp1
*   ChildProp2
 *   [5]:
*   ChildProp1
*   ChildProp2

Each node would have array information so some more advanced tooling could make 
use of it (in round braces)

Chris

Von: Christofer Dutz 
Datum: Montag, 9. September 2024 um 10:17
An: dev@plc4x.apache.org 
Betreff: AW: [DISCUSS] How should the browse api handle arrays?
I just remembered another bonus of option 2 that I had been thinking about 
yesterday:

If the client needs to build the address based on templates sent from the API 
(like in option 1), the client needs to know the assembly rules of the 
corresponding protocol.
Simply using a “.” as separator might not be valid for all protocols. By 
sending fully exploded browse items, we give the driver implementation 100% 
control, over this (and keep this complexity away from our users).

Chris

Von: Christofer Dutz 
Datum: Montag, 9. September 2024 um 10:10
An: dev@plc4x.apache.org 
Betreff: [DISCUSS] How should the browse api handle arrays?
Hi all,

While working on my little side-project (which actually puts together all the 
APIs for me for the first time) I noticed that currently the browse API has 
it’s shortcomings when it comes to handling arrays.

For example, the fully qualified address:
MAIN.hurz_STRUCT_ARRAY[2].hurz_DATE

Is returned as:
MAIN.hurz_STRUCT_ARRAY.hurz_DATE

Omitting the array portion.

Now I could think of multiple ways to handle this:


  1.  We return one item with the full dimensions: 
MAIN.hurz_STRUCT_ARRAY[1…3].hurz_DATE
  2.  We return one item per array item:

MAIN.hurz_STRUCT_ARRAY

MAIN.hurz_STRUCT_ARRAY[1].hurz_DATE

MAIN.hurz_STRUCT_ARRAY[2].hurz_DATE

MAIN.hurz_STRUCT_ARRAY[3].hurz_DATE



I would assume option 2 makes integration into other systems a LOT simpler, but 
extend the size of the response dramatically.



Considering that the browse functionality would only be used occasionally, I 
would lean more towards option 2 … mainly because this way users of the API 
don’t have to post-process the responses.

Hereby they can do less errors or misinterpret things.



What do you think?



If I don’t hear any feedback, I’ll start working on implementing option 2 this 
Friday.



Chris

Re: Does Plc4j connects to MXOPC Server UA by Mitsubishi

[Christofer Dutz]

Ok...

Then I guess our team mates taking care of the opc-ua driver will be able to 
help. I would recommend opening an issue on github and adding some more 
information. Such as maybe the bit of the choice where you're using plc4x, the 
exact log output of the error etc.

Chris

Gesendet von Outlook für Android

From: Kundan Negi 
Sent: Sunday, September 15, 2024 11:06:12 AM
To: dev@plc4x.apache.org 
Subject: Does Plc4j connects to MXOPC Server UA by Mitsubishi

Hi Plc4x Team,
I want to know *whether Plc4j connects to MXOPC Server UA by MItsubishi*. I
earlier used MXOPC DA by Mitsubishi. I am trying to connect to MXOPC UA
Server but it is failing to connect. Any help would be highly appreciated.

Thanks and Regards
Kundan Negi

Re: Does plc4x support MXOPC Server UA by Mitsubishi

[Christofer Dutz]

As far as I understood the UA version supports opc-ua, so I would say: yes. If 
you've got a model speaking opc-da, then unfortunately not.

Chris

Gesendet von Outlook für Android

From: Kundan Negi 
Sent: Saturday, September 14, 2024 7:30:42 PM
To: dev@plc4x.apache.org 
Subject: Does plc4x support MXOPC Server UA by Mitsubishi

Hi Team Apache Plc4x,
I am not able to *connect Plc4j to MXOPC Server UA by Mitsubishi*. Could
you please confirm whether Plc4j connects to it or not.

Thank and Regards
Kundan Negi

[DISCUSS] How should the browse api handle arrays?

[Christofer Dutz]

Hi all,

While working on my little side-project (which actually puts together all the 
APIs for me for the first time) I noticed that currently the browse API has 
it’s shortcomings when it comes to handling arrays.

For example, the fully qualified address:
MAIN.hurz_STRUCT_ARRAY[2].hurz_DATE

Is returned as:
MAIN.hurz_STRUCT_ARRAY.hurz_DATE

Omitting the array portion.

Now I could think of multiple ways to handle this:


  1.  We return one item with the full dimensions: 
MAIN.hurz_STRUCT_ARRAY[1…3].hurz_DATE
  2.  We return one item per array item:

MAIN.hurz_STRUCT_ARRAY

MAIN.hurz_STRUCT_ARRAY[1].hurz_DATE

MAIN.hurz_STRUCT_ARRAY[2].hurz_DATE

MAIN.hurz_STRUCT_ARRAY[3].hurz_DATE



I would assume option 2 makes integration into other systems a LOT simpler, but 
extend the size of the response dramatically.



Considering that the browse functionality would only be used occasionally, I 
would lean more towards option 2 … mainly because this way users of the API 
don’t have to post-process the responses.

Hereby they can do less errors or misinterpret things.



What do you think?



If I don’t hear any feedback, I’ll start working on implementing option 2 this 
Friday.



Chris

AW: Progress on OPC UA notifications

[Christofer Dutz]

Yeah … interestingly indeed finding the „official way to address something” is 
some times the most challenging thing.
Unfortunately I am so staying away from OPC-UA in general, that I can’t help 
you with that.

Chris

Von: Łukasz Dywicki 
Datum: Freitag, 23. August 2024 um 11:20
An: dev@plc4x.apache.org 
Betreff: Re: Progress on OPC UA notifications
Event subscriptions at the API level are indeed a perfect match for
alarms and alerts. So far we have alarms (event) subscriptions
implemented only for S7, which uses special tag syntax, different than
regular read/write tags.
Here situation is similar, however I don't have any reference material
of how official tag syntax looks a like. For s7 there are some pointers
coming from official tooling and their syntax (i.e. %DB, %Q). For OPC-UA
we have only node (ns=x;i=y).
I haven't found so far any example of what syntax people use to
subscribe events. There was one scada documentation which allowed to
specify attribute id, but its vendor specific. I don't think UA specs
advertises anything like that.
That's why I'm in the need to define tag syntax which will serve us in
initial implementation and let gather community feedback.
So OPC UA subscription tag will need to include optional node id and
event field for a start. Data type will remain optional, in case user
will require explicit type mapping.
For now we'll skip attribute id in tag syntax to do not complicate
things even more.

Best,
Łukasz

On 23.08.2024 07:26, Christofer Dutz wrote:
> Don't we already have "alerts" as a concept in subscriptions? Isn't that 
> pretty much the same as An event?
>
> Chris
>
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> 
> From: Łukasz Dywicki 
> Sent: Friday, August 23, 2024 2:12:09 AM
> To: dev@plc4x.apache.org 
> Subject: Progress on OPC UA notifications
>
> Hey folks,
> I wanted to share, and also source your ideas on tag syntax for OPC UA.
> I've managed to add missing messages and a bit of PoC logic to emulate
> event subscription. It seems to work, now its time to adjust
> subscription handling logic.
>
> In principle OPC UA specification defines 3 kinds of notifications [1]:
> 1) Data Change
> 2) Event
> 3) Status Change
>
> These have different calls to submit request and deliver different
> information. Before we go deeper, remember that in OPC UA everything is
> based on request/response paradigm. There is no push side per say, we
> send a publish request to receive notification message.
> What our Java driver currently cover is data change, so its more or less
> cyclic update / data change. The event notification requires pointing
> out what fields of event are interesting (i.e Id, Type, Time, Message),
> we then receive them. Still, event notification have to be hooked at
> specific NodeId, Milo's examples use Server (ns=0;i=2253) and
> EventNotifier (12 / 0x0c) attribute, whereas data change aim Value (13 /
> 0x0d) attribute. These of you who are familiar with OPC-UA can see some
> similarities due to multiple levels of complexity (object vs its property).
> Interesting animal in this zoo is status change which can be used to
> receive information about bad signal quality (whatever it means).
>
> Out of these 3 notification kinds data and status change are pretty much
> 1:1 (node id -> value, node id -> status), so each subscribed tag
> returns single value. The metadata concept [2] opens possibility to
> return more information to caller, including status.
> The event notification however is different, because first and foremost,
> we subscribe static node id (not sure if it can change), and do not send
> node id but browse path which is just a text:
>
> new SimpleAttributeOperand(nodeId,
> Arrays.asList(new QualifiedName(0, new PascalString >>("EventId")<<)),
> AttributeId.Value.getValue(),
> OpcuaProtocolLogic.NULL_STRING
> )
>
> Additionally, there might be filter criteria [3] (I didn't try yet),
> which can be used to supply more conditions for receiving data.
>
> Coming to the point - what do you think about defining new tag type for
> OPC UA to cover event fields? With this we could use this tag to specify
> event fields (browse path), and eventually use tag attributes for criteria:
>
> .addEventTagAddress("EventId;REAL")
> .addEventTagAddress("ns=0;i=2253;EventId;REAL") // same as above
> .addEventTagAddress("Time;DATETIME")
> .addEventTagAddress("Message;STRING{like=Fatal error}")
>
> In above example the default subscribe is assumed to be ns=0;i=2253, but
> each event tag address would require a path.
>
> WDYT?
>
> Best,
> Łukasz
>
> [1] https://reference.opcfoundation.org/Core/Part4/v104/docs/7.20
> [2] https://github.com/apache/plc4x/pull/1725
> [3] https://reference.opcfoundation.org/Core/Part4/v104/docs/7.4.4
>

Re: Progress on OPC UA notifications

[Christofer Dutz]

Don't we already have "alerts" as a concept in subscriptions? Isn't that pretty 
much the same as An event?

Chris


Gesendet von Outlook für Android

From: Łukasz Dywicki 
Sent: Friday, August 23, 2024 2:12:09 AM
To: dev@plc4x.apache.org 
Subject: Progress on OPC UA notifications

Hey folks,
I wanted to share, and also source your ideas on tag syntax for OPC UA.
I've managed to add missing messages and a bit of PoC logic to emulate
event subscription. It seems to work, now its time to adjust
subscription handling logic.

In principle OPC UA specification defines 3 kinds of notifications [1]:
1) Data Change
2) Event
3) Status Change

These have different calls to submit request and deliver different
information. Before we go deeper, remember that in OPC UA everything is
based on request/response paradigm. There is no push side per say, we
send a publish request to receive notification message.
What our Java driver currently cover is data change, so its more or less
cyclic update / data change. The event notification requires pointing
out what fields of event are interesting (i.e Id, Type, Time, Message),
we then receive them. Still, event notification have to be hooked at
specific NodeId, Milo's examples use Server (ns=0;i=2253) and
EventNotifier (12 / 0x0c) attribute, whereas data change aim Value (13 /
0x0d) attribute. These of you who are familiar with OPC-UA can see some
similarities due to multiple levels of complexity (object vs its property).
Interesting animal in this zoo is status change which can be used to
receive information about bad signal quality (whatever it means).

Out of these 3 notification kinds data and status change are pretty much
1:1 (node id -> value, node id -> status), so each subscribed tag
returns single value. The metadata concept [2] opens possibility to
return more information to caller, including status.
The event notification however is different, because first and foremost,
we subscribe static node id (not sure if it can change), and do not send
node id but browse path which is just a text:

new SimpleAttributeOperand(nodeId,
   Arrays.asList(new QualifiedName(0, new PascalString >>("EventId")<<)),
   AttributeId.Value.getValue(),
   OpcuaProtocolLogic.NULL_STRING
)

Additionally, there might be filter criteria [3] (I didn't try yet),
which can be used to supply more conditions for receiving data.

Coming to the point - what do you think about defining new tag type for
OPC UA to cover event fields? With this we could use this tag to specify
event fields (browse path), and eventually use tag attributes for criteria:

.addEventTagAddress("EventId;REAL")
.addEventTagAddress("ns=0;i=2253;EventId;REAL") // same as above
.addEventTagAddress("Time;DATETIME")
.addEventTagAddress("Message;STRING{like=Fatal error}")

In above example the default subscribe is assumed to be ns=0;i=2253, but
each event tag address would require a path.

WDYT?

Best,
Łukasz

[1] https://reference.opcfoundation.org/Core/Part4/v104/docs/7.20
[2] https://github.com/apache/plc4x/pull/1725
[3] https://reference.opcfoundation.org/Core/Part4/v104/docs/7.4.4

Re: Apache Kafka integration

[Christofer Dutz]

We didn't remove the adapter from the project. That's still in the extras repo. 
We asked it to be removed from the confluent store, as we were not willing to 
put up with the constraints confluent wanted to pile on us without giving 
anything back.

Chris

Gesendet von Outlook für Android

From: Łukasz Dywicki 
Sent: Friday, August 9, 2024 4:12:27 PM
To: dev@plc4x.apache.org 
Subject: Re: Apache Kafka integration

Hello Kevin,
As far I remember we have removed kafka connect adapter because it
required maintenance which no one was ready to commit.
Can you outline which adapter you would like to configure?
I'd like to mention that there is working component for Apache Camel
which was donated a while ago. You could use it as intermediate way to
seed data from OPC-UA to Kafka broker.

Kind regards,
Łukasz

On 16.07.2024 18:20, Kevin wrote:
> Does anyone have an OPC-UA config file to share for an Apache Kafka source
> connector?
> I looked at the config example file that comes with the PLC4X source code
> under Kafka integrations section, but none of the parameters used seem
> familiar.
>
> I don't need simulated data; I have an IGS OPC-UA server running. I just
> need to look at a real config file.
>
> Thank you everyone!
>

AW: Re: PLC4J, Siemens S7-300 and MPI communication

[Christofer Dutz]

Hi Luiz,

just some time ago someone reported this and I just recently found the 
root-cause of it.
https://github.com/apache/plc4x/issues/1593
Right now, I would simply ignore this message … it shouldn’t influence the 
functionality of the driver itself.

Does it work in general?

Chris


Von: Luiz doleron 
Datum: Freitag, 12. Juli 2024 um 17:09
An: dev@plc4x.apache.org 
Betreff: RE: Re: PLC4J, Siemens S7-300 and MPI communication
Hi Cesar and everyone,

I'm trying to get the ODOT gateway to work with PLC4X, however, I'm getting a 
timeout WARN and the program stuck in the getConnection call.

1 - after plugging the gateway in the S7-300, I followed the instructions 
here and set 
the IP using the NET-LINK app.
2 - The S7-300/ODOT gateway successfully replied to ping
3 - I was able to read data from the PLC using Kepware using S7/ethernet driver

However, when I tried PLC4J, I got a timeout. Any idea what I'm doing wrong?

My test code:


public static void main(String[] args) {

// System.setProperty(SimpleLogger.DEFAULT_LOG_LEVEL_KEY, "Error");

Logger logger = LoggerFactory.getLogger(TestConnection.class);

String connectionString = 
"s7://10.10.26.88?controller-type:S7_300";

PlcConnection plcConnection = null;

try {

plcConnection = PlcDriverManager.getDefault().getConnectionManager()

.getConnection(connectionString);



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

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

return;

}

System.out.println("Success");

} catch (Exception e) {

e.printStackTrace();

} finally {

if (plcConnection != null) {

try {

plcConnection.close();

} catch (Exception e) {

e.printStackTrace();

}

}

}



}

The log:


[main] INFO org.apache.plc4x.java.DefaultPlcDriverManager - Instantiating new 
PLC Driver Manager with class loader 
jdk.internal.loader.ClassLoaders$AppClassLoader@2cdf8d8a

[main] INFO org.apache.plc4x.java.DefaultPlcDriverManager - Registering 
available drivers...

[main] INFO org.apache.plc4x.java.DefaultPlcDriverManager - Registering driver 
for Protocol s7 (Siemens S7 (Basic))

[main] INFO org.apache.plc4x.java.transport.tcp.TcpChannelFactory - Configuring 
Bootstrap with 
org.apache.plc4x.java.s7.readwrite.configuration.S7TcpTransportConfiguration@709ba3fb

[main] INFO org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic - S7 
Driver running in ACTIVE mode.

[main] INFO org.apache.plc4x.java.s7.readwrite.protocol.S7HMuxImpl - 
12:01:12.590558651 userEventTriggered: Multiplexor Event: 
org.apache.plc4x.java.spi.events.ConnectEvent@5542c4ed

[nioEventLoopGroup-2-1] WARN io.netty.channel.embedded.EmbeddedChannel - More 
than one exception was raised. Will report only the first one and log others.

io.netty.handler.codec.DecoderException: 
io.netty.handler.codec.EncoderException: MessageToMessageCodec$1 must produce 
at least one message.

at 
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:98)

at 
io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111)

at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)

at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)

at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)

at 
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)

at 
io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111)

at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)

at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)

at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)

at 
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346)

at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318)

at 
io.netty.handler.codec.ByteToMessageCodec.channelRead(ByteToMessageCodec.java:103)

at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)

at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)

at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)

at io.netty.handler.logging.LoggingHandler.channelRead(LoggingHandler.java:280)

at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)

at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)

at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(Abstrac

AW: AW: [D] How to seed community engagement?

[Christofer Dutz]

Hi all,

I do agree that with PLC4PY we could reach a younger audience. One that would 
be more inclined to try something new.

The problem I see, is that these folks don’t have access to the production 
machinery, because the gatekeepers to the shopfloor systems are old-school 
automation engineers.

When I started PLC4X I first concentrated on IT … making it easy for software 
engineers to write software for industrial automation sector. I talked on IT 
conferences, published in IT magazines and Blogs. And people were really 
digging into it.

Unfortunately, I learned way too late, that I was targeting the wrong audience. 
While I got the IT folks on board really easy (compared to the others). Most of 
them stopped digging deeper when they noticed that they need industrial 
Hardware for actually doing something sensible with it. And when talking to the 
people with the hardware, we usually got disqualified by the Automation 
gatekeepers asking stuff like:


  *   Are you ZYZ certified?
  *   What’s your 24/7 on premise support offering worldwide?

That’s why at least for the first question I came up with the concept of 
passive-mode drivers. For the second I usually replied: “we don’t have one”.

I think the main problem of PLC4X is that the access to the equipment is 
guarded by hordes of old-school automation dinosaurs. And I doubt Python 
support will change anything here :-(

But hey … prove me wrong … and if I can help you, I’ll do what I can to do so.

But as you mention it:
"Economics is the study of how we choose to use limited resources to obtain the 
maximum satisfaction of unlimited human wants" … I have limited time available, 
if I want to have a life and I personally have found out that working with wood 
in my shed brings more satisfaction for myself compared to wearing me out for 
an industry that doesn’t seem to want me to do anything.

Chris


Von: Cesar Garcia 
Datum: Sonntag, 7. Juli 2024 um 22:14
An: dev@plc4x.apache.org 
Betreff: Re: AW: [D] How to seed community engagement?
Hello Luis,

Indeed, in the world of automation there is a lot of use and custom, and a
lot of resistance to change, which is generally created by big brands.

As you point out, within the group we share the vision that we should
introduce PLC4X in universities and bet on the future.

Some of us are working precisely so that the learning curve of PLC4X does
not hinder its adoption, bringing it closer to commercial components.

Kind regards,

El dom, 7 jul 2024 a las 14:15, Luiz doleron () escribió:

> Hi, Chris!
>
> I have more than 20 years in the TIC industry and Python is not my
> preferred language for real-world projects or even for hobby projects.
>
> My particular technical opinion about Python is that this language is an
> engineering mistake (pythonists, no offense intended).
>
> However, I use Python always when it is required to use Python.
>
> Said that,
>
> "Admittedly this doesn’t seem to have worked or we simply don’t know it."
>
> My suggestion is to rethink the strategy:
>
> So far, PLC4X focused on the old guys in the automation industry. This
> previous experience showed that these guys are (usually) less prone to
> changes.
> They use the same tools for years long and probably most of them are not
> inclined to spend energy or take risks to embrace new ways or tools.
>
> My suggestion is to focus on the enormous volume of engineering students
> playing educational/researching projects.
>
> - Tutorials showing how to use PLC4X to communicate with PLC Simulators
> - Easy support for Python and Java
> - Prebuilt packages like pip and maven
> - Simple runnable examples, lots of
> - Mix market: YouTube, StackOverflow, Medium, etc
>
> My feeling is that, in a second moment, this new public can form the
> critical mass to drive PLC4X for a more shopfloor-oriented, industrial
> scenario moving the proprietary alternatives to obsolescence.
>
> I would like to highlight that I am not criticizing PLC4X here. Quite the
> opposite. IMO PLC4X can play a game-changing.
>
> From the schoolbook:
>
> "Economics is the study of how we choose to use limited resources to obtain
> the maximum satisfaction of unlimited human wants"
>
> Thus, this is not about Python or Java or specifically code. My
> understanding about the code is that PLC4X as is (i.e., keeping netty) can
> rapidly take the scene control.
>
> Sorry if I'm stretching this talk for too long. I only would like to tell
> what I can see from an external perspective.
>
> Best regards,
>
> --
> Luiz Carlos d´Oleron
>


--
*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
*

AW: [D] How to seed community engagement?

[Christofer Dutz]

Hi Luiz,

well initially the main goal was to allow the OT-folks in the automation sector 
to start using PLC4X to get their data into open-source solutions instead of 
their proprietary solutions. So we decided to start with languages that have 
the biggest support for doing this and this is why probably Java is the best 
supported language.

Admittedly this doesn’t seem to have worked or we simply don’t know it. Yes … 
recently Python has been seeing quite a large adoption, but mainly not from the 
side of the Automation Industry. It’s mainly for people “playing around with 
things” (From my perspective … might be wrong though). My gut-feeling is 
telling me that getting Python onto the shopfloor is going to be a tough fight.

I fully agree that better Python support will be better for the project as more 
people working on the project will bring more insights, better drivers in 
total. After all … knowledge gained in one protocol is easily transferrable to 
another PLC4X language.

Chris


Von: ottlukas (via GitHub) 
Datum: Sonntag, 7. Juli 2024 um 09:00
An: dev@plc4x.apache.org 
Betreff: Re: [D] How to seed community engagement?

GitHub user ottlukas edited a comment on the discussion: How to seed community 
engagement?

First of all welcome to the PLC4X community.

We as a community are aware since at least 2020 to your point: 1 and 2. -> here 
you find the dicussions on confluence: [Python 
Development](https://cwiki.apache.org/confluence/display/PLC4X/Python+-+Developer+Wiki)

We have indeed already a pip account.

The challenge like in many communities is where to focus on. As our Java 
implementation is the most stable and most advanved one we have focused on that 
stack especially for the integration with the larger ASF Big Data and 
Integration projects such as Apache Kafka, Apache Nifi and Apache Camel. As 
this is already a huge advantage to have integrations into these ecosystems / 
projects.

For PLC4Py we hope to find some developers willing to invest some time to 
implement the S7 protocol (@vemmert :-P )and indeed publish on pip instead of 
having to do `pip install .` [PLC4Py Getting 
Started](https://plc4x.apache.org/users/getting-started/plc4py.html)

The longterm plans for the Java implementation to get rid of netty is a vision 
/ dream of the community but due to lack of resources (no money, no developers 
having free capacity) some warning messages are existing.

Again welcome highly appriciated your feedback and contribution to the 
disussion and I hope that this helps you and others to get some more 
transparency whats going on and what has been disccussed to your points.

GitHub link: 
https://github.com/apache/plc4x/discussions/1024#discussioncomment-9978040


This is an automatically sent email for dev@plc4x.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@plc4x.apache.org

Added a maxIdleTime to the CachedPlcConnectionManager

[Christofer Dutz]

Hi all,

also was pointed out to me by the Streampipes project, that once a connection 
is established with the connection cache, there is no way to make this expire.
As the cache didn’t have any form of connection expiry of stale connections, I 
took the liberty to add this.

It defaults to 5 minutes. So, if a connection is not used for 5 minutes, the 
connection is closed.

Chris

AW: Making the Connection Cache closable?

[Christofer Dutz]

Hi,

I was also thinking, if it would make sense to make the normal 
PlcConnectionManager (which was already pointed out is more of a 
PlcConnectionFactory, as it doesn’t manage the connection after being created)
more a “manager”. So, it should keep references to the connections it created 
and be able to close them by closing the PlcConnectionManager instance.

Chris

Von: Lukas Ott 
Datum: Freitag, 5. Juli 2024 um 09:13
An: dev@plc4x.apache.org 
Betreff: Re: Making the Connection Cache closable?
+1 that is really a useful and needed feature.

Am Fr., 5. Juli 2024 um 09:11 Uhr schrieb Christofer Dutz <
christofer.d...@c-ware.de>:

> Hi all,
>
> I recently had a discussion with our friends from StreamPipes and they
> were having problems that they couldn’t force closing of a connection in
> the connection-pool.
> The use case they described was that the configuration of the connection
> was changed, but the old connection stayed alive.
>
> I proposed adding a close() method to the connection-cache that shuts down
> the connection cache and all connections it currently manages.
>
> If nobody objects within the next few hours, this is what I’ll be working
> on this week’s PLC4X-Friday-Afternoon.
>
> Chris
>

Making the Connection Cache closable?

[Christofer Dutz]

Hi all,

I recently had a discussion with our friends from StreamPipes and they were 
having problems that they couldn’t force closing of a connection in the 
connection-pool.
The use case they described was that the configuration of the connection was 
changed, but the old connection stayed alive.

I proposed adding a close() method to the connection-cache that shuts down the 
connection cache and all connections it currently manages.

If nobody objects within the next few hours, this is what I’ll be working on 
this week’s PLC4X-Friday-Afternoon.

Chris

AW: Labels, labels everywhere

[Christofer Dutz]

I agree.

Chris

Von: Lukas Ott 
Datum: Freitag, 5. Juli 2024 um 08:49
An: dev@plc4x.apache.org 
Betreff: Re: Labels, labels everywhere
We currently have 63 labels:
https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels

instead of keeping plc4X which is internally understood I would keep the
language label and the name of the protocol.

What do you think?

My suggestion would be the following:
ADS -> keep
API -> keep
beginner -> keep
BLOCKER-> keep
bug-> keep
build-> keep
c-> keep
CANopen-> keep
code-Generation-> keep
core -> delete
CRITICAL -> keep
dependencies-> keep
docker-> keep
documentation-> keep
documentation-update -> delete
driver-ads -> delete
driver-modbus-> delete
driver-opc-ua-> delete
driver-profinet-> delete
driver-s7-> delete
duplicate -> keep
easy-fix-> delete
enhancement-> delete
Ethernet/IP -> keep
examples-> delete
Fatek -> keep
feature -> keep
feature-request -> delete
github_actions -> keep
go -> keep
good first issue -> keep
help wanted -> keep
improvement -> delete
integration-camel -> keep
integration-kafka-connect -> keep
integration-nifi -> keep
invalid-> delete
java -> keep
low-hanging-fruit -> delete
MAJOR -> keep
MINOR -> keep
Modbus -> keep
new feature -> delete
newbie -> delete
OPC-UA -> keep
pending-close -> delete
plc4c -> delete
plc4j -> delete
Profinet -> keep
python -> keep
Question -> delete
scraper -> delete
Task -> delete
test-> delete
testing-> delete
TRIVIAL-> delete
util-pool-> delete
wish-> delete
wontfix-> delete


Regards
Lukas

Am Fr., 5. Juli 2024 um 08:24 Uhr schrieb Christofer Dutz <
christofer.d...@c-ware.de>:

> I also noticed that as each issue lists up all the names, it's hard to
> search for "Modbus" for example.
>
> Chris
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> 
> From: Łukasz Dywicki 
> Sent: Friday, July 5, 2024 12:53:13 AM
> To: dev@plc4x.apache.org 
> Subject: Labels, labels everywhere
>
> I've noticed that we have plenty of labels in github, which do overlap.
>
> For example:
> Java, plc4j
> OPC-UA, driver-opc-ua
> ADS, driver-ads
>
> There are many more which probably come from JIRA import.
> Can we clarify which we intend to use and re-assign elements/reduce
> their number?
>
> Best,
> Łukasz
>

Re: Labels, labels everywhere

[Christofer Dutz]

I also noticed that as each issue lists up all the names, it's hard to search 
for "Modbus" for example.

Chris

Gesendet von Outlook für Android

From: Łukasz Dywicki 
Sent: Friday, July 5, 2024 12:53:13 AM
To: dev@plc4x.apache.org 
Subject: Labels, labels everywhere

I've noticed that we have plenty of labels in github, which do overlap.

For example:
Java, plc4j
OPC-UA, driver-opc-ua
ADS, driver-ads

There are many more which probably come from JIRA import.
Can we clarify which we intend to use and re-assign elements/reduce
their number?

Best,
Łukasz

AW: AW: [DISCUSS] Metadata for responses / source time

[Christofer Dutz]

Hi Lukasz,

Having the timestamps in a completely separate API separated from the normal 
read-requests or subscriptions?
I think I’m not quite understanding you.

You could whip up a PR where you simply change the interfaces (doesn’t have to 
compile) … guess dissussing it there makes more sense.

Chris


Von: Łukasz Dywicki 
Datum: Mittwoch, 3. Juli 2024 um 14:59
An: dev@plc4x.apache.org 
Betreff: Re: AW: [DISCUSS] Metadata for responses / source time
Hey Chris,
I propose to introduce new part in API used for read/write/subscribe
responses (or events). It is not discovery, its runtime information.

You are right that usually timestamp is set for entire message. This is
the case for CAN transport. However once we start playing with
aggregation (optimizers/decorators) it is not a case any more. I think
that in case of OPC UA server we can get different timestamps for every
field (scalar value), as their sample time can be different.

Best,
Łukasz

On 3.07.2024 07:58, Christofer Dutz wrote:
> Thinking more about it, I do think that this makes more sense for protocols 
> such as KNX, where there’s loads of metadata alongside the actual values.
> Currently we simply return a PLCStruct for that case, but having attributes 
> would be nicer as one could concentrate on the actual “value”.
> I know in general a “per-value” timestamp is rather seldom under the 
> industrial protocols as usually it’s on a per-message basis.
>
> However, we sometimes break up large requests into multiple ones. So, we 
> technically don’t have a timestamp per request but per-group of values.
> Because of this I would argue, that only a per-value is really reliable.
>
> Chris
>
>
> Von: Christofer Dutz 
> Datum: Mittwoch, 3. Juli 2024 um 07:03
> An: dev@plc4x.apache.org 
> Betreff: Re: [DISCUSS] Metadata for responses / source time
> You propose something like the "attributes" on discovery items, where its 
> generally a map of plc values added? Or something more integrated into the 
> api?
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> 
> From: Łukasz Dywicki 
> Sent: Tuesday, July 2, 2024 11:06:13 PM
> To: dev@plc4x.apache.org 
> Subject: [DISCUSS] Metadata for responses / source time
>
> Dear PLC4X followers,
> I would like to bring back 3 year old discussion we had on stuff related
> to "source time", but not only:
> https://lists.apache.org/thread/r3g4y6p7kst7z5bdpmccd8538h3hl80f
> The "metadata" term was coined by Ben, kudos for him! :)
>
> For these who missed earlier topic - it was an inquiry of how to acquire
> source time for plc values returned by our API. Because this kind of
> features is not always present in protocols at the time it was brought,
> it was heavily influenced by OPC-UA. For OPC-UA it comes from
> application layer, thus we can (relatively easily) propagate it from
> driver to our API callers.
> Over time we got another case. We have a transport which can do similar
> - CAN, if used with socketcan, can provide message level metadata. The
> most common metadata there is hardware or software level timestamp of
> message. First comes from microcontroller which deals with CAN
> transceiver, second one is (AFAIK) assumed at driver level.
>
> Reason why I bring this topic back is plain - we miss API for "source
> time", and I would like to bring implement it. I know this idea got
> stuck before because of driver level differences and multiple languages.
>
> To be clear - I intend to bring this only for java, because this is
> where we have functioning OPC-UA and CAN drivers. Other languages, as
> far I know, do not have these, hence benefit of new API there is
> non-existent.
> This topic was partially touched when we meet in Frankfurt to discuss
> 1.0 and expected/speculated API changes we are aware of. Given that we
> are still before 1.0 release, and new features interesting for 1.0 (i.e.
> subscription emulation) might benefit from it I would personally
> prioritize this work over other.
>
> Given that we might have metadata for two levels - entire response as
> well as individual field/event I wish to provide metadata API for both.
> Primary objective for both places is making it possible to enumerate all
> available metadata keys (if any), or lookup by predefined key (i.e.
> timestamp), as well as let drivers easily define their own metadata keys.
>
> Let me know if you have any notes, intent or suggestions for this API.
>
> Cheers,
> Łukasz
>

AW: Guess I had an upsie ...

[Christofer Dutz]

So, I added this to the GeneratedDriverBase:

protected boolean canDiscover() {
return false;
}

And overrode that in Ads and Profinet, as the existing UI only showed me a 
“Discovery” option for these two drivers.

Chris

Von: Christofer Dutz 
Datum: Mittwoch, 3. Juli 2024 um 08:32
An: dev@plc4x.apache.org 
Betreff: Guess I had an upsie ...
Hi all,

While playing around with the UI tool I noticed that the PlcDriver didn’t have 
any “hasDiscovery” method, but still the existing UI seems to know if a driver 
supports Auto-Discovery.
Turns out in GeneratedDriverBase I have this code:

public boolean isDiscoverySupported() {
return canBrowse();
}

Which obviously doesn’t look right … I guess it makes sense to add a 
“hasDiscovery” method to the driver base and to use that instead.

Chris

Guess I had an upsie ...

[Christofer Dutz]

Hi all,

While playing around with the UI tool I noticed that the PlcDriver didn’t have 
any “hasDiscovery” method, but still the existing UI seems to know if a driver 
supports Auto-Discovery.
Turns out in GeneratedDriverBase I have this code:

public boolean isDiscoverySupported() {
return canBrowse();
}

Which obviously doesn’t look right … I guess it makes sense to add a 
“hasDiscovery” method to the driver base and to use that instead.

Chris

AW: [DISCUSS] Metadata for responses / source time

[Christofer Dutz]

Thinking more about it, I do think that this makes more sense for protocols 
such as KNX, where there’s loads of metadata alongside the actual values.
Currently we simply return a PLCStruct for that case, but having attributes 
would be nicer as one could concentrate on the actual “value”.
I know in general a “per-value” timestamp is rather seldom under the industrial 
protocols as usually it’s on a per-message basis.

However, we sometimes break up large requests into multiple ones. So, we 
technically don’t have a timestamp per request but per-group of values.
Because of this I would argue, that only a per-value is really reliable.

Chris


Von: Christofer Dutz 
Datum: Mittwoch, 3. Juli 2024 um 07:03
An: dev@plc4x.apache.org 
Betreff: Re: [DISCUSS] Metadata for responses / source time
You propose something like the "attributes" on discovery items, where its 
generally a map of plc values added? Or something more integrated into the api?

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: Łukasz Dywicki 
Sent: Tuesday, July 2, 2024 11:06:13 PM
To: dev@plc4x.apache.org 
Subject: [DISCUSS] Metadata for responses / source time

Dear PLC4X followers,
I would like to bring back 3 year old discussion we had on stuff related
to "source time", but not only:
https://lists.apache.org/thread/r3g4y6p7kst7z5bdpmccd8538h3hl80f
The "metadata" term was coined by Ben, kudos for him! :)

For these who missed earlier topic - it was an inquiry of how to acquire
source time for plc values returned by our API. Because this kind of
features is not always present in protocols at the time it was brought,
it was heavily influenced by OPC-UA. For OPC-UA it comes from
application layer, thus we can (relatively easily) propagate it from
driver to our API callers.
Over time we got another case. We have a transport which can do similar
- CAN, if used with socketcan, can provide message level metadata. The
most common metadata there is hardware or software level timestamp of
message. First comes from microcontroller which deals with CAN
transceiver, second one is (AFAIK) assumed at driver level.

Reason why I bring this topic back is plain - we miss API for "source
time", and I would like to bring implement it. I know this idea got
stuck before because of driver level differences and multiple languages.

To be clear - I intend to bring this only for java, because this is
where we have functioning OPC-UA and CAN drivers. Other languages, as
far I know, do not have these, hence benefit of new API there is
non-existent.
This topic was partially touched when we meet in Frankfurt to discuss
1.0 and expected/speculated API changes we are aware of. Given that we
are still before 1.0 release, and new features interesting for 1.0 (i.e.
subscription emulation) might benefit from it I would personally
prioritize this work over other.

Given that we might have metadata for two levels - entire response as
well as individual field/event I wish to provide metadata API for both.
Primary objective for both places is making it possible to enumerate all
available metadata keys (if any), or lookup by predefined key (i.e.
timestamp), as well as let drivers easily define their own metadata keys.

Let me know if you have any notes, intent or suggestions for this API.

Cheers,
Łukasz

Re: [DISCUSS] Metadata for responses / source time

[Christofer Dutz]

You propose something like the "attributes" on discovery items, where its 
generally a map of plc values added? Or something more integrated into the api?

Gesendet von Outlook für Android

From: Łukasz Dywicki 
Sent: Tuesday, July 2, 2024 11:06:13 PM
To: dev@plc4x.apache.org 
Subject: [DISCUSS] Metadata for responses / source time

Dear PLC4X followers,
I would like to bring back 3 year old discussion we had on stuff related
to "source time", but not only:
https://lists.apache.org/thread/r3g4y6p7kst7z5bdpmccd8538h3hl80f
The "metadata" term was coined by Ben, kudos for him! :)

For these who missed earlier topic - it was an inquiry of how to acquire
source time for plc values returned by our API. Because this kind of
features is not always present in protocols at the time it was brought,
it was heavily influenced by OPC-UA. For OPC-UA it comes from
application layer, thus we can (relatively easily) propagate it from
driver to our API callers.
Over time we got another case. We have a transport which can do similar
- CAN, if used with socketcan, can provide message level metadata. The
most common metadata there is hardware or software level timestamp of
message. First comes from microcontroller which deals with CAN
transceiver, second one is (AFAIK) assumed at driver level.

Reason why I bring this topic back is plain - we miss API for "source
time", and I would like to bring implement it. I know this idea got
stuck before because of driver level differences and multiple languages.

To be clear - I intend to bring this only for java, because this is
where we have functioning OPC-UA and CAN drivers. Other languages, as
far I know, do not have these, hence benefit of new API there is
non-existent.
This topic was partially touched when we meet in Frankfurt to discuss
1.0 and expected/speculated API changes we are aware of. Given that we
are still before 1.0 release, and new features interesting for 1.0 (i.e.
subscription emulation) might benefit from it I would personally
prioritize this work over other.

Given that we might have metadata for two levels - entire response as
well as individual field/event I wish to provide metadata API for both.
Primary objective for both places is making it possible to enumerate all
available metadata keys (if any), or lookup by predefined key (i.e.
timestamp), as well as let drivers easily define their own metadata keys.

Let me know if you have any notes, intent or suggestions for this API.

Cheers,
Łukasz

Improved Modbus Byte-Order handling

[Christofer Dutz]

Hi all,

today I implemented support for some quite odd encodings:
LITTLE_ENDIAN_BYTE_SWAP and BIG_ENDIAN_BYTE_SWAP.
Also did I add support for custom overriding of the connections default 
byte-order in Modbus on a per tag basis.

//final PlcConnection connection = new 
DefaultPlcDriverManager().getConnection("modbus-tcp://10.211.55.3?default-payload-byte-order=BIG_ENDIAN");
final PlcConnection connection = new 
DefaultPlcDriverManager().getConnection("modbus-tcp://10.211.55.3?default-payload-byte-order=LITTLE_ENDIAN");
//final PlcConnection connection = new 
DefaultPlcDriverManager().getConnection("modbus-tcp://10.211.55.3?default-payload-byte-order=BIG_ENDIAN_BYTE_SWAP");
//final PlcConnection connection = new 
DefaultPlcDriverManager().getConnection("modbus-tcp://10.211.55.3?default-payload-byte-order=LITTLE_ENDIAN_BYTE_SWAP");
final PlcReadRequest readRequest = connection.readRequestBuilder()
.addTagAddress("16 bit BigEndian", 
"holding-register:1:WORD{byte-order:'BIG_ENDIAN'}")
.addTagAddress("16 bit LittleEndian", 
"holding-register:2:WORD{byte-order:'LITTLE_ENDIAN'}")
.addTagAddress("32 bit BigEndian", 
"holding-register:3:DWORD{byte-order:'BIG_ENDIAN'}")
.addTagAddress("32 bit LittleEndian", 
"holding-register:5:DWORD{byte-order:'LITTLE_ENDIAN'}")
.addTagAddress("32 bit BigEndianByteSwap", 
"holding-register:7:DWORD{byte-order:'BIG_ENDIAN_BYTE_SWAP'}")
.addTagAddress("32 bit LittleEndianByteSwap", 
"holding-register:9:DWORD{byte-order:'LITTLE_ENDIAN_BYTE_SWAP'}")
.addTagAddress("64 bit BigEndian", 
"holding-register:11:LWORD{byte-order:'BIG_ENDIAN'}")
.addTagAddress("64 bit LittleEndian", 
"holding-register:15:LWORD{byte-order:'LITTLE_ENDIAN'}")
.addTagAddress("64 bit BigEndianByteSwap", 
"holding-register:19:LWORD{byte-order:'BIG_ENDIAN_BYTE_SWAP'}")
.addTagAddress("64 bit LittleEndianByteSwap", 
"holding-register:23:LWORD{byte-order:'LITTLE_ENDIAN_BYTE_SWAP'}")
.build();


Chris

AW: Issues caused by the Endianness PR

[Christofer Dutz]

So,

I’ve started reverting the PR and moving the WORD-SWAP code into the Modbus 
protocol, as this is the only place I have ever seen it be needed.
Problem is, that the byte-reordering works with 16, 32, 64 bit, but is a 
nightmare with any of the partial … especially ADS makes heavy use of uint 32 
Little Endian …
Simply adding the byte-shift at the end for Little endian did make things work 
again, but even starting to think about how this would work for 
Little-Endian-Word-Swap was something I was not willing to investigate ;-)

Chris

Von: Christofer Dutz 
Datum: Freitag, 14. Juni 2024 um 16:41
An: dev@plc4x.apache.org 
Betreff: Issues caused by the Endianness PR
Hi all,

I thought it would be simpler for me to merge the PR and then add the missing 
Apache Header … turns out that the PR has serious side-effects on other 
protocols.
Generally when haing 32 unsigned types in mspec, now everything is missed up … 
I’m working on it.

Chris

Issues caused by the Endianness PR

[Christofer Dutz]

Hi all,

I thought it would be simpler for me to merge the PR and then add the missing 
Apache Header … turns out that the PR has serious side-effects on other 
protocols.
Generally when haing 32 unsigned types in mspec, now everything is missed up … 
I’m working on it.

Chris

Re: [DRAFT] Board Report

[Christofer Dutz]

Yeah.

Thanks for writing this.
I'm done with you posting it.
Considering the more than 80% drop in commits, the board will ask about if we 
can name a reason for that.
Feel free to mention that I decided to stop working on the project in my free 
time.

Chris

Gesendet von Outlook für Android

From: Lukas Ott 
Sent: Tuesday, June 4, 2024 8:35:55 AM
To: dev@plc4x.apache.org 
Subject: Re: [DRAFT] Board Report

+1


Looks good to me.

Thank you for writing the Report :-)

Cesar Garcia  schrieb am Di., 4. Juni 2024, 05:54:

> As they are?
>
> Annex you will find a draft to report to the commission.
> I'm following the macro activities, in the development list and in Slack,
> but if you consider a point of observation it is welcome.
>
> In this report I think it is important to highlight the meeting held by the
> work team in Frankfurt since it establishes the line of work that aims to
> reach 1.0.0 this year.
>
> Waiting for your comments,
>
> Thanks for your support
>
>
> *## 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.
>
> *## Project Status:*
>
>- Current project status: Ongoing with moderate activity
>- Issues for the board: None
>
>
> *## Membership Data:*
>
>- Apache PLC4X was founded 2019-04-16 (5 years ago) There are currently
>21 committers and 13 PMC members in this project.
>- The Committer-to-PMC ratio is roughly 3:2.
>
>
> *Community changes, past quarter:*
>
>- No new PMC members. Last addition was César García on 2021-09-30.
>- No new committers. Last addition was Jinlin Hong on 2022-11-02.
>
>
> *## Project Activity:*
>
>- Version 0.12.0 was released on 2024-02-19
>- On 03/23/2024 the team held a work meeting in Franfurk with the
>purpose of defining the work path towards version 1.0.0, the main focus
>being the implementation of the management of the real or emulated
>subscription concept as applicable for the specific device.
>- The "plc4x" prepository was separated between "plc4x" (core) and
>"plc4x-extras", the latter containing the examples and integration
> projects
>with other Apache projects.
>- The support of libraries with python "plc4xpy" was moved to top level,
>its incorporation to The Python Package Index is being planned.
>
>
>
> *## Community Health:*
> There has been no invitation to a new committer for a while.
> The user base based on statistical reports (individuals and other
> institutions) is increasing.
> Although the level of commits has decreased in this period, the community
> is working on the objectives established for version 1.0.0.
>
>- dev@plc4x.apache.org had a 29% decrease in traffic in the past
> quarter
>(437 emails compared to 608)
>- iss...@plc4x.apache.org had a 67% increase in traffic in the past
>quarter (248 emails compared to 148)
>- 61 commits in the past quarter (-83% decrease)
>- 7 code contributors in the past quarter (-53% change)
>
>
> --
> *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
> *
>

AW: ADS

[Christofer Dutz]

Hi Björn,

nothing would make me happier than if you did find some time and could help out 
a little bit ;-)

Chris


Von: bjo...@b-have.de 
Datum: Donnerstag, 30. Mai 2024 um 12:17
An: dev@plc4x.apache.org 
Betreff: AW: ADS
Hi Chris,

I'm taking a look into the driver at this very moment.

No worries, it is the same here... so much to do with only so little time...
I think I'm good with the things how they are for the time being, and if not, 
I'll see if I can put the things together.
I'm keen to work on this project. Maybe I can find the time after my current 
obligations are satisfied.

Best regards

Björn



-
Bjoern Haverland
Tel.: +49 171 7535 889
Mail: bjo...@b-have.de

-Ursprüngliche Nachricht-----
Von: Christofer Dutz 
Gesendet: Donnerstag, 30. Mai 2024 12:04
An: dev@plc4x.apache.org
Betreff: Re: ADS

Hi Bjöern,

That was how the old driver worked. I always had planned to re-implement an 
ad-hoc address resolution, but never found the time 😕

All parts needed should be there to add that, but someone would still need to 
implement that.

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> 

From: bjo...@b-have.de 
Sent: Thursday, May 30, 2024 11:56:24 AM
To: dev@plc4x.apache.org 
Subject: AW: ADS

Hi Łukasz,

Thanks for your reply.

It is Twincat 3 for me.
I was able to get a connection for reading and browsing the PLC.

One of my problems have been related in the load-symbol-and-data-type-tables 
option. I had set it to false. I thought the driver would discover the symbolic 
addresses on a per variable bases while querying it, but it doesn't.
As soon as I set the options to true I can browse the variables.

Best regards,


Björn





-
Bjoern Haverland
Tel.: +49 171 7535 889
Mail: bjo...@b-have.de

-Ursprüngliche Nachricht-
Von: Łukasz Dywicki 
Gesendet: Mittwoch, 29. Mai 2024 16:13
An: dev@plc4x.apache.org
Betreff: Re: ADS

Hello Björn,
Symbolic variable names depend on twincat version.

For twincat 2.x you can use . syntax, for 3.x you use 
..
Given your example, for TC2 symbolic address on plc4x side will be .GVL and 
.GVL_TEST. For fresh twincats it will be Main.GVL and Main.GVL_Test (assuming 
you have such task in your PLC project).

Best,
Łukasz

On 24.05.2024 15:34, bjo...@coding-nexus.com wrote:
> Hi,
>
>
>
> Is someone able to provide me a small code example on how to query ADS
> variable?
>
>
>
> Say  I have a GVL called GVL_TEST how could I browse it or even read
> GVL_TEST.test which would be a String(10).
>
>
>
> My attempts to read it like I do read a Variable at the S7 are leading
> to null…
>
>
>
> Thank you very much!
>
>
>
> Best regards and happy weekend
>
>
>
> Björn
>
>
>
> -
>
> Coding Nexus LLC
>
> Björn Haverland
>
> 2880W Oakland Park Blvd
>
> Suite 225C
>
> Oakland Park
>
> 33311 Florida
>
>
>
> Tel: +1 954 607 2347
>
>
>
>   <mailto:bjo...@coding-nexus.com> bjo...@coding-nexus.com
>
>   <https://www.coding-nexus.com/> https://www.coding-nexus.com
>
>
>
>
>
>

Re: ADS

[Christofer Dutz]

Hi Bjöern,

That was how the old driver worked. I always had planned to re-implement an 
ad-hoc address resolution, but never found the time 😕

All parts needed should be there to add that, but someone would still need to 
implement that.

Chris

Gesendet von Outlook für Android

From: bjo...@b-have.de 
Sent: Thursday, May 30, 2024 11:56:24 AM
To: dev@plc4x.apache.org 
Subject: AW: ADS

Hi Łukasz,

Thanks for your reply.

It is Twincat 3 for me.
I was able to get a connection for reading and browsing the PLC.

One of my problems have been related in the load-symbol-and-data-type-tables 
option. I had set it to false. I thought the driver would discover the symbolic 
addresses on a per variable bases while querying it, but it doesn't.
As soon as I set the options to true I can browse the variables.

Best regards,


Björn





-
Bjoern Haverland
Tel.: +49 171 7535 889
Mail: bjo...@b-have.de

-Ursprüngliche Nachricht-
Von: Łukasz Dywicki 
Gesendet: Mittwoch, 29. Mai 2024 16:13
An: dev@plc4x.apache.org
Betreff: Re: ADS

Hello Björn,
Symbolic variable names depend on twincat version.

For twincat 2.x you can use . syntax, for 3.x you use 
..
Given your example, for TC2 symbolic address on plc4x side will be .GVL and 
.GVL_TEST. For fresh twincats it will be Main.GVL and Main.GVL_Test (assuming 
you have such task in your PLC project).

Best,
Łukasz

On 24.05.2024 15:34, bjo...@coding-nexus.com wrote:
> Hi,
>
>
>
> Is someone able to provide me a small code example on how to query ADS
> variable?
>
>
>
> Say  I have a GVL called GVL_TEST how could I browse it or even read
> GVL_TEST.test which would be a String(10).
>
>
>
> My attempts to read it like I do read a Variable at the S7 are leading
> to null…
>
>
>
> Thank you very much!
>
>
>
> Best regards and happy weekend
>
>
>
> Björn
>
>
>
> -
>
> Coding Nexus LLC
>
> Björn Haverland
>
> 2880W Oakland Park Blvd
>
> Suite 225C
>
> Oakland Park
>
> 33311 Florida
>
>
>
> Tel: +1 954 607 2347
>
>
>
>    bjo...@coding-nexus.com
>
>    https://www.coding-nexus.com
>
>
>
>
>
>

AW: [DISCUSS] Remove the Var-Arg Object methods and replace them with PlcValues?

[Christofer Dutz]

Actually …

The more I think of it, possibly letting go of var-args in total might also be 
a good Idea.

Right now, someone could put in one PlcList of values or multiple PlcValues … 
but what if he puts in multiple PlcList?
If we simply say in a Write operation for one tag you put in one PlcValue … if 
you want to write an array, put in a PlcList.

Chris


Von: Christofer Dutz 
Datum: Freitag, 17. Mai 2024 um 15:51
An: dev@plc4x.apache.org 
Betreff: [DISCUSS] Remove the Var-Arg Object methods and replace them with 
PlcValues?
Hi all,

I know we staeted with accepting Object… vararg arguments in the early days of 
PLC4X but due to many issues coming from not guessing the right types, most 
drivers now expec PlcValues as arguments.
However, we still have parts of the API that use Object…

I propose to clean this up and replace it with “PlcValue…” var-args so we 
finally find the missing places where we’re not handling things correctly.

What do you folks think?

Chris

[DISCUSS] Remove the Var-Arg Object methods and replace them with PlcValues?

[Christofer Dutz]

Hi all,

I know we staeted with accepting Object… vararg arguments in the early days of 
PLC4X but due to many issues coming from not guessing the right types, most 
drivers now expec PlcValues as arguments.
However, we still have parts of the API that use Object…

I propose to clean this up and replace it with “PlcValue…” var-args so we 
finally find the missing places where we’re not handling things correctly.

What do you folks think?

Chris

Re: PLC4X support

[Christofer Dutz]

I Chen,

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

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

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

Chris

Gesendet von Outlook für Android

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


Hi,





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

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



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



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



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



Is that possible PLC4x support such application?



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



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



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



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

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





Shuyi Chen
AMR RCOE - Senior Operation Manager
Dematic Global Robotics


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

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

Remove the UI from the plc4x-extras repo?

[Christofer Dutz]

Hi all,

So, it seems in the Node world you need to keep updating dependencies as older 
versions seem to be removed.

Unfortunately, I’m a total opponent of using the normal “latest” concept people 
in the node world seem to be using. Therefore, someone needs to constantly 
update the node dependencies. I’m not going to be doing that. So, for now, I’ll 
disable the UI in the extras build, but I think we should either work on the UI 
or delete it.

Chris

Some help for people having trouble with PLC4C on Mac systems with the latest OS update

[Christofer Dutz]

Hi all,

so I was having a bit of a problem with PLC4Go and PLC4C after updating to the 
latest OS version on my Mac.
I think I managed to solve the issues with Go by updating all tools used in the 
build to the latest versions (on my feature branch for moving the examples and 
integration to the extras repo)

With PLC4C I had the strange problem, that CLion was reporting loads of 
problems (mainly related to not finding include files)

Turns out that CLion was reporting that the toolchain has changed in the little 
bell icon on the side.

Hitting the recommended “reset” button fixed at least the false positive 
problems …

Just thought I’d leave this info here as it was causing quite a bit of trouble 
for me.

Chris

Splitting up the repos

[Christofer Dutz]

Hi all,

so for the last days I have tried splitting up the repos while containing the 
history.
Seems there are issues with that as the process keeps on crashing on one or two 
commits.

Now the question … I could do a very time-consuming process of plitting out 
each module into a separate branch and merging them back together.

Or I simply copy stuff to the new repo and live with the fact that the commit 
history is still in the old main repo.

Keeping the history will probably take a while for me to finish.

Chirs

AW: opcua

[Christofer Dutz]

Hi Lukasz,

Actually, I tried that … if you use the opcua:tcp:// version, the error still 
refers to “opc.tcp” … I first thought the same, but when I tried it, I could 
confirm.
Unfortunately, I have no idea how OPC-UA works and I’m not planning on changing 
that any time soon ;-)

Chris

Von: Łukasz Dywicki 
Datum: Dienstag, 2. April 2024 um 13:43
An: dev@plc4x.apache.org , Alexis KHOURY 

Betreff: Re: opcua
Hello Alexis,
Welcome on mailing list, and thank you for interest in PLC4X! Sorry for
delayed answer, you found me (us?) during Easter break.

In terms of URI - the protocol prefix you use is "opc" flavor. Due to
internal library architecture we do not follow OPC specs for connection
string, at least in this part.
Please have a try with "opcua:tcp://...", it should work. Also note that
http transport/xml encoding is unsupported. We cover only binary marshaling.

Kind regards,
Łukasz

On 31.03.2024 22:15, Alexis KHOURY wrote:
> Hi,
>
> Thanks for this great piece of software. However, I am having trouble
> connecting to opc server (opc.tcp://
> uademo.prosysopc.com:53530/OPCUA/SimulationServer) freely accessible on the
> internet. On connection I receive an exception "unsupported transport tcp".
>
> Your help is appreciated, we intend to use plc4j driver in our projects
> soon. Thanks in advance for your cooperation.
>
> Regards,
> Alexis
>

AW: AW: [DISCUSS] Where to regster the handler?

[Christofer Dutz]

Hi Lukasz,

I fully agree … that’s why I already started implementing that path a bit in 
order to get a feeling on how it would be used.
Admittedly I’m in strong favor of calling “getUnsubscriptionRequest()” on the 
SubscriptionResponse object.

Chris

Von: Łukasz Dywicki 
Datum: Dienstag, 26. März 2024 um 10:30
An: dev@plc4x.apache.org 
Betreff: Re: AW: [DISCUSS] Where to regster the handler?
Hello Chris,
I believe both ways are fine, but if speak of simplicity the shorter
version wins. Given that after discussed changes unsubscribe call will
not need a builder, we can construct it for user request in one pass.
One consideration I'd make is keeping reference to smaller object rather
than larger ones. This means that
subscriptionResponse.getUnsubscriptionRequest() might be a better fit
than retaining entire subscription response which has much more fields
(field statuses etc.).

Best,
Łukasz

On 26.03.2024 10:17, Christofer Dutz wrote:
> Hi all,
>
> So, I’ve been fefactoring the Subscription stuff in a branch (not yet pushed 
> however).
> I stumbled over something:
>
> In the past we had an unsubscription request that took “subscription handles”
> This made sense as we had one subscription handle per field.
>
> Now that we’re changing things to have a callback for all fileds in the 
> subscription request, I think this method no longer really makes much sense.
>
> I would now rather have someone keep the subscription request and call an 
> “unsubscribe” method on this.
>
> So as soon as you’re finished with your subscription a 
> “subscriptionResponse.unsubscribe()” call would take care of that.
> Or possibly a “subscriptionResponse.getUnsubscriptionRequest().execute()” 
> (which might be more in line with our usual patterns.
> This way also someone could drop the subscription response and save the 
> unsubscriptionRequest till he needs it.
>
> What do you folks think?
>
> Chris
>
>
> Von: Christofer Dutz 
> Datum: Montag, 25. März 2024 um 09:32
> An: dev@plc4x.apache.org 
> Betreff: AW: [DISCUSS] Where to regster the handler?
> Having another look at existing types:
>
> In browse-request we have:
>
>
>*   execute()
>*   executeWithInterceptor()
>
> In discovery-request we have:
>
>
>*   execute()
>*   executeWithHandler()
>
> So, in order to continue that pattern, what do you think about having two 
> options:
>
>
>*   execute()
>*   executeWithHandler()
>
> And to add the option to add a handler to the response.
>
> I know this could let users miss first responses, especially as ADS for 
> example sends an event directly after subscribing.
> However it would be more in line with the rest of the API, which all have an 
> “execute” without any arguments.
>
>
> Thinking even more about everything … I think moving the 
> “executeWithInterceptor” .. the interceptor adding should actually more be 
> added to the request and not the execution.
>
> Also could we add a “WithHandler” option to every type of request.
>
> Chris
>
>
>
> Von: Christofer Dutz 
> Datum: Montag, 25. März 2024 um 09:15
> An: dev@plc4x.apache.org 
> Betreff: [DISCUSS] Where to regster the handler?
> Hi all,
>
> so yesterday I‘ve been working on the refactoring of the subscriptions as we 
> discussed that on the meetup.
> So, we said to register a callback for all fields before the “execute()”
>
>
> Consumer subscriptionConsumer = …;
> PlcSubscriptionRequest.Builder builder = 
> plcConnection.subscriptionRequestBuilder();
> for (int i = 0; i < options.getTagAddress().length; i++) {
>  builder.addChangeOfStateTagAddress("value-" + i, 
> options.getTagAddress()[i]);
> }
> PlcSubscriptionRequest subscriptionRequest = 
> builder.build(subscriptionConsumer);
>
> // Execute the subscription response.
> final PlcSubscriptionResponse subscriptionResponse = 
> subscriptionRequest.execute().get();
>
> Right now, I initially thought about adding it to the build()-method, but 
> that sort of felt oddly.
>
> Thinking about it a bit more, adding it to the “execute” seemed a bit more 
> like what I was looking for.
>
> So, what do you think about doing:
>
>
> Consumer subscriptionConsumer = …;
> PlcSubscriptionRequest.Builder builder = 
> plcConnection.subscriptionRequestBuilder();
> for (int i = 0; i < options.getTagAddress().length; i++) {
>  builder.addChangeOfStateTagAddress("value-" + i, 
> options.getTagAddress()[i]);
> }
> PlcSubscriptionRequest subscriptionRequest = builder.build();
>
> // Execute the subscription response.
> final PlcSubscriptionResponse subscriptionResponse = 
> subscriptionRequest.execute(subscriptionConsumer).get();
>
> What’s your opinion? I prefer the adding to the “execute” method.
>
> Chris
>

[DISCUSS] Refactor the whole "tag-query" and "tag" stuff

[Christofer Dutz]

Hi all,

Initially I introduced the „tag-query” for subscriptions as quite regularly 
there I didn#t want to list all tags, that I subscribe to, but wanted to be 
able to use queries to filter which ones I’m interested in.

However, when going through the current subscription/publication API, I think 
that might have been a bad idea.

We could instead have queries be a special form of Tag … cause for example in 
ADS I could have a symbolic address and get a tag for that and read it. 
However, I currently would have to create a new Query in order to subscribe. 
This doesn’t sound good to me.

So, what do you think? Should I refactor the SubscriptionAPI to use normal Tag 
instances … the protocol dependent address parsers could then continue to 
produce Tags or QueryTags … the main difference would be, that if I add a query 
tag to a read-request, building or executing that request should probably 
produce an error for that field. (Which matches what we discussed during the 
meetup … that drivers should use return codes more excessively to report if 
subscriptions are not supported for the current device)

What do you folks think?

Chris

AW: [DISCUSS] Where to regster the handler?

[Christofer Dutz]

Hi all,

So, I’ve been fefactoring the Subscription stuff in a branch (not yet pushed 
however).
I stumbled over something:

In the past we had an unsubscription request that took “subscription handles”
This made sense as we had one subscription handle per field.

Now that we’re changing things to have a callback for all fileds in the 
subscription request, I think this method no longer really makes much sense.

I would now rather have someone keep the subscription request and call an 
“unsubscribe” method on this.

So as soon as you’re finished with your subscription a 
“subscriptionResponse.unsubscribe()” call would take care of that.
Or possibly a “subscriptionResponse.getUnsubscriptionRequest().execute()” 
(which might be more in line with our usual patterns.
This way also someone could drop the subscription response and save the 
unsubscriptionRequest till he needs it.

What do you folks think?

Chris


Von: Christofer Dutz 
Datum: Montag, 25. März 2024 um 09:32
An: dev@plc4x.apache.org 
Betreff: AW: [DISCUSS] Where to regster the handler?
Having another look at existing types:

In browse-request we have:


  *   execute()
  *   executeWithInterceptor()

In discovery-request we have:


  *   execute()
  *   executeWithHandler()

So, in order to continue that pattern, what do you think about having two 
options:


  *   execute()
  *   executeWithHandler()

And to add the option to add a handler to the response.

I know this could let users miss first responses, especially as ADS for example 
sends an event directly after subscribing.
However it would be more in line with the rest of the API, which all have an 
“execute” without any arguments.


Thinking even more about everything … I think moving the 
“executeWithInterceptor” .. the interceptor adding should actually more be 
added to the request and not the execution.

Also could we add a “WithHandler” option to every type of request.

Chris



Von: Christofer Dutz 
Datum: Montag, 25. März 2024 um 09:15
An: dev@plc4x.apache.org 
Betreff: [DISCUSS] Where to regster the handler?
Hi all,

so yesterday I‘ve been working on the refactoring of the subscriptions as we 
discussed that on the meetup.
So, we said to register a callback for all fields before the “execute()”


Consumer subscriptionConsumer = …;
PlcSubscriptionRequest.Builder builder = 
plcConnection.subscriptionRequestBuilder();
for (int i = 0; i < options.getTagAddress().length; i++) {
builder.addChangeOfStateTagAddress("value-" + i, 
options.getTagAddress()[i]);
}
PlcSubscriptionRequest subscriptionRequest = 
builder.build(subscriptionConsumer);

// Execute the subscription response.
final PlcSubscriptionResponse subscriptionResponse = 
subscriptionRequest.execute().get();

Right now, I initially thought about adding it to the build()-method, but that 
sort of felt oddly.

Thinking about it a bit more, adding it to the “execute” seemed a bit more like 
what I was looking for.

So, what do you think about doing:


Consumer subscriptionConsumer = …;
PlcSubscriptionRequest.Builder builder = 
plcConnection.subscriptionRequestBuilder();
for (int i = 0; i < options.getTagAddress().length; i++) {
builder.addChangeOfStateTagAddress("value-" + i, 
options.getTagAddress()[i]);
}
PlcSubscriptionRequest subscriptionRequest = builder.build();

// Execute the subscription response.
final PlcSubscriptionResponse subscriptionResponse = 
subscriptionRequest.execute(subscriptionConsumer).get();

What’s your opinion? I prefer the adding to the “execute” method.

Chris

AW: Moving things to the plc4x-extras.git repo

[Christofer Dutz]

Guess I’ll leave this thread for another 2-3 days and then start moving things 
based on my proposal.

Chris

Von: Christofer Dutz 
Datum: Sonntag, 24. März 2024 um 11:04
An: dev@plc4x.apache.org 
Betreff: Moving things to the plc4x-extras.git repo
Hi all,

so I just initiated the creation of the plc4x-extras repo and I guess it will 
be created in a few minutes.

I would propose we keep the naming scheme identical to the main repo:

  *   Development is done on “develop”
  *   Releases are merged to “release”


Regarding components that should be moved to the extras repo, how about this:


  *   plc4c/examples/**
  *   plc4c/integrations/**
  *   plc4x/tools/plc4x-server



  *   plc4go/examples/**
  *   plc4go/tools/plc4xbrowser
  *   plc4go/tools/plc4xpcapanalyzer
  *   (it looks as if plc4go/tools/generator and licenser are tools used for 
the build)


  *   plc4j/examples/**
  *   plc4j/integrations/**
  *   plc4j/tools/opcua-server
  *   plc4j/tools/plc4x-server
  *   plc4j/tools/ui/**

What do you think?

I would propose to keep the directory structure and I would try to replicate 
the general build as it was in a mono-repo before.

I guess the main repo build will then live with a LOT less managed dependencies 
and plugins managed.

Chris

AW: [DISCUSS] Where to regster the handler?

[Christofer Dutz]

Having another look at existing types:

In browse-request we have:


  *   execute()
  *   executeWithInterceptor()

In discovery-request we have:


  *   execute()
  *   executeWithHandler()

So, in order to continue that pattern, what do you think about having two 
options:


  *   execute()
  *   executeWithHandler()

And to add the option to add a handler to the response.

I know this could let users miss first responses, especially as ADS for example 
sends an event directly after subscribing.
However it would be more in line with the rest of the API, which all have an 
“execute” without any arguments.


Thinking even more about everything … I think moving the 
“executeWithInterceptor” .. the interceptor adding should actually more be 
added to the request and not the execution.

Also could we add a “WithHandler” option to every type of request.

Chris



Von: Christofer Dutz 
Datum: Montag, 25. März 2024 um 09:15
An: dev@plc4x.apache.org 
Betreff: [DISCUSS] Where to regster the handler?
Hi all,

so yesterday I‘ve been working on the refactoring of the subscriptions as we 
discussed that on the meetup.
So, we said to register a callback for all fields before the “execute()”


Consumer subscriptionConsumer = …;
PlcSubscriptionRequest.Builder builder = 
plcConnection.subscriptionRequestBuilder();
for (int i = 0; i < options.getTagAddress().length; i++) {
builder.addChangeOfStateTagAddress("value-" + i, 
options.getTagAddress()[i]);
}
PlcSubscriptionRequest subscriptionRequest = 
builder.build(subscriptionConsumer);

// Execute the subscription response.
final PlcSubscriptionResponse subscriptionResponse = 
subscriptionRequest.execute().get();

Right now, I initially thought about adding it to the build()-method, but that 
sort of felt oddly.

Thinking about it a bit more, adding it to the “execute” seemed a bit more like 
what I was looking for.

So, what do you think about doing:


Consumer subscriptionConsumer = …;
PlcSubscriptionRequest.Builder builder = 
plcConnection.subscriptionRequestBuilder();
for (int i = 0; i < options.getTagAddress().length; i++) {
builder.addChangeOfStateTagAddress("value-" + i, 
options.getTagAddress()[i]);
}
PlcSubscriptionRequest subscriptionRequest = builder.build();

// Execute the subscription response.
final PlcSubscriptionResponse subscriptionResponse = 
subscriptionRequest.execute(subscriptionConsumer).get();

What’s your opinion? I prefer the adding to the “execute” method.

Chris

[DISCUSS] Where to regster the handler?

[Christofer Dutz]

Hi all,

so yesterday I‘ve been working on the refactoring of the subscriptions as we 
discussed that on the meetup.
So, we said to register a callback for all fields before the “execute()”


Consumer subscriptionConsumer = …;
PlcSubscriptionRequest.Builder builder = 
plcConnection.subscriptionRequestBuilder();
for (int i = 0; i < options.getTagAddress().length; i++) {
builder.addChangeOfStateTagAddress("value-" + i, 
options.getTagAddress()[i]);
}
PlcSubscriptionRequest subscriptionRequest = 
builder.build(subscriptionConsumer);

// Execute the subscription response.
final PlcSubscriptionResponse subscriptionResponse = 
subscriptionRequest.execute().get();

Right now, I initially thought about adding it to the build()-method, but that 
sort of felt oddly.

Thinking about it a bit more, adding it to the “execute” seemed a bit more like 
what I was looking for.

So, what do you think about doing:


Consumer subscriptionConsumer = …;
PlcSubscriptionRequest.Builder builder = 
plcConnection.subscriptionRequestBuilder();
for (int i = 0; i < options.getTagAddress().length; i++) {
builder.addChangeOfStateTagAddress("value-" + i, 
options.getTagAddress()[i]);
}
PlcSubscriptionRequest subscriptionRequest = builder.build();

// Execute the subscription response.
final PlcSubscriptionResponse subscriptionResponse = 
subscriptionRequest.execute(subscriptionConsumer).get();

What’s your opinion? I prefer the adding to the “execute” method.

Chris

Summery of yesterday's meetup

[Christofer Dutz]

Hi all,

here comes a summary of what we discussed yesterday … feel free to add things, 
that I might have missed writing down.


  *   Lukasz brought up the problem in Modbus (and I guess CAN) that he would 
like to extend the address syntax with a “unit-id” attribute in order to 
address multiple devices.
We decided that we should start adding this sort of optional “tag-options” with 
a java-script-like notation after the tag:
tag-address:plc-value-type{option:’value’, option-2:’value-2’}
- Lukasz started working on this and is leading this extension.
  *   OSGI support: It seems that we currently generate the OSGI manifests 
automatically. This works, but has the disadvantage, that a lot more is 
included than is really needed. Lukasz and Ben proposed to manually curate this 
list of dependencies and hereby make the OSGI bundles a lot more lightweight. I 
proposed to live with the generated bundles per default and to manually update 
them. This way we are not reliant on Lukasz and Ben keeping them up to date. 
So, we have the fallback: If there are problems with the bundles, but nobody is 
there to manage them manually – we default back to the generated ones.
- Lukasz volunteered to lead this initiative.
  *   We discussed the usefulness of a Simulator: Chris proposed to generally 
build it, so it is only built for working with PLC4X drivers (It is not meant 
to be a full implementation of the protocols). A plc4x driver needs to be used 
to configure the simulated device that is then also queried by the same driver. 
This simplifies everything a LOT and as a result we could both tests a PLC4X 
application for which the corresponding PLC does not exist (or we want to test 
how the application behaves in hard to produce situations.
- No real lead has been set and this is considered more a long-time-perspective 
goal to reach
  *   We discussed the need to generate larger protions of the code (Chris gave 
a walk through what he thinks we need and in which steps to achieve it:
1. Generate Message Templates (helper functions to generate and initialize 
protocol messages)
2. Generate Interactions (Use the message templates and define what defines a 
“response” and simplify sending requests and handling responses
3. Generate a driver as sequence of interactions based an a directed graph, 
that represents the protocol logic.
- Chris said he’s currently working on the message templates based on an 
extended XML notation that matches that of the unit- and integration-tests.
  *   We discussed splitting up the repository into a main repo and an 
“plc4x-extras” repo, that contains examples, integration modules and optional 
tools. The reasoning behind this is, that most security-related dependency 
updates and transitive CVEs we get reported are mostly because of the 
integration modules and examples. By splitting the repositories up, we would 
rid the core-repo of these CVEs. Especially looking toward the CRE and PLD 
initiatives, we see a large benefit in having our core-repo clean of these 
dependencies.
- A vote was started on the mailing list, and it was in huge favor of creating 
the plc4x-extras repo and the creation has been initiated
- Currently we are discussing on the list which parts should be moved and how, 
also which branch strategy to use etc.
  *   Ben and Lukas worked on moving finishing some unfinished business in 
PLC4PY and moving this out of the sandbox
- This work has been finished during the meetup and plc4py is now located in 
the root of the main repo
  *   As the “sandbox” now only contained no longer worked on initiatives, we 
decided to remove these and we then completely removed the now empty sandbox 
all together.
  *   We discussed the need to refactor the OPC-UA testsuite:
- Chris suggested to refactor the tests requiring a server into 
Integration-Tests which are executed in the integration-test phase and for 
which one Milo server instance would be started in the pre-integration-test 
phase and which is then torn down in the post-integration-test phase, as this 
would probably solve a lot of the issues we were having with Milo in unit-tests.
- Chris will also be working on this feature.

The probably biggest discussion was the: What’s needed for 1.0.0

 *   Publish API (Counterpart of Subscription) (chris)
 *   Streamline other PLC4X Languages APIs to match those of PLC4J 
(sebastian: go, chris: c)
 *   Subscriptions survive connection-reconnections when using 
connection-cache (Auto Re-Subscribe) (chris)
 *   SubscriptionEmulation “decorator” (Component, that implements 
PlcConnection API, but takes care of emulating subscriptions)
*   PlcConnectionManager fluent API extension “ensureSubscribable()”
*   (Lukasz, chris)
 *   Subscriptions: Example: Generally, supports “true” for S7 for example 
if we’re connected to a s7 300 or 400 and reports false for S7-1200 and 
S7-1500. SubscriptionRequestBuilder checks if a given connection supports 
subsc

Moving things to the plc4x-extras.git repo

[Christofer Dutz]

Hi all,

so I just initiated the creation of the plc4x-extras repo and I guess it will 
be created in a few minutes.

I would propose we keep the naming scheme identical to the main repo:

  *   Development is done on “develop”
  *   Releases are merged to “release”


Regarding components that should be moved to the extras repo, how about this:


  *   plc4c/examples/**
  *   plc4c/integrations/**
  *   plc4x/tools/plc4x-server



  *   plc4go/examples/**
  *   plc4go/tools/plc4xbrowser
  *   plc4go/tools/plc4xpcapanalyzer
  *   (it looks as if plc4go/tools/generator and licenser are tools used for 
the build)


  *   plc4j/examples/**
  *   plc4j/integrations/**
  *   plc4j/tools/opcua-server
  *   plc4j/tools/plc4x-server
  *   plc4j/tools/ui/**

What do you think?

I would propose to keep the directory structure and I would try to replicate 
the general build as it was in a mono-repo before.

I guess the main repo build will then live with a LOT less managed dependencies 
and plugins managed.

Chris

AW: [VOTE] Create plc4x-extras repository

[Christofer Dutz]

Hi all …

I guess I can consider this consensus … will order the new repo … then I’ll 
start a new thread to what should be moved there … and then I’ll try to figure 
out how to pull parts of the main repo there.

Chris


Von: Otto Fowler 
Datum: Samstag, 23. März 2024 um 21:00
An: dev@plc4x.apache.org , Christofer Dutz 

Betreff: Re: [VOTE] Create plc4x-extras repository
+1 (binding)

On March 23, 2024 at 12:48:49 PM, Christofer Dutz 
(christofer.d...@c-ware.de<mailto:christofer.d...@c-ware.de>) wrote:
We would like to create a new git-repository “plc4x-extras” that will contain 
the integration modules as well as the examples.

Please vote +1 if you are in favor of creating this repository and moving 
things from the main repository.

Chris

AW: [VOTE] Create plc4x-extras repository

[Christofer Dutz]

+1 (binding)

cdutz



Von: Christofer Dutz 
Datum: Samstag, 23. März 2024 um 17:48
An: dev@plc4x.apache.org 
Betreff: [VOTE] Create plc4x-extras repository
We would like to create a new git-repository “plc4x-extras” that will contain 
the integration modules as well as the examples.

Please vote +1 if you are in favor of creating this repository and moving 
things from the main repository.

Chris

[VOTE] Create plc4x-extras repository

[Christofer Dutz]

We would like to create a new git-repository “plc4x-extras” that will contain 
the integration modules as well as the examples.

Please vote +1 if you are in favor of creating this repository and moving 
things from the main repository.

Chris

AW: UI Branch

[Christofer Dutz]

Hi,

a bit late to this thread, but possibly worth adding my info.

So, I do not have anything on a branch, all I did is on the develop branch.
https://github.com/apache/plc4x/tree/develop/plc4j/tools/ui

This is aimed at being an application, that you start and then you see which 
drivers are available, you can manage connections to your devices, have them 
found via auto-discovery.

In theory you should be able to double-click a configured connection and then 
see which tags are available (If the connection supports browse) and then you 
should be able to read/write or subscribe to tags.



I built it with SpringBoot and React … and please stop asking questions 
formulated: “Why did you decide to not use framework X” because that implies it 
would have been the logical sense to select that one, which especially with UI 
frameworks it is not.

I know SpringBoot and I expect many others to also know it … I know possibly I 
could have selected any of the 100 competing technologies, but I didn’t. I said 
early when starting to work on this: The technology decision is a decision 
being done by the people doing the work and not by the ones having opinions.

Regaring the UI framework: I worked with VUE and didn’t like it from an 
architectural point of view. React feelt a lot more direct and deterministic 
with less “tool-voodo”. Also did React rank better in the lists of how many 
people use framework X … this adoption seems to be not homogeniously spread 
throughout the world. So, for example in China VUE is used a lot more than 
React, but in the rest of the world this is the other way around. So, I simply 
chose to work with the tool that I liked more. If anyone wants to work on the 
UI and wants to use a different technology, I’m fine with that, but I will not 
invest even a single minute into refactoring it based on opinions.

Chris




Von: Cesar Garcia 
Datum: Donnerstag, 21. März 2024 um 20:03
An: dev@plc4x.apache.org 
Betreff: Re: UI Branch
A few years ago I wrote about that concept,

If you visit the blog, But there are many details. The technologies have
changed, but in general the needs are the same,

http://glcj.blogspot.com/

I should restart the blog,

Best regards,




El jue, 21 mar 2024 a las 12:31,  escribió:

> I see...
>
> Are you sure you wanna go with gRPC or Apache Karaf as Backend? Can you
> elaborate on this? Why not websockets builtin in plc4x?
>
> Best regards
>
> -
> Coding Nexus LLC
> Björn Haverland
> 2880W Oakland Park Blvd
> Suite 225C
> Oakland Park
> 33311 Florida
>
> Tel: +1 954 607 2347
>
> bjo...@coding-nexus.com
> https://www.coding-nexus.com
>
>
> -Ursprüngliche Nachricht-
> Von: Cesar Garcia 
> Gesendet: Donnerstag, 21. März 2024 17:17
> An: dev@plc4x.apache.org
> Betreff: Re: UI Branch
>
> Hello,
>
> I took the flag raised by Chris regarding the UI, and we are evaluating
> the different technologies, the idea is to keep things as simple as
> possible (I think).
>
> For the frontend
>
> 1. qooxdoo.
> 2. Apache Echarts.
>
> For the backend
>
> 3. gRPC
> 4. Apache Karaf (Merlot).
>
> I'm going to try to make a demo for the work team on Saturday, against the
> clock, but I'll do my best.
>
> Kind regards,
>
> El jue, 21 mar 2024 a las 12:07,  escribió:
>
> > I’m splitting the topic, I read something about an UI Branch, where
> > can I find it? Is there a particular reason why ReactJS? What is it
> > supposed to be? A unified UI library for all supported plc?
> >
> > So many questions 😉
> >
> >
> >
> > I had an idea of using plc4j add a websocket API and use vueJS (I’m
> > using vue in several projects, have only little experience with React)
> > to export a simple UI library. This way a UI would be very portable
> > across many platforms.
> >
> > Is the ReactJS Branch a similar approach?
> >
> >
> >
> > Best regards
> >
> >
> >
> > Björn
> >
> >
> >
> >
> >
> > Gesendet von Outlook für Android <https://aka.ms/AAb9ysg>
> >
> >   _
> >
> > From: Christofer Dutz 
> > Sent: Thursday, March 21, 2024 1:39:11 PM
> > To: dev@plc4x.apache.org 
> > Subject: AW: [DISCUSS] What do we want to look into/talk about on the
> > Meetup/Workshop?
> >
> >
> >
> > Possibly worth adding:
> > - Refactor the OPC-UA test-suite to run as Integration-Test in the
> > build and to rely on a Milo server started in the pre-integration-test
> > phase and which is stopped in the post-integration-test-phase.
> >
> > Von: Lukas Ott 
> > Datum: Montag, 18. März 2024 um 11:51
> > An:

AW: [DISCUSS] What do we want to look into/talk about on the Meetup/Workshop?

[Christofer Dutz]

Possibly worth adding:
- Refactor the OPC-UA test-suite to run as Integration-Test in the build and to 
rely on a Milo server started in the pre-integration-test phase and which is 
stopped in the post-integration-test-phase.

Von: Lukas Ott 
Datum: Montag, 18. März 2024 um 11:51
An: dev@plc4x.apache.org 
Betreff: Re: [DISCUSS] What do we want to look into/talk about on the 
Meetup/Workshop?
Mine are much simpler:
- Merge my pull request
* https://github.com/apache/plc4x/pull/1419 should be 5-10 minutes with
Sebastian.
- Go through PLC4PY with Ben and get things running on my side
  * Add Pip Package to https://pypi.org/ including release integration etc.
  * What is missing for PLC4Py to get out of the sandbox?
  * Find little tasks where I can start and not overwhelmed as one of
the rare-non developers in that project.
- Look into what you (Chris) did with ReactJS on the UI branch and get that
running

For the rest I am giving a +1 for your points.

Lukas

Am Mo., 18. März 2024 um 11:17 Uhr schrieb Christofer Dutz <
christofer.d...@c-ware.de>:

> Here some things I have on my mind:
>
>
>   *   Road to 1.0.0 (What’s still missing?)
>   *   Generating larger portions of the code (Mesasages & Request+Response)
>   *   Missing features:
>  *   Optimizer Framework (Optimize requests, by rewriting them)
>  *   Subscription Emulation (General purpose component, that uses the
> READ api to simulare subscriptions)
>  *   New/Advanced Scraper (Rewrite of the Scraper, that allows things
> like “read, triggered by subscription”)
>   *   How can we distribute the workload a bit better?
>   *   How can we grow the community?
>
> Chris
>

AW: [DISCUSS] Fix or disable some flaky OPC-UA tests?

[Christofer Dutz]

As again the build failed because of one of these tests, I disabled them for 
now.

So, if you want to keep them, fix them … had to smile, when opeining the 
OpcuaSubscriptionHandleTest as I could see all my frustration with this test 
I’ve had before in the comments on the header of that test.

I am totally pro-tests, but only if the tests work.


Chris

Von: Christofer Dutz 
Datum: Montag, 18. März 2024 um 13:33
An: dev@plc4x.apache.org 
Betreff: [DISCUSS] Fix or disable some flaky OPC-UA tests?
Hi all,

having a look at the latest builds, it shows that some of the OPC-UA tests are 
continuing to be super-flaky … they fail in one build and in anoter others fail.

I would like to see our build on develop become stable and not a gamble.

So, if someone could have a look at these tests and why they have been failing, 
that would be great:


  *   ChunkFactoryTest
  *   OpcuaSubscriptionHandleTest


Otherwise, I’ll simply add a “skip” or “disable” to them in a week or so. I’ve 
invested such an enormous amount of time into trying to find issues in the 
OPC-UA testsuite over the last years, that I consider my fuel-tank for OPC-UA 
issues empty.

Chris

[DISCUSS] Fix or disable some flaky OPC-UA tests?

[Christofer Dutz]

Hi all,

having a look at the latest builds, it shows that some of the OPC-UA tests are 
continuing to be super-flaky … they fail in one build and in anoter others fail.

I would like to see our build on develop become stable and not a gamble.

So, if someone could have a look at these tests and why they have been failing, 
that would be great:


  *   ChunkFactoryTest
  *   OpcuaSubscriptionHandleTest


Otherwise, I’ll simply add a “skip” or “disable” to them in a week or so. I’ve 
invested such an enormous amount of time into trying to find issues in the 
OPC-UA testsuite over the last years, that I consider my fuel-tank for OPC-UA 
issues empty.

Chris

[DISCUSS] What do we want to look into/talk about on the Meetup/Workshop?

[Christofer Dutz]

Here some things I have on my mind:


  *   Road to 1.0.0 (What’s still missing?)
  *   Generating larger portions of the code (Mesasages & Request+Response)
  *   Missing features:
 *   Optimizer Framework (Optimize requests, by rewriting them)
 *   Subscription Emulation (General purpose component, that uses the READ 
api to simulare subscriptions)
 *   New/Advanced Scraper (Rewrite of the Scraper, that allows things like 
“read, triggered by subscription”)
  *   How can we distribute the workload a bit better?
  *   How can we grow the community?

Chris

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

[Christofer Dutz]

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

So when do we want to meet on Saturday?

[Christofer Dutz]

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: AW: [DISCUSS] Disable the Sonar-Check in Github Actions?

[Christofer Dutz]

As long as the sonar reports keep being generated …

I wouldn’t want to give up on that.
A different option would be to relax the rules in Sonar for failing the build.

If someone adds something like fatal issues, I think it’s ok to fail, but based 
on our current coverage levels I would probably relax those rules a bit.

Chris


Von: Sebastian Rühl 
Datum: Freitag, 15. März 2024 um 14:45
An: dev@plc4x.apache.org 
Betreff: Re: AW: [DISCUSS] Disable the Sonar-Check in Github Actions?
Yes, you are absolutely right. Lets just disable the Part in sonar which fails 
the build or mark it as failed and lets disable that.

On 2024/03/15 13:05:00 Christofer Dutz wrote:
> I generally fully agree.
>
> But I don’t want to cause contributors to leave in that case.
> I have seen way too many projects where good contributions don’t get merged 
> because of guards like that.
>
> So, if us doing that would cause us loosing/not attracting new people, then I 
> would be hesitant to add more rules.
>
> In the end it doesn’t help us, if we have a happy Sonar, but we’re (or I) am 
> the only ones contributing, cause everyone else left.
>
> When contributing to other project stuff like that is sometimes the most 
> discouraging things.
> Like “Build failed cause there’s a line-break at the end of this file” 
> (Totally annoyed by that in the IoTDB project).
>
> Chris
>
> Von: Sebastian Rühl 
> Datum: Freitag, 15. März 2024 um 11:23
> An: dev@plc4x.apache.org 
> Betreff: Re: [DISCUSS] Disable the Sonar-Check in Github Actions?
> Honestly I think we should do the following:
>
> - Take sonar serious and look after that stuff Reported there
> - Disable the build breaker for some time so it doesn't flag everything as a 
> failed build
> - Think about how we can avoid ending in the same situation again
>
> If you look at other projects usually you have a build breaker/guard on a PR 
> and then it is the duty of the author to ensure that the code added doesn't 
> break the sonar rules before merging. Due to the fact that we don't follow 
> that it is easy to slip stuff into develop which leads then to a state we 
> have now. Not 100% sure what is best to do here.
>
> Sebastian
>
> On 2024/03/14 21:27:45 Christofer Dutz wrote:
> > Hi all,
> >
> > So, we have been having failing builds for … well … it feels like … ever. 
> > Because the Sonarcloud check always keeps on marking every commit as Errror.
> >
> > I think: Either we pay attention to it, or we disable it.
> >
> > So, what do you folks think? Keeping it on and paying attention to it will 
> > be a lot of work, but it would be worth it.
> >
> > Chris
> >
>

AW: S7 types supporting Subscriptions

[Christofer Dutz]

Hi all,

I wasn’t in favor of this … just added what we would need to fully address it, 
but still I would assume that even then will be some edge-cases.

Throwing an exception sounds quite excessive, but thinking more about it, we do 
return plc status codes for every field.
So, if an operation is requested, that is not supported, we could simply 
indicate that in the status codes returned for that field.
Maybe we need to add some codes we were missing, but I guess that should be a 
lot simpler.

Chris


Von: Cesar Garcia 
Datum: Freitag, 15. März 2024 um 14:15
An: dev@plc4x.apache.org 
Betreff: Re: S7 types supporting Subscriptions
Hello,

I think that makes the API more complex than necessary.

We should keep it as simple as possible.

I think that for the driver there are already some fields that are
MetaData, so we should document and not extend the API.

As you don't point out, for example the S7 has the ability to diagnose
which functions it supports, and then inform the developer. Of course it
takes time to do it.

My grain of sand

El vie, 15 mar 2024 a las 9:02, Christofer Dutz ()
escribió:

> Well in that case we‘d actually have to introduce the following:
>
>
>   *   IsCyclicSubscriptionSupportedForTag
>   *   IsChangeOnValueSubscriptionSupportedForTag
>   *   IsEventSubscriptionSupportedForTag
>
> And possibly the “TagAddress” counterparts.
>
> We’d definitely be blowing up the API that way and making it more complex
> to use.
>
> Possibly throwing an exception when buiding a request might be a better
> option.
> So you use the isXYZSupported functions for general functionality support
> and catch exceptions later.
>
> Chris
>
> Von: Łukasz Dywicki 
> Datum: Freitag, 15. März 2024 um 10:48
> An: dev@plc4x.apache.org 
> Betreff: Re: S7 types supporting Subscriptions
> Thinking of it, maybe it would be better to extend signature of
> subscription inquiry to be isSubscriptionSupported(PlcTag) ?
> My motivation for this is rather basic - the BACnet stuff which is on
> the way will have per-participant subscriptions. Profinet (I suppose) is
> same for cyclic/acyclic subscriptions and so on.
> This gives driver opportunity to make smarter decision. Obviously for
> point to point connection such S7-TCP we can rely on device type
> negotiated earlier, *but* spanning further, we could finally let S7-1200
> subscriptions only for MODE events.
>
> Cheers,
> Łukasz
>
> On 13.03.2024 21:16, Christofer Dutz wrote:
> > Changing the title ….
> >
> > So, I just updated the S7 driver to no longer simply report true on
> “isSubscriptionSupported()” and it now only reports “true”, if it’s a
> S7-300 or S7-400.
> > If there is more, that needs to be enabled in order to support
> subscriptions on such a device, it would be cool, if we could detect that
> during the connection process and report accordingly.
> >
> > Chris
> >
> >
> > Von: Cesar Garcia 
> > Datum: Mittwoch, 13. März 2024 um 21:12
> > An: dev@plc4x.apache.org 
> > Betreff: Re: Board report 
> > Hello Chris,
> >
> > The S7-300/S7-400 devices have an important group of functions for event
> > handling. In the process part (PCS7) this is handled intensively.
> >
> > At the time, all these operations are on the Tag associated with the
> > request, so any service type subscription is a subscription to events.
> >
> > In general the S7-300/S7-400 support;
> >
> > - *MODE*: Change of operating state in the controller, change from
> STOP
> > to RUN and vice versa.
> > - *SYS*: System events, associated with internal events of the
> > controller or events previously parameterized for their indication.
> > - *USR*: Events programmed by the user and that are registered in the
> > internal diagnostic buffer.
> > - *ALM*: Alarm events generated by the user program, ALARM_S,
> ALARM_8,
> > NOTIFY.
> > - And additionally "*CYC*" cyclic mode transfer.
> >
> >
> > But in general they are all seen as events, hence the inconsistency
> pointed
> > out by Bjorn.
> >
> > All these events are implemented, of course, they have many points of
> > improvement that must be addressed.
> >
> > I currently do not have a PN or CP-343-1 CPU for testing with S7-300.
> >
> > As you point out, with Zylk's contribution it can complement the CP-443-1
> > for redudance tests (thanks Zylk).
> >
> > Well, the story is long... I'm going for a good coffee.
> >
> > Kind regards,
> >
> > El mié, 13 mar 2024 a las 14:57, Christofer Dutz (<
> christofer.d...@c-ware.de>)
> > escribió:
> >
&

AW: [DISCUSS] Disable the Sonar-Check in Github Actions?

[Christofer Dutz]

I generally fully agree.

But I don’t want to cause contributors to leave in that case.
I have seen way too many projects where good contributions don’t get merged 
because of guards like that.

So, if us doing that would cause us loosing/not attracting new people, then I 
would be hesitant to add more rules.

In the end it doesn’t help us, if we have a happy Sonar, but we’re (or I) am 
the only ones contributing, cause everyone else left.

When contributing to other project stuff like that is sometimes the most 
discouraging things.
Like “Build failed cause there’s a line-break at the end of this file” (Totally 
annoyed by that in the IoTDB project).

Chris

Von: Sebastian Rühl 
Datum: Freitag, 15. März 2024 um 11:23
An: dev@plc4x.apache.org 
Betreff: Re: [DISCUSS] Disable the Sonar-Check in Github Actions?
Honestly I think we should do the following:

- Take sonar serious and look after that stuff Reported there
- Disable the build breaker for some time so it doesn't flag everything as a 
failed build
- Think about how we can avoid ending in the same situation again

If you look at other projects usually you have a build breaker/guard on a PR 
and then it is the duty of the author to ensure that the code added doesn't 
break the sonar rules before merging. Due to the fact that we don't follow that 
it is easy to slip stuff into develop which leads then to a state we have now. 
Not 100% sure what is best to do here.

Sebastian

On 2024/03/14 21:27:45 Christofer Dutz wrote:
> Hi all,
>
> So, we have been having failing builds for … well … it feels like … ever. 
> Because the Sonarcloud check always keeps on marking every commit as Errror.
>
> I think: Either we pay attention to it, or we disable it.
>
> So, what do you folks think? Keeping it on and paying attention to it will be 
> a lot of work, but it would be worth it.
>
> Chris
>

AW: S7 types supporting Subscriptions

[Christofer Dutz]

Well in that case we‘d actually have to introduce the following:


  *   IsCyclicSubscriptionSupportedForTag
  *   IsChangeOnValueSubscriptionSupportedForTag
  *   IsEventSubscriptionSupportedForTag

And possibly the “TagAddress” counterparts.

We’d definitely be blowing up the API that way and making it more complex to 
use.

Possibly throwing an exception when buiding a request might be a better option.
So you use the isXYZSupported functions for general functionality support and 
catch exceptions later.

Chris

Von: Łukasz Dywicki 
Datum: Freitag, 15. März 2024 um 10:48
An: dev@plc4x.apache.org 
Betreff: Re: S7 types supporting Subscriptions
Thinking of it, maybe it would be better to extend signature of
subscription inquiry to be isSubscriptionSupported(PlcTag) ?
My motivation for this is rather basic - the BACnet stuff which is on
the way will have per-participant subscriptions. Profinet (I suppose) is
same for cyclic/acyclic subscriptions and so on.
This gives driver opportunity to make smarter decision. Obviously for
point to point connection such S7-TCP we can rely on device type
negotiated earlier, *but* spanning further, we could finally let S7-1200
subscriptions only for MODE events.

Cheers,
Łukasz

On 13.03.2024 21:16, Christofer Dutz wrote:
> Changing the title ….
>
> So, I just updated the S7 driver to no longer simply report true on 
> “isSubscriptionSupported()” and it now only reports “true”, if it’s a S7-300 
> or S7-400.
> If there is more, that needs to be enabled in order to support subscriptions 
> on such a device, it would be cool, if we could detect that during the 
> connection process and report accordingly.
>
> Chris
>
>
> Von: Cesar Garcia 
> Datum: Mittwoch, 13. März 2024 um 21:12
> An: dev@plc4x.apache.org 
> Betreff: Re: Board report 
> Hello Chris,
>
> The S7-300/S7-400 devices have an important group of functions for event
> handling. In the process part (PCS7) this is handled intensively.
>
> At the time, all these operations are on the Tag associated with the
> request, so any service type subscription is a subscription to events.
>
> In general the S7-300/S7-400 support;
>
> - *MODE*: Change of operating state in the controller, change from STOP
> to RUN and vice versa.
> - *SYS*: System events, associated with internal events of the
> controller or events previously parameterized for their indication.
> - *USR*: Events programmed by the user and that are registered in the
> internal diagnostic buffer.
> - *ALM*: Alarm events generated by the user program, ALARM_S, ALARM_8,
> NOTIFY.
> - And additionally "*CYC*" cyclic mode transfer.
>
>
> But in general they are all seen as events, hence the inconsistency pointed
> out by Bjorn.
>
> All these events are implemented, of course, they have many points of
> improvement that must be addressed.
>
> I currently do not have a PN or CP-343-1 CPU for testing with S7-300.
>
> As you point out, with Zylk's contribution it can complement the CP-443-1
> for redudance tests (thanks Zylk).
>
> Well, the story is long... I'm going for a good coffee.
>
> Kind regards,
>
> El mié, 13 mar 2024 a las 14:57, Christofer Dutz ()
> escribió:
>
>> Hi Björn,
>>
>> the problem with the subscriptions in S7 are that they do work, but only
>> on S7 300 (I think).
>> I mentioned before on this list, that we should probably do
>> context-sensitive “isXYZSupported” functions.
>> Unfortunately, I haven’t yet had the time to implement them.
>>
>> So, to make it short … in general the S7 protocol doesn’t support
>> subscriptions, except for a small subset of device types.
>> If Cesar could possibly tell me which devices support Subscriptions, I
>> could implement something to make this happen (Shouldn’t be too much work).
>>
>> One day we’ll probably have simulated subscriptions, but admittedly as
>> nobody really seems to be interested in working on core-services like this,
>> it’s probably gonna take a while.
>> In the past I was able to work on PLC4X full time, but as no company
>> (except Zylk) was really willing to pay for any form of development, I had
>> to pick a job that pays the bills.
>> I’m still on it, but doing this in my free time.
>>
>> Chris
>>
>> Von: Björn Haverland 
>> Datum: Mittwoch, 13. März 2024 um 18:52
>> An: dev@plc4x.apache.org 
>> Betreff: Re: Board report 
>> Hi,
>>
>> as I'm starting to get used to the project I do have some questions,
>> especially regarding the mentioned v1.0.0.
>>
>> I tried to set up a plc4j with the quickstart guide which utilizes the S7
>> protocol.
>>
>&

[DISCUSS] Disable the Sonar-Check in Github Actions?

[Christofer Dutz]

Hi all,

So, we have been having failing builds for … well … it feels like … ever. 
Because the Sonarcloud check always keeps on marking every commit as Errror.

I think: Either we pay attention to it, or we disable it.

So, what do you folks think? Keeping it on and paying attention to it will be a 
lot of work, but it would be worth it.

Chris

S7 types supporting Subscriptions

[Christofer Dutz]

Changing the title ….

So, I just updated the S7 driver to no longer simply report true on 
“isSubscriptionSupported()” and it now only reports “true”, if it’s a S7-300 or 
S7-400.
If there is more, that needs to be enabled in order to support subscriptions on 
such a device, it would be cool, if we could detect that during the connection 
process and report accordingly.

Chris


Von: Cesar Garcia 
Datum: Mittwoch, 13. März 2024 um 21:12
An: dev@plc4x.apache.org 
Betreff: Re: Board report 
Hello Chris,

The S7-300/S7-400 devices have an important group of functions for event
handling. In the process part (PCS7) this is handled intensively.

At the time, all these operations are on the Tag associated with the
request, so any service type subscription is a subscription to events.

In general the S7-300/S7-400 support;

   - *MODE*: Change of operating state in the controller, change from STOP
   to RUN and vice versa.
   - *SYS*: System events, associated with internal events of the
   controller or events previously parameterized for their indication.
   - *USR*: Events programmed by the user and that are registered in the
   internal diagnostic buffer.
   - *ALM*: Alarm events generated by the user program, ALARM_S, ALARM_8,
   NOTIFY.
   - And additionally "*CYC*" cyclic mode transfer.


But in general they are all seen as events, hence the inconsistency pointed
out by Bjorn.

All these events are implemented, of course, they have many points of
improvement that must be addressed.

I currently do not have a PN or CP-343-1 CPU for testing with S7-300.

As you point out, with Zylk's contribution it can complement the CP-443-1
for redudance tests (thanks Zylk).

Well, the story is long... I'm going for a good coffee.

Kind regards,

El mié, 13 mar 2024 a las 14:57, Christofer Dutz ()
escribió:

> Hi Björn,
>
> the problem with the subscriptions in S7 are that they do work, but only
> on S7 300 (I think).
> I mentioned before on this list, that we should probably do
> context-sensitive “isXYZSupported” functions.
> Unfortunately, I haven’t yet had the time to implement them.
>
> So, to make it short … in general the S7 protocol doesn’t support
> subscriptions, except for a small subset of device types.
> If Cesar could possibly tell me which devices support Subscriptions, I
> could implement something to make this happen (Shouldn’t be too much work).
>
> One day we’ll probably have simulated subscriptions, but admittedly as
> nobody really seems to be interested in working on core-services like this,
> it’s probably gonna take a while.
> In the past I was able to work on PLC4X full time, but as no company
> (except Zylk) was really willing to pay for any form of development, I had
> to pick a job that pays the bills.
> I’m still on it, but doing this in my free time.
>
> Chris
>
> Von: Björn Haverland 
> Datum: Mittwoch, 13. März 2024 um 18:52
> An: dev@plc4x.apache.org 
> Betreff: Re: Board report 
> Hi,
>
> as I'm starting to get used to the project I do have some questions,
> especially regarding the mentioned v1.0.0.
>
> I tried to set up a plc4j with the quickstart guide which utilizes the S7
> protocol.
>
> So there are examples, in the example folder as well, which are just not
> working. (The Subscription for instance) I do understand that the lib
> hasn't had a Major release yet, but I think it could set people off.
>
> I like to suggest to change the docs on that points. I know it is hard to
> test everything but if a feature isn't implemented a wrong documentation
> just leads to frustration.
> Cesar has implemented a working CyclicSubscription, and I think he is
> going to merge it to the dev branch soon. But still there are other
> subscription methods shown which won't work, just yet.
>
> I'd like to hear your opinion on this.
>
> Best regards
>
> Bjoern
>
>
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> 
> From: Christofer Dutz 
> Sent: Wednesday, March 13, 2024 12:00:11 PM
> To: dev@plc4x.apache.org 
> Subject: Board report 
>
> Hi all,
>
> unfortunately I had almost forgotten to submit the board report after
> coming back from my little snowboard vacation.
> I took the liberty of posting the following report. If there are changes
> you’d like to see, please tell me asap and I can edit it.
>
>
>
> ## 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.
>
> ## Project Status:
> Current project status: Ongoing with moderate activity
> Issues for the board: None
>
> ## Membership Data:
> A

AW: Board report ....

[Christofer Dutz]

Hi Björn,

the problem with the subscriptions in S7 are that they do work, but only on S7 
300 (I think).
I mentioned before on this list, that we should probably do context-sensitive 
“isXYZSupported” functions.
Unfortunately, I haven’t yet had the time to implement them.

So, to make it short … in general the S7 protocol doesn’t support 
subscriptions, except for a small subset of device types.
If Cesar could possibly tell me which devices support Subscriptions, I could 
implement something to make this happen (Shouldn’t be too much work).

One day we’ll probably have simulated subscriptions, but admittedly as nobody 
really seems to be interested in working on core-services like this, it’s 
probably gonna take a while.
In the past I was able to work on PLC4X full time, but as no company (except 
Zylk) was really willing to pay for any form of development, I had to pick a 
job that pays the bills.
I’m still on it, but doing this in my free time.

Chris

Von: Björn Haverland 
Datum: Mittwoch, 13. März 2024 um 18:52
An: dev@plc4x.apache.org 
Betreff: Re: Board report 
Hi,

as I'm starting to get used to the project I do have some questions, especially 
regarding the mentioned v1.0.0.

I tried to set up a plc4j with the quickstart guide which utilizes the S7 
protocol.

So there are examples, in the example folder as well, which are just not 
working. (The Subscription for instance) I do understand that the lib hasn't 
had a Major release yet, but I think it could set people off.

I like to suggest to change the docs on that points. I know it is hard to test 
everything but if a feature isn't implemented a wrong documentation just leads 
to frustration.
Cesar has implemented a working CyclicSubscription, and I think he is going to 
merge it to the dev branch soon. But still there are other subscription methods 
shown which won't work, just yet.

I'd like to hear your opinion on this.

Best regards

Bjoern



Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
____
From: Christofer Dutz 
Sent: Wednesday, March 13, 2024 12:00:11 PM
To: dev@plc4x.apache.org 
Subject: Board report 

Hi all,

unfortunately I had almost forgotten to submit the board report after coming 
back from my little snowboard vacation.
I took the liberty of posting the following report. If there are changes you’d 
like to see, please tell me asap and I can edit it.



## 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.

## Project Status:
Current project status: Ongoing with moderate activity
Issues for the board: None

## Membership Data:
Apache PLC4X was founded 2019-04-17 (5 years ago)
There are currently 21 committers and 13 PMC members in this project.
The Committer-to-PMC ratio is roughly 3:2.

Community changes, past quarter:
- No new PMC members. Last addition was César García on 2021-10-01.
- No new committers. Last addition was Jinlin Hong on 2022-11-02.

## Project Activity:
Version 0.12.0 was released on 2024-02-19

The project has been working on closing many issues this quarter.
We were able to cut the number of open issues by half. Also did we
invest a considerable amount of time for working towards reproducible
builds and automating most of the release process. Also did we update
the content on the website, especially thanks to a new documentation-
generator now the configuration for our drivers is automatically going
to be up to date.

## Community Health:
We know we haven't invited any new committers for quite some time.
This is definitely not due to a high committer bar, but more related
to the fact that the people needing Apache PLC4X seem to come from a
part of the industry that is completely new to the concept of open-source.

Only very few people accept our offer to mentor them to scratching their
own itches.

Interestingly the project is gaining more and more popularity on the user-
side.

Activity on the mailing lists seems to have increased slightly (8% - 605 emails)

The community is looking forward to a community meetup in Frankfurt the
weekend after the board meeting. Here we hope to re-ignite some of the
community activity and focus on perhaps releasing a 1.0.0 version of
PLC4X this year.

Disabling flaky GO tests ...

[Christofer Dutz]

Hi all,

in the past there generally seem 2 reasons for failing tests:

  1.  Infra has upsies with timeouts when we deploy the snapshots
  2.  Some go tests (mainly Cbus) randomly fail.

I was hoping we would be able to resolve the flakiness, however it seems we 
can’t.
So, I’ll be starting to disable flaky tests.

I know this is not ideal, but I think having a non-stable build is worse. I 
think the Cbus driver never got finished anyway -right?
So, nobody would be using it anyway, so I guess there’s no harm done by 
disabling the test.

Please speak up if you think different ;-)

Chris

Board report ....

[Christofer Dutz]

Hi all,

unfortunately I had almost forgotten to submit the board report after coming 
back from my little snowboard vacation.
I took the liberty of posting the following report. If there are changes you’d 
like to see, please tell me asap and I can edit it.



## 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.

## Project Status:
Current project status: Ongoing with moderate activity
Issues for the board: None

## Membership Data:
Apache PLC4X was founded 2019-04-17 (5 years ago)
There are currently 21 committers and 13 PMC members in this project.
The Committer-to-PMC ratio is roughly 3:2.

Community changes, past quarter:
- No new PMC members. Last addition was César García on 2021-10-01.
- No new committers. Last addition was Jinlin Hong on 2022-11-02.

## Project Activity:
Version 0.12.0 was released on 2024-02-19

The project has been working on closing many issues this quarter.
We were able to cut the number of open issues by half. Also did we
invest a considerable amount of time for working towards reproducible
builds and automating most of the release process. Also did we update
the content on the website, especially thanks to a new documentation-
generator now the configuration for our drivers is automatically going
to be up to date.

## Community Health:
We know we haven't invited any new committers for quite some time.
This is definitely not due to a high committer bar, but more related
to the fact that the people needing Apache PLC4X seem to come from a
part of the industry that is completely new to the concept of open-source.

Only very few people accept our offer to mentor them to scratching their
own itches.

Interestingly the project is gaining more and more popularity on the user-
side.

Activity on the mailing lists seems to have increased slightly (8% - 605 emails)

The community is looking forward to a community meetup in Frankfurt the
weekend after the board meeting. Here we hope to re-ignite some of the
community activity and focus on perhaps releasing a 1.0.0 version of
PLC4X this year.

AW: Next steps for your trip to Bratislava

[Christofer Dutz]

Hi all … sorry for that … Outlook seems to try and be smarter than it actually 
is :-(

Von: Christofer Dutz 
Datum: Dienstag, 5. März 2024 um 16:19
An: dev@plc4x.apache.org , i...@apache.org 

Betreff: Next steps for your trip to Bratislava
Hi Christopher,

congratulations, you have been chosen to receive sponsoring from the Apache TAC 
program.
We’re looking forward to meeting you at Community over Code Bratislava this 
June.

First, we need you to formally accept your invitation. So … do you accept our 
invitation?

>From what we have on file you have asked for assistance and have been granted:


  *   Travel
  *   Accommodation
  *   Conference Registration

As we will be doing some introduction tasks on Sunday afternoon, were planning 
on getting you to Bratislava on the 01.06.2024.
We are planning on sending you back home on the day after the conference.
However, in some cases we might ask you to stay another day or two or come in 
earlier, if flight costs and connections are a significantly better. Would that 
be ok for you?

We would also need detailed information on the airport we would be booking your 
flights from and to.

To further proceed we need some general information from you:

  *   Your date of birth
  *   A mobile phone number (so we can get in touch with you when travelling)
  *   Your T-Shirt size
  *   Do you have any dietary requirements?

Please go through this email several times to ensure you’re answering all 
questions that we ask and please reply in a timely manner.
We’re all doing this in our free time and we’re trying to make this process as 
smooth as possible for all sides.

Summary of what we deed from you now:

  *   Do you accept?
  *   Are you ok with the general dates?
  *   Which airports would you be coming from/to?
  *   Your date of birth
  *   A mobile phone number
  *   Your T-Shirt Size
  *   Your dietary requirements

Greetings,
Chris
On behalf of Apache TAC

Aaaaaarrrrrgh !!!

[Christofer Dutz]

I am so sorry … for some reason my email client changed the address I was 
copying … and I noticed way too late ☹

Next steps for your trip to Bratislava

[Christofer Dutz]

Hi Mbah,

congratulations, you have been chosen to receive sponsoring from the Apache TAC 
program.
We’re looking forward to meeting you at Community over Code Bratislava this 
June.

First, we need you to formally accept your invitation. So … do you accept our 
invitation?

>From what we have on file you have asked for assistance and have been granted:


  *   Travel
  *   Accommodation
  *   Conference Registration

As we will be doing some introduction tasks on Sunday afternoon, were planning 
on getting you to Bratislava on the 01.06.2024.
We are planning on sending you back home on the day after the conference.
However, in some cases we might ask you to stay another day or two or come in 
earlier, if flight costs and connections are a significantly better. Would that 
be ok for you?

We would also need detailed information on the airport we would be booking your 
flights from and to.

As you state to be requiring a Visa, we will be booking your flight as soon as 
you have your Visa. Let us know if you need any help with obtaining the Visa 
(documents etc.)

To further proceed we need some general information from you:

  *   Your date of birth
  *   A mobile phone number (so we can get in touch with you when travelling)
  *   Your T-Shirt size
  *   Do you have any dietary requirements?

Please go through this email several times to ensure you’re answering all 
questions that we ask and please reply in a timely manner.
We’re all doing this in our free time and we’re trying to make this process as 
smooth as possible for all sides.

Summary of what we deed from you now:

  *   Do you accept?
  *   Are you ok with the general dates?
  *   Which airports would you be coming from/to?
  *   Your date of birth
  *   A mobile phone number
  *   Your T-Shirt Size
  *   Your dietary requirements

Greetings,
Chris
On behalf of Apache TAC

Next steps for your trip to Bratislava

[Christofer Dutz]

Hi Öykü,

congratulations, you have been chosen to receive sponsoring from the Apache TAC 
program.
We’re looking forward to meeting you at Community over Code Bratislava this 
June.

First, we need you to formally accept your invitation. So … do you accept our 
invitation?

>From what we have on file you have asked for assistance and have been granted:


  *   Travel
  *   Accommodation
  *   Conference Registration

As we will be doing some introduction tasks on Sunday afternoon, were planning 
on getting you to Bratislava on the 01.06.2024.
We are planning on sending you back home on the day after the conference. You 
state that you would like to travel back on the 08th. We hope that the ASF 
can’t cover the accommodation costs for that. Are you ok with potentially 
covering your accommodation for the prolonged stay?
However, in some cases we might ask you to stay another day or two or come in 
earlier, if flight costs and connections are a significantly better. Would that 
be ok for you?

We would also need detailed information on the airport we would be booking your 
flights from and to.

As you state to be requiring a Visa, we will be booking your flight as soon as 
you have your Visa. Let us know if you need any help with obtaining the Visa 
(documents etc.)

To further proceed we need some general information from you:

  *   Your date of birth
  *   A mobile phone number (so we can get in touch with you when travelling)
  *   Your T-Shirt size
  *   Do you have any dietary requirements?

Please go through this email several times to ensure you’re answering all 
questions that we ask and please reply in a timely manner.
We’re all doing this in our free time and we’re trying to make this process as 
smooth as possible for all sides.

Summary of what we deed from you now:

  *   Do you accept?
  *   Are you ok with the general dates?
  *   Are you ok with potentially covering for your prolonged accommodation?
  *   Which airports would you be coming from/to?
  *   Your date of birth
  *   A mobile phone number
  *   Your T-Shirt Size
  *   Your dietary requirements

Greetings,
Chris
On behalf of Apache TAC

Next steps for your trip to Bratislava

[Christofer Dutz]

Hi Tomas,

congratulations, you have been chosen to receive sponsoring from the Apache TAC 
program.
We’re looking forward to meeting you at Community over Code Bratislava this 
June.

First, we need you to formally accept your invitation. So … do you accept our 
invitation?

>From what we have on file you have asked for assistance and have been granted:


  *   Travel
  *   Accommodation
  *   Conference Registration

As we will be doing some introduction tasks on Sunday afternoon, were planning 
on getting you to Bratislava on the 01.06.2024.
We are planning on sending you back home on the day after the conference, 
however you ask to stay longer. We hope you understand that the ASF can’t be 
covering the additional Hotel costs for that stay, so are you ok with covering 
any accommodation costs beyond the 06th?
However, in some cases we might ask you to stay another day or two or come in 
earlier, if flight costs and connections are a significantly better. Would that 
be ok for you?

We would also need detailed information on the airport we would be booking your 
flights from and to.

To further proceed we need some general information from you:

  *   Your date of birth
  *   A mobile phone number (so we can get in touch with you when travelling)
  *   Your T-Shirt size
  *   Do you have any dietary requirements?

Please go through this email several times to ensure you’re answering all 
questions that we ask and please reply in a timely manner.
We’re all doing this in our free time and we’re trying to make this process as 
smooth as possible for all sides.

Summary of what we deed from you now:

  *   Do you accept?
  *   Are you ok with the general dates?
  *   Are you ok with covering the additional nights at the hotel?
  *   Which airports would you be coming from/to?
  *   Your date of birth
  *   A mobile phone number
  *   Your T-Shirt Size
  *   Your dietary requirements

Greetings,
Chris
On behalf of Apache TAC

Next steps for your trip to Bratislava

[Christofer Dutz]

Hi Bryan,

congratulations, you have been chosen to receive sponsoring from the Apache TAC 
program.
We’re looking forward to meeting you at Community over Code Bratislava this 
June.

First, we need you to formally accept your invitation. So … do you accept our 
invitation?

>From what we have on file you have asked for assistance and have been granted:


  *   Travel
  *   Accommodation
  *   Conference Registration

As we will be doing some introduction tasks on Sunday afternoon, were planning 
on getting you to Bratislava on the 01.06.2024.
We are planning on sending you back home on the day after the conference.
However, in some cases we might ask you to stay another day or two or come in 
earlier, if flight costs and connections are a significantly better. Would that 
be ok for you?

We would also need detailed information on the airport we would be booking your 
flights from and to.

To further proceed we need some general information from you:

  *   Your date of birth
  *   A mobile phone number (so we can get in touch with you when travelling)
  *   Your T-Shirt size
  *   Do you have any dietary requirements?

Please go through this email several times to ensure you’re answering all 
questions that we ask and please reply in a timely manner.
We’re all doing this in our free time and we’re trying to make this process as 
smooth as possible for all sides.

Summary of what we deed from you now:

  *   Do you accept?
  *   Are you ok with the general dates?
  *   Which airports would you be coming from/to?
  *   Your date of birth
  *   A mobile phone number
  *   Your T-Shirt Size
  *   Your dietary requirements

Greetings,
Chris
On behalf of Apache TAC

Next steps for your trip to Bratislava

[Christofer Dutz]

Hi Christopher,

congratulations, you have been chosen to receive sponsoring from the Apache TAC 
program.
We’re looking forward to meeting you at Community over Code Bratislava this 
June.

First, we need you to formally accept your invitation. So … do you accept our 
invitation?

>From what we have on file you have asked for assistance and have been granted:


  *   Travel
  *   Accommodation
  *   Conference Registration

As we will be doing some introduction tasks on Sunday afternoon, were planning 
on getting you to Bratislava on the 01.06.2024.
We are planning on sending you back home on the day after the conference.
However, in some cases we might ask you to stay another day or two or come in 
earlier, if flight costs and connections are a significantly better. Would that 
be ok for you?

We would also need detailed information on the airport we would be booking your 
flights from and to.

To further proceed we need some general information from you:

  *   Your date of birth
  *   A mobile phone number (so we can get in touch with you when travelling)
  *   Your T-Shirt size
  *   Do you have any dietary requirements?

Please go through this email several times to ensure you’re answering all 
questions that we ask and please reply in a timely manner.
We’re all doing this in our free time and we’re trying to make this process as 
smooth as possible for all sides.

Summary of what we deed from you now:

  *   Do you accept?
  *   Are you ok with the general dates?
  *   Which airports would you be coming from/to?
  *   Your date of birth
  *   A mobile phone number
  *   Your T-Shirt Size
  *   Your dietary requirements

Greetings,
Chris
On behalf of Apache TAC

Next steps for your trip to Bratislava

[Christofer Dutz]

Hi Muhammed,

congratulations, you have been chosen to receive sponsoring from the Apache TAC 
program.
We’re looking forward to meeting you at Community over Code Bratislava this 
June.

First, we need you to formally accept your invitation. So … do you accept our 
invitation?

>From what we have on file you have asked for assistance and have been granted:


  *   Conference Registration

As we will be doing some introduction tasks on Sunday afternoon, would need you 
to participate on Sunday 02.06.2024 would you be able to do this?

To further proceed we need some general information from you:

  *   Your T-Shirt size
  *   Do you have any dietary requirements?

Please go through this email several times to ensure you’re answering all 
questions that we ask and please reply in a timely manner.
We’re all doing this in our free time and we’re trying to make this process as 
smooth as possible for all sides.

Summary of what we deed from you now:

  *   Do you accept?
  *   Are you ok with the general dates?
  *   Your T-Shirt Size
  *   Your dietary requirements

Greetings,
Chris
On behalf of Apache TAC

AW: We need to work on some of the basics ... and I could use your help with that.

[Christofer Dutz]

Hi Cesar,

sure … feel free to give it a shot.


Chris


Von: Cesar Garcia 
Datum: Dienstag, 27. Februar 2024 um 11:43
An: dev@plc4x.apache.org 
Betreff: Re: We need to work on some of the basics ... and I could use your 
help with that.
Good day,

For the approach you make for PLC4X frontend, I proposed "qooxdoo". I have
been testing the new version and we can definitely get results very
quickly. It is pure JavaScript, nothing to do with NetBeans.

In the case of NetBeans Platform, the integration with PLC4X, I see it for
final applications, and very specific solutions. We cannot cover all
scenarios with web applications. And I would propose it for the
"plc4j/integration" section.

If you agree, I can take a few steps with qooxdoo, and we will evaluate it
to present it to the work team.

I'm going to get a coffee,

Have a great day,

Kind regards,

El mar, 27 feb 2024 a las 4:32, Christofer Dutz ()
escribió:

> Hi Cesar,
>
> Having had a look at https://qooxdoo.org/ … it seems as this is a
> web-framework not at all linked with NetBeans. So, do you propose to use
> that or a NetBeans GUI?
>
> Chris
>
> Von: Cesar Garcia 
> Datum: Montag, 26. Februar 2024 um 15:14
> An: dev@plc4x.apache.org 
> Betreff: Re: We need to work on some of the basics ... and I could use
> your help with that.
> Hello,
>
> Reading your email while having a coffee, what comes to mind is a word
> "time".
>
> I can remember that I followed up on the way Woodhead (Applicom) cards work
> and definitely before the request they have an optimizer, but they achieve
> this by creating a model of the device as an intermediate layer, which will
> plan the requests.
>
> The poorest implementation of a driver, I could see a communication with
> Modbus of a Simenes MP277, horrible!
>
> There are some papers like [1] that attack this problem, it would be
> interesting for the work team to debate how to implement an "optimizer +
> scheduler", which would solve two of the problems you raise.
>
> The interesting thing here is how to maintain a unified architecture
> between the versions of C and Java, which are the ones I can evaluate.
>
> My proposal for visualization follows the same line, we continue working
> with Apache NetBeans Platform for relatively complex applications, and web
> visualization with "qooxdoo" [2].
>
> Why I propose "qooxdoo", because of its simplicity, we don't want to learn
> a lot of React, Typescript, css, etc.
>
> To make a simple functional table, qooxdoo's implementation of a table is
> the best I've tried [3].
>
> The integration of qooxdoo with Apache ECharts [4] is pure magic.
>
> The best thing, qooxdoo + ECharts V4, works with old equipment that we
> still find in some industries (yes, Windows XP is still used).
>
> I would just add to the list, PLC4X driver as a service. In this case
> supported by Apache Karaf and Apache Celix.
>
> Uhs, I'm out of coffee,
>
> My grain of sand,
>
> Have an excellent day.
>
>
> 1.
>
> https://www.researchgate.net/publication/332657959_Dynamic_Optimization_of_Data_Packet-based_Communication_for_PLC_Visual_Monitoring
> 2. https://qooxdoo.org/
> 3. https://qooxdoo.org/qxl.demobrowser/#table~Table.html
> 4. https://echarts.apache.org/en/index.html
>
> El lun, 26 feb 2024 a las 5:17, Christofer Dutz (<
> christofer.d...@c-ware.de>)
> escribió:
>
> > Hi all,
> >
> > So, we now have more and more drivers in more and more languages and are
> > seeing that this is becoming a bit of a problem, as it’s difficult to
> keep
> > all of them aligned.
> > It was always my plan to work on this by extremely increasing the portion
> > of generated code.
> >
> > The problem is that there is also stuff that needs doing to promote the
> > project (Our users are asking for more drivers, better integrations,
> > bugfixes etc.)
> > I personally see that we need the following features:
> >
> > - A general purpose Request-Optimizer, that rewrites requests and
> possibly
> > splits them up
> > - A rewrite of the scraper
> > - A general purpose “subscription emulator” that allows using the
> > subscription API with connections only allowing reads
> > - A general purpose UI that allows interacting with PLCs using PLC4X in a
> > graphical way.
> >
> > However, you can imagine, that I can’t do all of that on my own,
> > especially as I unfortunately no longer can work on this sort of things
> > full-time as part of my day job.
> > So, I’m mostly relying on rainy weekends and dark and rainy evenings.
> >
> > My question to you all: Anyone willing to 

AW: We need to work on some of the basics ... and I could use your help with that.

[Christofer Dutz]

And regarding my plans on extending the code generation.
That’s generally multiple steps … each one generating more parts of the code:


  *   Message Templates: Here we use the same syntax we used for defining 
test-messages, but can use placeholders “${someVariable}” instead of fixed 
values and it generates a factory method that takes all placeholders as 
arguments which can be used to “createConnectionRequest(param1, param2)”
  *   Message Interactions: Here we use Message Templates to produce a message, 
but also declare what we consider to be a response. This would generate the 
sendRequest and expectResponse parts. So, an interaction would be something 
like: “sendConnectionRequest(param1, param2, response -> {code handling the 
response})”. I would consider the input to such a definition being also in XML, 
but having a set of expressions, which describe what we currently do in code.
  *   I have already started writing down some of the general state-machine 
descriptions for the documentation. The general Idea of the third step would be 
to have a state-machine description and use the Message Interactions as 
transitions from one state to the other.

All of this won’t fully generate the drivers, but it would get us a lot further 
and the manual labor of implementing a driver would be a lot less.

So much for my ideas ;-)

Chris

Von: Christofer Dutz 
Datum: Dienstag, 27. Februar 2024 um 09:32
An: dev@plc4x.apache.org 
Betreff: AW: We need to work on some of the basics ... and I could use your 
help with that.
Hi Cesar,

Having had a look at https://qooxdoo.org/ … it seems as this is a web-framework 
not at all linked with NetBeans. So, do you propose to use that or a NetBeans 
GUI?

Chris

Von: Cesar Garcia 
Datum: Montag, 26. Februar 2024 um 15:14
An: dev@plc4x.apache.org 
Betreff: Re: We need to work on some of the basics ... and I could use your 
help with that.
Hello,

Reading your email while having a coffee, what comes to mind is a word
"time".

I can remember that I followed up on the way Woodhead (Applicom) cards work
and definitely before the request they have an optimizer, but they achieve
this by creating a model of the device as an intermediate layer, which will
plan the requests.

The poorest implementation of a driver, I could see a communication with
Modbus of a Simenes MP277, horrible!

There are some papers like [1] that attack this problem, it would be
interesting for the work team to debate how to implement an "optimizer +
scheduler", which would solve two of the problems you raise.

The interesting thing here is how to maintain a unified architecture
between the versions of C and Java, which are the ones I can evaluate.

My proposal for visualization follows the same line, we continue working
with Apache NetBeans Platform for relatively complex applications, and web
visualization with "qooxdoo" [2].

Why I propose "qooxdoo", because of its simplicity, we don't want to learn
a lot of React, Typescript, css, etc.

To make a simple functional table, qooxdoo's implementation of a table is
the best I've tried [3].

The integration of qooxdoo with Apache ECharts [4] is pure magic.

The best thing, qooxdoo + ECharts V4, works with old equipment that we
still find in some industries (yes, Windows XP is still used).

I would just add to the list, PLC4X driver as a service. In this case
supported by Apache Karaf and Apache Celix.

Uhs, I'm out of coffee,

My grain of sand,

Have an excellent day.


1.
https://www.researchgate.net/publication/332657959_Dynamic_Optimization_of_Data_Packet-based_Communication_for_PLC_Visual_Monitoring
2. https://qooxdoo.org/
3. https://qooxdoo.org/qxl.demobrowser/#table~Table.html
4. https://echarts.apache.org/en/index.html

El lun, 26 feb 2024 a las 5:17, Christofer Dutz ()
escribió:

> Hi all,
>
> So, we now have more and more drivers in more and more languages and are
> seeing that this is becoming a bit of a problem, as it’s difficult to keep
> all of them aligned.
> It was always my plan to work on this by extremely increasing the portion
> of generated code.
>
> The problem is that there is also stuff that needs doing to promote the
> project (Our users are asking for more drivers, better integrations,
> bugfixes etc.)
> I personally see that we need the following features:
>
> - A general purpose Request-Optimizer, that rewrites requests and possibly
> splits them up
> - A rewrite of the scraper
> - A general purpose “subscription emulator” that allows using the
> subscription API with connections only allowing reads
> - A general purpose UI that allows interacting with PLCs using PLC4X in a
> graphical way.
>
> However, you can imagine, that I can’t do all of that on my own,
> especially as I unfortunately no longer can work on this sort of things
> full-time as part of my day job.
> So, I’m mostly relying on

AW: We need to work on some of the basics ... and I could use your help with that.

[Christofer Dutz]

Hi Cesar,

Having had a look at https://qooxdoo.org/ … it seems as this is a web-framework 
not at all linked with NetBeans. So, do you propose to use that or a NetBeans 
GUI?

Chris

Von: Cesar Garcia 
Datum: Montag, 26. Februar 2024 um 15:14
An: dev@plc4x.apache.org 
Betreff: Re: We need to work on some of the basics ... and I could use your 
help with that.
Hello,

Reading your email while having a coffee, what comes to mind is a word
"time".

I can remember that I followed up on the way Woodhead (Applicom) cards work
and definitely before the request they have an optimizer, but they achieve
this by creating a model of the device as an intermediate layer, which will
plan the requests.

The poorest implementation of a driver, I could see a communication with
Modbus of a Simenes MP277, horrible!

There are some papers like [1] that attack this problem, it would be
interesting for the work team to debate how to implement an "optimizer +
scheduler", which would solve two of the problems you raise.

The interesting thing here is how to maintain a unified architecture
between the versions of C and Java, which are the ones I can evaluate.

My proposal for visualization follows the same line, we continue working
with Apache NetBeans Platform for relatively complex applications, and web
visualization with "qooxdoo" [2].

Why I propose "qooxdoo", because of its simplicity, we don't want to learn
a lot of React, Typescript, css, etc.

To make a simple functional table, qooxdoo's implementation of a table is
the best I've tried [3].

The integration of qooxdoo with Apache ECharts [4] is pure magic.

The best thing, qooxdoo + ECharts V4, works with old equipment that we
still find in some industries (yes, Windows XP is still used).

I would just add to the list, PLC4X driver as a service. In this case
supported by Apache Karaf and Apache Celix.

Uhs, I'm out of coffee,

My grain of sand,

Have an excellent day.


1.
https://www.researchgate.net/publication/332657959_Dynamic_Optimization_of_Data_Packet-based_Communication_for_PLC_Visual_Monitoring
2. https://qooxdoo.org/
3. https://qooxdoo.org/qxl.demobrowser/#table~Table.html
4. https://echarts.apache.org/en/index.html

El lun, 26 feb 2024 a las 5:17, Christofer Dutz ()
escribió:

> Hi all,
>
> So, we now have more and more drivers in more and more languages and are
> seeing that this is becoming a bit of a problem, as it’s difficult to keep
> all of them aligned.
> It was always my plan to work on this by extremely increasing the portion
> of generated code.
>
> The problem is that there is also stuff that needs doing to promote the
> project (Our users are asking for more drivers, better integrations,
> bugfixes etc.)
> I personally see that we need the following features:
>
> - A general purpose Request-Optimizer, that rewrites requests and possibly
> splits them up
> - A rewrite of the scraper
> - A general purpose “subscription emulator” that allows using the
> subscription API with connections only allowing reads
> - A general purpose UI that allows interacting with PLCs using PLC4X in a
> graphical way.
>
> However, you can imagine, that I can’t do all of that on my own,
> especially as I unfortunately no longer can work on this sort of things
> full-time as part of my day job.
> So, I’m mostly relying on rainy weekends and dark and rainy evenings.
>
> My question to you all: Anyone willing to help take any of this off my
> plate?
>
> 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
*

AW: We need to work on some of the basics ... and I could use your help with that.

[Christofer Dutz]

Hi Cesar,

Well, I guess for a general purpose we’d have to come up with general 
functionality for some things like:

  *   Size of a base request (no items)
  *   Size of a base response (no items)
  *   Size of a request item
  *   Size of a response item
With this and a given request and max pdu-size, we should be able to build a 
general-purpose optimizer, that produces a sequence of requests, that utilize 
the PDU size.

What I built for S7, simply keeps on checking: “does it work, if I add this 
item?” … as soon as it doesn’t it finishes the first request and starts a new 
one. This doesn’t make use of possibly re-arranging items to better fill PDUs, 
which should also be pretty general purpose.

The next step would be one that is able to apply protocol-dependent 
optimizations. Like … if I read 10 boolean values, it might be better to read 
an array of bytes instead, as the overhead is a lot less. I could imagine that 
such an optimizer would be pretty much like a rule engine.

I have no objections if anyone wants to build a UI tool with some other 
technology. I’m not overwhelmed when I hear “Netbeans”, as I remember that is 
built by an ANT build from hell … pretty much on one level with all the Eclipse 
stuff that uses Tycho to build and you essentially have to build it in an 
Eclipse IDE. I would not be willing to buy easy implementation of tables by 
inheriting a nightmare of a build.

If you could whip up a PR with such an editor (doesn’t have to be much more 
than what I have in React). I guess that would be something we could be 
discussing over.

I just thought: If I must learn something new, I might as well learn something 
I might be benefiting from in my future carrier. And I was expecting more 
people to be able to join in with React compared to any other UI framework.

I’d love if this thing would become backed by a community that is able to 
sustain it. Nothing that someone built and then I have to maintain it.


Chris


Von: Cesar Garcia 
Datum: Montag, 26. Februar 2024 um 15:14
An: dev@plc4x.apache.org 
Betreff: Re: We need to work on some of the basics ... and I could use your 
help with that.
Hello,

Reading your email while having a coffee, what comes to mind is a word
"time".

I can remember that I followed up on the way Woodhead (Applicom) cards work
and definitely before the request they have an optimizer, but they achieve
this by creating a model of the device as an intermediate layer, which will
plan the requests.

The poorest implementation of a driver, I could see a communication with
Modbus of a Simenes MP277, horrible!

There are some papers like [1] that attack this problem, it would be
interesting for the work team to debate how to implement an "optimizer +
scheduler", which would solve two of the problems you raise.

The interesting thing here is how to maintain a unified architecture
between the versions of C and Java, which are the ones I can evaluate.

My proposal for visualization follows the same line, we continue working
with Apache NetBeans Platform for relatively complex applications, and web
visualization with "qooxdoo" [2].

Why I propose "qooxdoo", because of its simplicity, we don't want to learn
a lot of React, Typescript, css, etc.

To make a simple functional table, qooxdoo's implementation of a table is
the best I've tried [3].

The integration of qooxdoo with Apache ECharts [4] is pure magic.

The best thing, qooxdoo + ECharts V4, works with old equipment that we
still find in some industries (yes, Windows XP is still used).

I would just add to the list, PLC4X driver as a service. In this case
supported by Apache Karaf and Apache Celix.

Uhs, I'm out of coffee,

My grain of sand,

Have an excellent day.


1.
https://www.researchgate.net/publication/332657959_Dynamic_Optimization_of_Data_Packet-based_Communication_for_PLC_Visual_Monitoring
2. https://qooxdoo.org/
3. https://qooxdoo.org/qxl.demobrowser/#table~Table.html
4. https://echarts.apache.org/en/index.html

El lun, 26 feb 2024 a las 5:17, Christofer Dutz ()
escribió:

> Hi all,
>
> So, we now have more and more drivers in more and more languages and are
> seeing that this is becoming a bit of a problem, as it’s difficult to keep
> all of them aligned.
> It was always my plan to work on this by extremely increasing the portion
> of generated code.
>
> The problem is that there is also stuff that needs doing to promote the
> project (Our users are asking for more drivers, better integrations,
> bugfixes etc.)
> I personally see that we need the following features:
>
> - A general purpose Request-Optimizer, that rewrites requests and possibly
> splits them up
> - A rewrite of the scraper
> - A general purpose “subscription emulator” that allows using the
> subscription API with connections only allowing reads
> - A general purpose UI that allows interacting with PLCs usi

We need to work on some of the basics ... and I could use your help with that.

[Christofer Dutz]

Hi all,

So, we now have more and more drivers in more and more languages and are seeing 
that this is becoming a bit of a problem, as it’s difficult to keep all of them 
aligned.
It was always my plan to work on this by extremely increasing the portion of 
generated code.

The problem is that there is also stuff that needs doing to promote the project 
(Our users are asking for more drivers, better integrations, bugfixes etc.)
I personally see that we need the following features:

- A general purpose Request-Optimizer, that rewrites requests and possibly 
splits them up
- A rewrite of the scraper
- A general purpose “subscription emulator” that allows using the subscription 
API with connections only allowing reads
- A general purpose UI that allows interacting with PLCs using PLC4X in a 
graphical way.

However, you can imagine, that I can’t do all of that on my own, especially as 
I unfortunately no longer can work on this sort of things full-time as part of 
my day job.
So, I’m mostly relying on rainy weekends and dark and rainy evenings.

My question to you all: Anyone willing to help take any of this off my plate?

Chris

[ANNOUNCE] Apache PLC4X 0.12.0 released

[Christofer Dutz]

The Apache PLC4X team is pleased to announce the release of Apache PLC4X 0.12.0

PLC4X is a set of libraries for communicating with industrial programmable
logic controllers (PLCs) using a variety of protocols but with a shared API.

This release was mainly a release containing many bugfixes. We
literally halved the number of open issues. A second major topic would
have been another API streamlining in preparation for the big 1.0.0
release.

The API was extended by additional features, that now allow tools to
automatically provide support for tool assist when connecting to
devices. Now additional information such as:
 - Which transports does a given driver support?
 - Which is the default transport for a given driver?
 - Which configuration-options does a driver have?
 - What types are these configuration options?
 - What are the default-values these configuration options have?
 - Which of these configuration options are required?
 - The same set of information is also available for the transports a
driver is using.

Especially the S7, Modbus and OPC-UA drivers received the most
bugfixes and improvements.
S7 now supports all supported S7 datatypes. Modbus should now also
work in Serial modes. OPC-UA now supports certificate based
communication.

Visit the Apache PLC4X website [1] for general information or
the downloads page [2] for release notes and download information.

Regards,
The Apache PLC4X team

[1] http://plc4x.apache.org
[2] http://plc4x.apache.org/users/download.html

[RESULT][VOTE] Apache PLC4X 0.12.0 RC2

[Christofer Dutz]

Ok … so the vote passes with 3 binding +1 votes and no other votes.

:-)

Von: Ben Hutcheson 
Datum: Sonntag, 18. Februar 2024 um 05:53
An: dev@plc4x.apache.org 
Betreff: Re: [VOTE] Apache PLC4X 0.12.0 RC2
+1 (binding)

The header for this release in RELEASE_NOTES should probably be just 0.12
instead of the SNAPSHOT version.

[x] Download all staged artifacts under the url specified in the release
vote email.
[x] Verify the signature is correct.
[x] Check if the signature references an Apache email address.
[x] Verify the SHA512 hashes.
[x] Unzip the archive.
[x] Verify the existence of LICENSE, NOTICE, README, RELEASE_NOTES files in
the extracted source bundle.
[x] Verify the content of LICENSE, NOTICE, README, RELEASE_NOTES files in
the extracted source bundle.
[x] [RM] Verify the staged source README, RELEASE_NOTE files correspond to
those in the extracted source bundle.
[x] [RM] Run RAT externally to ensure there are no surprises.
[x] Search for SNAPSHOT references
[x] Build the project according to the information in the README.md file.


On Fri, Feb 16, 2024 at 7:27 PM Lukas Ott  wrote:

> +1 (binding)
>
> Lukas - otluk
>
> [x] Download all staged artifacts under the url specified in the release
> vote email.
> [x] Verify the signature is correct.
> [x] Check if the signature references an Apache email address.
> [x] Verify the SHA512 hashes.
> [x] Unzip the archive.
> [x] Verify the existence of LICENSE, NOTICE, README, RELEASE_NOTES files in
> the extracted source bundle.
> [x] Verify the content of LICENSE, NOTICE, README, RELEASE_NOTES files in
> the extracted source bundle.
> [x] [RM] Verify the staged source README, RELEASE_NOTE files correspond to
> those in the extracted source bundle.
> [x] [RM] Run RAT externally to ensure there are no surprises.
> [x] Search for SNAPSHOT references
> [x] Build the project according to the information in the README.md file.
>
> Built with: ./mvnw -P
>
> with-c,with-dotnet,with-java,with-python,with-sandbox,enable-all-checks,update-generated-code
> install -X
>
> OS: Linux Mint 21.3 x86_64
> Kernel: 6.5.0-18-generic
> openjdk version "11.0.21" 2023-10-17
> OpenJDK Runtime Environment (build 11.0.21+9-post-Ubuntu-0ubuntu122.04)
> OpenJDK 64-Bit Server VM (build 11.0.21+9-post-Ubuntu-0ubuntu122.04, mixed
> mode, sharing)
> .NET - SDK-Version: 8.0.102
> Python 3.10.12
>
> Am Fr., 16. Feb. 2024 um 18:09 Uhr schrieb Christofer Dutz <
> christofer.d...@c-ware.de>:
>
> > Apache PLC4X 0.13.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: v0.12.0
> > Hash for the release tag: 47af22589818dc83c274dd6299449ec1a36f8fae
> >
> > 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-1054
> > [2] https://dist.apache.org/repos/dist/dev/plc4x/0.12.0/rc2
> > [3] https://www.apache.org/dev/release.html#approving-a-release
> > [4]
> >
> https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release
> >
> >
>

AW: [VOTE] Apache PLC4X 0.12.0 RC2

[Christofer Dutz]

+1 (binding)

Chris

[OK] Download all staged artifacts under the url specified in the release vote 
email.
[OK] Verify the signature is correct.
[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 references in disabled code-blocks and modules.
[OK] Search for Copyright references, and if they are in headers, make sure 
these files containing them are mentioned in the LICENSE file.
[OK] Build the project according to the information in the README.md file.
[OK] [RM] Build the project with all with-xyz profiles and tests enabled and an 
empty maven local repo.


Von: Christofer Dutz 
Datum: Freitag, 16. Februar 2024 um 18:10
An: dev@plc4x.apache.org 
Betreff: [VOTE] Apache PLC4X 0.12.0 RC2
Apache PLC4X 0.13.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: v0.12.0
Hash for the release tag: 47af22589818dc83c274dd6299449ec1a36f8fae

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

[VOTE] Apache PLC4X 0.12.0 RC2

[Christofer Dutz]

Apache PLC4X 0.13.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: v0.12.0
Hash for the release tag: 47af22589818dc83c274dd6299449ec1a36f8fae

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

[DISCUSS] Apache PLC4X 0.12.0 RC2

[Christofer Dutz]

This is the discussion thread for the corresponding VOTE thread.

Please keep discussions in this thread to simplify the counting of votes.

If you have to vote -1 please mention a brief description on why and then take 
the details to this thread.

[CANCELED][VOTE] Apache PLC4X 0.12.0 RC1

[Christofer Dutz]

Found an issue … will fix it and stage an RC2

Chris

Von: Christofer Dutz 
Datum: Freitag, 16. Februar 2024 um 14:54
An: dev@plc4x.apache.org 
Betreff: AW: [VOTE] Apache PLC4X 0.12.0 RC1
-1 (binding)

Chris

[OK] Download all staged artifacts under the url specified in the release vote 
email.
[OK] Verify the signature is correct.
[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.
[MINOR] Verify the content of LICENSE, NOTICE, README, RELEASE_NOTES files in 
the extracted source bundle.

  *   It turns out the “build with everything” statement needs an additional 
“update-generated-code” profile to really build everything.
[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.
[FAIL] Search for SNAPSHOT references

  *   It seems the code-generation tests were not run during the release and 
therefore the artifacts there were not updated :-/
[OK] Search for Copyright references, and if they are in headers, make sure 
these files containing them are mentioned in the LICENSE file.
[-] Build the project according to the information in the README.md file.
[-] [RM] Build the project with all with-xyz profiles and tests enabled and an 
empty maven local repo.


Von: Christofer Dutz 
Datum: Freitag, 16. Februar 2024 um 13:58
An: dev@plc4x.apache.org 
Betreff: [VOTE] Apache PLC4X 0.12.0 RC1
Apache PLC4X 0.12.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: v0.12.0
Hash for the release tag: 90fc8c00de051abcad2789d7622c8d497209def4

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-1052
[2] https://dist.apache.org/repos/dist/dev/plc4x/0.12.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: [VOTE] Apache PLC4X 0.12.0 RC1

[Christofer Dutz]

-1 (binding)

Chris

[OK] Download all staged artifacts under the url specified in the release vote 
email.
[OK] Verify the signature is correct.
[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.
[MINOR] Verify the content of LICENSE, NOTICE, README, RELEASE_NOTES files in 
the extracted source bundle.

  *   It turns out the “build with everything” statement needs an additional 
“update-generated-code” profile to really build everything.
[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.
[FAIL] Search for SNAPSHOT references

  *   It seems the code-generation tests were not run during the release and 
therefore the artifacts there were not updated :-/
[OK] Search for Copyright references, and if they are in headers, make sure 
these files containing them are mentioned in the LICENSE file.
[-] Build the project according to the information in the README.md file.
[-] [RM] Build the project with all with-xyz profiles and tests enabled and an 
empty maven local repo.


Von: Christofer Dutz 
Datum: Freitag, 16. Februar 2024 um 13:58
An: dev@plc4x.apache.org 
Betreff: [VOTE] Apache PLC4X 0.12.0 RC1
Apache PLC4X 0.12.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: v0.12.0
Hash for the release tag: 90fc8c00de051abcad2789d7622c8d497209def4

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-1052
[2] https://dist.apache.org/repos/dist/dev/plc4x/0.12.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: [DISCUSS] Apache PLC4X 0.12.0 RC1

[Christofer Dutz]

Hi all,

this release was the first done by the scripts in “tools”. With this I am 
trying to make releasing easier and to make it harder for RMs to miss things.
However, the probably major difference is that the final 
release:perform-release step is executed in a Docker-container, which should 
make the build fully reproducible.
I am planning on building some additional tooling, that allows people to 
validate releases additionally by downloading the content of the staging repo 
and doing binary comparisons with what’s built from the local sources.
Also, could people download our releases and run the script and compare that 
what they are using in the company is binary identical what they would build 
locally.

I think that’s going to be pretty cool.

Happy voting … I would love to release the release on Tuesday, so please do me 
a favor and plan in some time for voting. Ideally as soon as possible, so we 
could possibly have a bit more time, in case an RC2 is needed, as I would love 
to have the release out the door before Building IoT Conference next week and 
to have our website in-line with the currently latest released version as soon 
as possible.

Chris

Von: Christofer Dutz 
Datum: Freitag, 16. Februar 2024 um 13:59
An: dev@plc4x.apache.org 
Betreff: [DISCUSS] Apache PLC4X 0.12.0 RC1
This is the discussion thread for the corresponding VOTE thread.

Please keep discussions in this thread to simplify the counting of votes.

If you have to vote -1 please mention a brief description on why and then take 
the details to this thread.

[DISCUSS] Apache PLC4X 0.12.0 RC1

[Christofer Dutz]

This is the discussion thread for the corresponding VOTE thread.

Please keep discussions in this thread to simplify the counting of votes.

If you have to vote -1 please mention a brief description on why and then take 
the details to this thread.

[VOTE] Apache PLC4X 0.12.0 RC1

[Christofer Dutz]

Apache PLC4X 0.12.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: v0.12.0
Hash for the release tag: 90fc8c00de051abcad2789d7622c8d497209def4

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-1052
[2] https://dist.apache.org/repos/dist/dev/plc4x/0.12.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: Re-generated Generated Sources

[Christofer Dutz]

Hi Robert,

happy to help you with that.

In general, I’ll be working on updating the documentation after the next 
release (which I’ll start after finishing this mail)
But for now: We’ve introduced some minor changes to the build, so you’ll need 
to make sure the following maven profiles are enabled:


  *   with-java (Without it, generally nothing java-related will be built at 
all)
  *   update-generated-code (Without it, the code generation will not be 
performed at all)


So, if you run the following command:


./mvnw -Pwith-java,update-generated-code -pl :plc4j-driver-eip -am clean package

It will generally build the java eip driver and all modules it depends on.

Hope that helps and looking forward to some pull-requests ;-)


Chris



Von: R Thayer 
Datum: Freitag, 16. Februar 2024 um 02:25
An: dev@plc4x.apache.org 
Betreff: Re: Re-generated Generated Sources
All,
What is the process to regenerate generated sources?

New to plc4x but have live EIP/CIP traffic that i'm trying to model with the 
eip.mspec and need to close the circle of eip.mspec==>generated-code in the 
plc4j/drivers/eip/src/main/generated to verify correct mspec.  Working through 
ParserSerializerTestsuiteLittleEndian.xml to model MultipleServiceR/R

The website discusses it and suggests "mvn compile".
This thinks it works but does not regenerate nor replace the files.

Thanks,

Robert Thayer
CC Software, Inc.
702-726-1034

[DISCUSS] How about releasing 0.12.0?

[Christofer Dutz]

Hi all,

so in the past few weeks we managed to cut the number of open issues by half 
and merge in all the big running initiatives.

I would really love to have a new version available at Building IoT next week.

What do you think? Should we do a new release?

I would also really love to test the scripts for releasing reproducible builds 
with docker that I whipped up over the last months.

Chris

AW: [DISCUSS] How about registering a profile for ApachePLC4X on LinkedIn?

[Christofer Dutz]

Hi all …

So, as I didn’t hear any objections, I used this weeks “Tuesday morning” slot 
for announcing it.
https://www.linkedin.com/company/apache-plc4x

I also sent out a first post and shared if from my account: 
https://www.linkedin.com/feed/update/urn:li:activity:7160542025086324738/ 
(couldn’t find out how to get the link to the original post as LinkedIn always 
switched to the Admin view)

If anyone on the PMC wants to be invited, please give me a ping.

Chris




Von: Ben Hutcheson 
Datum: Dienstag, 6. Februar 2024 um 09:18
An: dev@plc4x.apache.org 
Betreff: Re: [DISCUSS] How about registering a profile for ApachePLC4X on 
LinkedIn?
Sounds like a decent idea +1

On Sun, Feb 4, 2024 at 12:35 PM Lukas Ott  wrote:

> +1
>
> As we would mainly follow other Apache projects like:
> - https://www.linkedin.com/company/apache-streampipes/
> - https://www.linkedin.com/company/apachespark/
> - https://www.linkedin.com/company/apache-beam/
> - https://www.linkedin.com/company/apache-airflow/
> - https://www.linkedin.com/company/apache-hudi/
> - https://www.linkedin.com/company/apache-nifi/
> - https://www.linkedin.com/company/apache-cassandra/
> - https://www.linkedin.com/company/apachehop/
> - https://www.linkedin.com/showcase/apache-ignite/
> - https://www.linkedin.com/company/apache-couchdb/
> - https://www.linkedin.com/company/apache-apisix/
> - https://www.linkedin.com/company/tinkerpop
>
> Am So., 4. Feb. 2024 um 11:00 Uhr schrieb Christofer Dutz <
> christofer.d...@c-ware.de>:
>
> > Hi all,
> >
> > it seems that LinkedIn have dropped the hashtags … so people interested
> in
> > ApachePLC4X can no longer follow the hashtag.
> > What do you folks think? Should I register an account (setting our
> private
> > list as email address)?
> >
> > I would say: Yes.
> >
> >
> > Chris
> >
>

[DISCUSS] How about registering a profile for ApachePLC4X on LinkedIn?

[Christofer Dutz]

Hi all,

it seems that LinkedIn have dropped the hashtags … so people interested in 
ApachePLC4X can no longer follow the hashtag.
What do you folks think? Should I register an account (setting our private list 
as email address)?

I would say: Yes.


Chris

Re: Question on S7 Siemens PLC possibilities

[Christofer Dutz]

Hi Fred,

I am afraid, that these are two things that are not possible with plc4x. 
Technically it would be possible, but given the fact that plcs are usually 
completely unprotected, in the early days of plc4x, we decided to leave this 
sort of thing out of scope.

Chris

Gesendet von Outlook für Android

From: Fred van Zwieten 
Sent: Saturday, January 27, 2024 8:17:01 AM
To: dev@plc4x.apache.org 
Subject: Question on S7 Siemens PLC possibilities

Hi,

(Disclaimer: I know next to nothing about PLC's..)

My name is Fred van Zwieten. I work for Red Hat and am researching a
question from one of my customers. They operate Siemens S7-1200 PLC's and
have a need to do some remote automation.

The use-cases they are requesting are:

1. Change the PLC Password(s)
2. Upgrade the PLC to a newer firmware version

I came across several automation efforts. Preferably I need a REST API
access over a TCP transport. Customer has a TIA Portal application so
automation through the TIA portal or bypassing the TIA portal are possible.

Is this somehow possible with plc4x?

Thank you!

Regards

Fred Van Zwieten

Senior infrastructure portfolio SSA

Interest in an Apache IoT Track at EclipseCon EU in Mainz (Germany) later this year?

[Christofer Dutz]

Hi folks,

I was contacted by some of my friends in the IoT Space at the Eclipse 
Foundation. 

They are planning this year's EclipseCon to work closer together with the other 
foundations in this space and proposed an Apache IoT Track in paralel to the 
EclipseCon. This will be happening in Mainz in Germany I think 4 weeks before 
Community Over Code NA.

I promised to reach out to the projects I know at Apache that count to the IoT 
space.

I really liked the idea of networking with the other foundation's projects as I 
think this is something happening far too little.

So would you folks be interested in submitting talks and attending such a 
conference?

Also the CFP for CoC EU in Bratislava is only open for a few more days and so 
far the IoT related submissions have been ... let's say ... less than I was 
hoping for. 

So if you folks are planning on submitting: Do your track-chair (me) a favor 
and don't submit on the last day ... it's always a hastle to whip up a schedule 
if you can't do it in an orderly way, but get "shot by what's there" on the 
last day.

Looking forward to feedback,

Chris

AW: Is there a reason we're not deploying "library-udf"?

[Christofer Dutz]

Wrong list .. sorry

Von: Christofer Dutz 
Datum: Donnerstag, 4. Januar 2024 um 11:39
An: dev@plc4x.apache.org 
Betreff: Is there a reason we're not deploying "library-udf"?
Hi all,

while setting up Apache TsFile, I noticed, that we’re excluding “library-udf” 
from SNAPSHOT deployment on Jenkins. Is there a reason for this?

(Always to leave a comment in the code on stuff like that)

Chris

Is there a reason we're not deploying "library-udf"?

[Christofer Dutz]

Hi all,

while setting up Apache TsFile, I noticed, that we’re excluding “library-udf” 
from SNAPSHOT deployment on Jenkins. Is there a reason for this?

(Always to leave a comment in the code on stuff like that)

Chris

[RESULT] [VOTE] Drop Java 1.8 Support

[Christofer Dutz]

So, the vote closes with 6 +1 votes.

Next I’ll update the build to no longer produce Java 8

Chris

Von: Łukasz Dywicki 
Datum: Mittwoch, 13. Dezember 2023 um 11:35
An: dev@plc4x.apache.org , Jinlin Hong 

Betreff: Re: [VOTE] Drop Java 1.8 Support
+1 to drop Java 8 compilation and stick with Java 11 as minimum.

To explain - there are slight differences in java standard library which
make this move not only about bytecode. Its about classpath which will
vary and miss/add some useful parts.

I did use Apache PLC4X initially with some openHAB 2.x bindings which
had to run on Java 1.8.
However, that version of openHAB had its last patch release almost 3
years ago (2.5.12 - January 2021), if we look at 2.5 release itself, it
was conducted on December 2019. It was 5 years ago. The openHAB
community have no plans to maintain this release beyond, and next major
which we baseline at connectorio (3.x) runs on Java 11. Most recent
openHAB release is 4.0 (4.1 about to come this December), both run
exclusively on Java 17.

As you see - other open source projects are done with Java 8 for couple
of years already. We are far behind "bleeding edge".
Looking at the dates - Java 8 was released on 18th March 2014, almost 10
years ago. It is about a time to get one level up, especially that we
effectively reached industry 10 year lifetime. ;-)

Cheers,
Łukasz

On 11.12.2023 07:12, Jinlin Hong wrote:
> +1
>
> Lukas Ott  於 2023年12月11日 週一 下午2:03寫道：
>
>> +1
>>
>> Otto Fowler  schrieb am Mo., 11. Dez. 2023,
>> 04:26:
>>
>>>   +1 binding
>>>
>>> On December 8, 2023 at 9:16:19 AM, Christofer Dutz (
>>> christofer.d...@c-ware.de) wrote:
>>>
>>> Hi all,
>>>
>>> in the past we have settled with requiring Java 11 for building plc4x and
>>> making sure the libraries we build are compatible with Java 1.8.
>>> Now it looks as if some of our libraries are no longer runnable on Java
>> 1.8
>>> and we would need one of the following two options:
>>>
>>>
>>> 1. Re-Enable the animal-sniffer-plugin to ensure binary compatability
>> with
>>> Java 1.8 and fix the location in the code
>>> 2. We officially drop Java 1.8 support
>>>
>>> As we like to vote with “+1” and “-1”, I therefore start this vote as:
>>>
>>> Do we want to officially drop Java 11 support?
>>>
>>> Chris
>>>
>>
>

AW: apache kafka and subscription mode

[Christofer Dutz]

Hi,

Right now, the Kafka connector only supports polling from the data source.
However, for 2024 I have planned to create a completely new scraper component, 
that will also support subscriptions.
So right now, it doesn’t support it, but it’s on the schedule.

Chris


Von: Hamze HAMZE 
Datum: Dienstag, 19. Dezember 2023 um 12:00
An: dev@plc4x.apache.org 
Betreff: apache kafka and subscription mode
Hello together,


Do you know whether it is possible to use the ChangeOfState Subscription mode

at retrieving data from OPCUA by the Apache Kafka Connector?


I have her an example configuration and would like to know how and by which

variable this could be possible.


{
  "name": "PLC4X-OPCUA-Connector",
  "config": {
"connector.class": "org.apache.plc4x.kafka.Plc4xSourceConnector",
"tasks.max": "1",
"default.topic": "PLC_opcua",
"sources.opcua.connectionString": "opcua:tcp://xxx.xxx.xxx.xxx:4840",
"sources.opcua.jobReferences": "L12",
"jobs": "L12",
"jobs.L12.interval":100,
"jobs.L12.fields": "SN18",
"jobs.L12.fields.SN18": "ns=3;s=\"TO\".\"SN18\"",
"transforms": "extractField",
"transforms.extractField.type":
"org.apache.kafka.connect.transforms.ExtractField$Value",
"transforms.extractField.field": "fields",
"key.converter": "org.apache.kafka.connect.json.JsonConverter",
"value.converter": "org.apache.kafka.connect.json.JsonConverter",
"key.converter.schemas.enable": "false",
"value.converter.schemas.enable": "false"
  }
}


Thank you in advance!


--
Mit freundlichen Grüßen / Bien Cordialement / Kind regards / أطيب التحيات

*Hamze HAMZE*
Machine Learning Engineer
+49 (0) 17630004907
hamze.ha...@valeo.com

Valeo Schalter und Sensoren GmbH
Valeostrasse 1 - 86650 - Wemding (GERMANY)
[image: valeo] 
[image: linkedin]  [image: twitter]
 [image: youtube]
 [image: facebook]
 [image: instagram]


Sitz der Gesellschaft: 74321 Bietigheim-Bissingen
Handelsregister: Amtsgericht Stuttgart - HRB 301795
Vorsitzender des Aufsichtsrates: Dr. Andreas Heinrich
Geschäftsführer: Stiv Michael Smudja, Martin Mandry, Pierre-Yves Veltois

*This e-mail message is intended for the internal use of the intended
recipient(s) only.
The information contained herein is confidential/privileged. Its
disclosure or reproduction is strictly prohibited.
If you are not the intended recipient, please inform the sender
immediately, do not disclose it internally or to third parties and
destroy it.

In the course of our business relationship and for business purposes
only, Valeo may need to process some of your personal data.
For more information, please refer to the Valeo Data Protection
Statement and Privacy notice available on Valeo.com
*

--
*This e-mail message is intended for the internal use of the intended
recipient(s) only.
The information contained herein is
confidential/privileged. Its disclosure or reproduction is strictly
prohibited.
If you are not the intended recipient, please inform the sender
immediately, do not disclose it internally or to third parties and destroy
it.

In the course of our business relationship and for business purposes
only, Valeo may need to process some of your personal data.
For more
information, please refer to the Valeo Data Protection Statement and
Privacy notice available on Valeo.com
*

AW: [DRAFT] December board report

[Christofer Dutz]

Ok … report is published,

I added a point about Lukas’ work on the OPC-UA secure-connection part.

Chris

Von: Christofer Dutz 
Datum: Dienstag, 12. Dezember 2023 um 09:10
An: dev@plc4x.apache.org 
Betreff: [DRAFT] December board report
Hi all,

it’s reporting time again … I went through our commit history and tried to 
compile a list of the most noticeable changes.
Could you please have a look if anything is missing?

I’ll post it tomorrow.

Chris

---


# 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.

## Project Status:
Current project status: ongoing with moderate activity
Issues for the board: none

## Membership Data:
Apache PLC4X was founded 2019-04-17 (5 years ago)
There are currently 21 committers and 13 PMC members in this project.
The Committer-to-PMC ratio is roughly 3:2.

Community changes, past quarter:
- No new PMC members. Last addition was César García on 2021-10-01.
- No new committers. Last addition was Jinlin Hong on 2022-11-02.

## Project Activity:
The most noteworthy points for the last 3 months were definitely:
- Our last release after exactly one year (didn't copy+paste that)
- Work on the Profinet Driver
- Initiation of a new Web-Based UI tool
- Major updates in the S7 driver (datatype-handling)
- Work on PLC4PY which now has a first working Modbus driver
- Refactored the way transports are configured
- Prepared the build for reproducible builds
- Multiple Bugfixes

Recent releases:
0.11.0 was released on 2023-10-06.
0.10.0 was released on 2022-10-06.
0.9.1 was released on 2021-09-21.

## Community Health:
While I was a bit worried about activity inside the project in my last
reports, things are looking a bit different now. There's currently plenty
activity on various initiatives.

Following the last release we received a number of new bug-reports and fixes
by new folks. We're definitely not going to wait another year for a new
release.

[DRAFT] December board report

[Christofer Dutz]

Hi all,

it’s reporting time again … I went through our commit history and tried to 
compile a list of the most noticeable changes.
Could you please have a look if anything is missing?

I’ll post it tomorrow.

Chris

---


# 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.

## Project Status:
Current project status: ongoing with moderate activity
Issues for the board: none

## Membership Data:
Apache PLC4X was founded 2019-04-17 (5 years ago)
There are currently 21 committers and 13 PMC members in this project.
The Committer-to-PMC ratio is roughly 3:2.

Community changes, past quarter:
- No new PMC members. Last addition was César García on 2021-10-01.
- No new committers. Last addition was Jinlin Hong on 2022-11-02.

## Project Activity:
The most noteworthy points for the last 3 months were definitely:
- Our last release after exactly one year (didn't copy+paste that)
- Work on the Profinet Driver
- Initiation of a new Web-Based UI tool
- Major updates in the S7 driver (datatype-handling)
- Work on PLC4PY which now has a first working Modbus driver
- Refactored the way transports are configured
- Prepared the build for reproducible builds
- Multiple Bugfixes

Recent releases:
0.11.0 was released on 2023-10-06.
0.10.0 was released on 2022-10-06.
0.9.1 was released on 2021-09-21.

## Community Health:
While I was a bit worried about activity inside the project in my last
reports, things are looking a bit different now. There's currently plenty
activity on various initiatives.

Following the last release we received a number of new bug-reports and fixes
by new folks. We're definitely not going to wait another year for a new
release.

AW: [VOTE] Drop Java 1.8 Support

[Christofer Dutz]

Given the fact that nobody officially admits using PLC4X or what they are using 
it for, we shouldn’t guess that people are using it.
So, I’m in favor of dropping 1.8 support and to focus on the use cases that we 
know of.

I know that some reported issues seem to indicate that some people use 1.8, but 
I have no idea if that’s just for some experiment.

However, some “success stories” being published, definitely would swing my 
vote, but as long as that’s not happening.

+1 on dropping 1.8 support.



Chris


Von: Christofer Dutz 
Datum: Freitag, 8. Dezember 2023 um 15:16
An: dev@plc4x.apache.org 
Betreff: [VOTE] Drop Java 1.8 Support
Hi all,

in the past we have settled with requiring Java 11 for building plc4x and 
making sure the libraries we build are compatible with Java 1.8.
Now it looks as if some of our libraries are no longer runnable on Java 1.8 and 
we would need one of the following two options:


  1.  Re-Enable the animal-sniffer-plugin to ensure binary compatability with 
Java 1.8 and fix the location in the code
  2.  We officially drop Java 1.8 support

As we like to vote with “+1” and “-1”, I therefore start this vote as:

Do we want to officially drop Java 11 support?

Chris