Re: ADS

[Łukasz Dywicki]

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

  

  

Re: opcua

[Łukasz Dywicki]

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

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

[Łukasz Dywicki]

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

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

[Łukasz Dywicki]

Chris,
If you can, please drop links to failed agent executions into this 
thread or github discussion/issue. I'll look at them.
Currently we have a bunch of github actions executed within each build, 
it is quite hard for me to track every failure caused by opcua tests. If 
we will aggregate few in one place I'll look at cause and possible 
solutions.


Best,
Łukasz

On 18.03.2024 13:33, Christofer Dutz wrote:

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

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

[Łukasz Dywicki]

I can add one more:

- Support for OSGi as a potential project runtime.

It is a technology which is still popular for various applications 
running on the edge.
@Cesar, I know you use it, pulling you into thread so you can also share 
your point in this regard.


I do maintain a separate repository [1] with hand written karaf feature 
sets. I do so to avoid large duplication of dependencies between 
drivers, as generated feature sets are quite dumb.
I did it initially to make 0.6 and 0.8 release work with openHAB, after 
seeing recent updates from 0.11 release I think we have most of stuff in 
place to make it work.
One missing concept is a classloader propagation so whole thing would 
work without Aries Spifly in other down stream projects, i.e. openems.


Cheers,
Łukasz

--
[1] https://github.com/ConnectorIO/plc4x-extras/

On 21.03.2024 14:39, Christofer Dutz wrote:

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

Re: AW: UI Branch

[Łukasz Dywicki]

I can throw in one more option - openHAB on top of apache karaf. :)
Its more a question about what you are trying to build. There are 
several approaches out there. openHAB is one, merlot is second, eclipse 
kura is third, openMUC or amplia-iiot (oda) or openems is yet another 
one. Real question is what kind application/system you wish to bring and 
how it differs from others.


I could see also other architecture which would involve websockets, but 
with clean structures defined via i.e. graphql schema. I've made some 
experiments with later one combined with react, to see how hard it works 
together.


Currently I have built amsads and s7 bindings on top of plc4j APIs:
https://docs.connectorio.com/connectorio-addons/3.0.x/index.html

Sources:
https://github.com/connectorio/connectorio-addons

Binaries:
https://repository.connectorio.cloud/#browse/browse:co7io-public-snapshots:org%2Fconnectorio%2Faddons

Cheers,
Łukasz

On 21.03.2024 17:30, bjo...@coding-nexus.com wrote:

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 

   _

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






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

*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César 
García*

*Cel: +58 414-760.98.95*

*Hotline Técnica SIEMENS: 0800 1005080*

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

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

[Łukasz Dywicki]

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

Re: S7 types supporting Subscriptions

[Łukasz Dywicki]

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.

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

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 

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

[Łukasz Dywicki]

Is there an agenda for Eclipse thing? Is it 4 weeks before CoC, their 
preparations are probably ahead of ours..


Best,
Łukasz

On 4.01.2024 14:05, Christofer Dutz wrote:

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

Re: SocketCan J1939 support?

[Łukasz Dywicki]

Hello John,
I think its within the reach, it does depend however on JavaCAN library: 
https://github.com/pschichtel/JavaCAN.
I saw you issued already a query on JavaCAN repository. Once we have a 
data stream available the application layer can be implemented.


Best,
Łukasz

On 2.01.2024 00:22, John Lussmyer wrote:
I'm trying to figure out if PLX4X SocketCan support will work with the 
J1939 variation.


i.e. create a socket like this:

s=socket(PF_CAN,SOCK_DGRAM,CAN_J1939);

If so, anyone have some example code of using the socketcan support?

Re: [VOTE] Drop Java 1.8 Support

[Łukasz Dywicki]

+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

Discovery connections, driver context and related issues

[Łukasz Dywicki]

Hey all,
I've been working recently on security updates started by Patryk prior 
summer. What I have found made me question what would be proper way to 
integrate his changes and also improve quality of code we have in 
PLC4X/PLC4J.


1) Driver context - the driver context is something which we use 
internally in some cases. Interestingly enough its responsibility is not 
clear - in some cases driver context is used to retain some 
configuration options passed by user to driver (s7, partially opcua), in 
others it keeps information obtained during negotiation (knx) or 
read/write cycles (profinet). OPC UA driver attempts to use driver 
context to retain UA server certificate.
2) Discovery connection and connection - we received a bugfix for thread 
leak prior 0.11 release which terminates connections created by plc4j. 
The same fix also caused driver context to get blind (driver context is 
tied to channel). Other fixes changed initialization sequence of drivers 
known up to 0.10 release (call onDiscover, then onConnect) breaking 
discovery of UA server endpoints (onConnect, then onDiscover).


I am writing about these two aspects because they are closely related 
and need a further thought on how we would like to address these. For 
now I do not have any strong opinion beyond necessity to clean up and 
make a clear distinction where SPI/API border is.
The driver context and its use within channel lifecycle from one hand 
makes a lot of sense, context will be tied to connection itself. Yet, it 
causes a requirement for configuration to be mutable (onDiscover, then 
populate driver configuration, then onConnect) - this approach is also 
consistent, because it not only justifies separation of configuration 
from driver context, but also makes it clear that onDiscover cycle can 
always be avoided when extra configuration options appear.
On other hand it might also lead to situations where connection URI with 
all options will get fairly long (imagine x.509 certificate encoded as 
uri parameter) ;-), which is probably fine in 95% of cases.


In terms of connection handling I believe we started with early 
prototype which been working fine, however due to several aspects it 
fall of the supported (tested) code base. Effectively 0.11 opcua driver 
can't a) discover server certificate and b) can't make use of it, 
because it is stored in driver context, because c) driver context is 
being reset between discovery and actual connection.
All this also navigates us to DefaultNettyPlcConnectiona and its 
connect() implementation. To be fair, that thing got a number of 
switches to configure behavior, out of which some are used for tests, 
some are used by specific drivers ie. UA (discovery) or S7 (high 
availability).
To me it feels like we should clarify that part first. If the logic is 
specific to driver it should be held within driver or this driver stack 
configurer, without necessity to have branch logic within SPI/common 
base class. I believe that only this way we will save ourselves from 
headaches. Because driver knows configuration before spinning actual 
connection it could manage connections needed for negotiation/discovery 
and also coordinate their termination.


Looking forward to your comments. In case of no further inputs - I'll 
try move some portions of code back to OPCUA driver and see if it will 
fit there.


Cheers,
Łukasz

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

[Łukasz Dywicki]

I believe it will be affected. Once you disable symbol discovery  driver 
logic breaks because some type mappings are not present.


Best,
Łukasz

On 17.10.2023 14:16, Christofer Dutz wrote:

His PLC is a TC3 device so it shouldn’t be affected by the issue you were 
seeing.

Chris


Von: Łukasz Dywicki 
Datum: Dienstag, 17. Oktober 2023 um 13:57
An: dev@plc4x.apache.org 
Betreff: Re: PLC4X - 0.11.0 - Issue writing value to a Beckhoff PLC using ads 
driver
Hey Chris and Patrick,
I've had a look on ADS driver in context of TC2 and I found that i.e.
subscriptions do not work when initial symbol discovery is disabled
(load-symbol-and-data-type-tables=false).

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

Best,
Łukasz

On 17.10.2023 13:40, Patrick Boisclair wrote:

Hi Chris,

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

The PLC type is a "CX8190 / Standard"

I really appreciate your help on this.



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

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


Hi Patrick,

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

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

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

Chris

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

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

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

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

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

Any information would be grateful.

Thank you very much and best regards.



Patrick Boisclair
Analyste Programmeur Sénior, Automatisation ‑ IoT Senior Analyst Programmer, Automation ‑ IoT 
noovelia.com<https://ca.content.exclaimer.net/?url=https%3A%2F%2Fwww.noovelia.com%2F=8tX2umAPEeuYigAD_7TEDg=8cd6b243492cec11ae720050f28c6d00=Iv95LR45lyPUil_sETs-kbbi-09FQA9SVNo9xy79EyFBb0c4rfAoaU8CIr-BB2O4MlDHT91tJ3AXDpUwKBgFLvH_lMRrX6Qzz78VWBQX0WcgNvP2Kmdr51bWnwRokgS9B3HiswGaGBI3lZkVZLh4D3OOGWPuquBDNBsmCkiOSCcXMathSqDI0eLd1euQg0mzPsylz76W5KuwGrUpUP0olQFuLsORCDtg2xViq4KNzcRSHGBhP90MPnLmGvrSaY5WOoKPMWqedgOx2_W6CITnPxQUPfmo2hEKyXVNDEESmEmYdWkBPRHM72y0DI7O0Y8m5DMM89VPSXtGlNnZIIYv9A=1=4bf374d6-ae40-4614-a370-08df1279dbc0>
[Facebook]<https://ca.content.exclaimer.net/?url=https%3A%2F%2Fwww.facebook.com%2Fnoovelia=8tX2umAPEeuYigAD_7TEDg=8cd6b243492cec11ae720050f28c6d00=ZmF7WktjxTdDuuZQWYc6sGK2yu2_ALLM4NagQa2CaXQ=gA7zQcDvyMqziyTk1NpiqkUs4_KHFoPAPkaxB4RaSUokp9VZJ6ge8O6B_dLVF4ZTG9EqoMY4hyfDyjuTosxrNxVLkg6zGnUwC5AtynhsvqVCdn47JRkX2PhZFduKoN2y9_Cg4zpHF7ua6QxVHUHWk4CRYO2eYxnqh3B4s4EAI3_CkMW8a2ESjipCdSd9oGnOIf4iv0Kd63h1zX1NRM-DDggACNKxZ2CBg6aj9RhboI0cF-tmWhjiCRUC6F3bSXciM1MBPoX5ZgMKmYb56ptGDvzZ08kFzGBePkkHZj0NjEo_vzlOQ5EmHsKDtdhtfKD_cZyzAq05FaudXDdXKWmHrw=1=4bf374d6-ae40-4614-a370-08df1279dbc0>
[LinkedIn]<https://ca.content.exclaimer.net/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fnoovelia=8tX2umAPEeuYigAD_7TEDg=8cd6b243492cec11ae720050f28c6d00=gNvIHZ_qTdPfV59g9Dvb-7S1lYFMf8aJTWYxR5l4oio=DseD1J-zw05mIkCR2-ODxg8DQL69F5g3SbGhVrl-KrhMKZP8V3bSHxUEe06ALzSjjYh5Z2MwhH6ZfpPVT-pGlV2XJaE-XBLRLtbDf9UyUZ_4AKOxdbLUFrV6vx0_svGCemL5JTj7l9ATIyHFzUKxB_F42E77uzDGVvWHKP0JmQvrIo3exdGsbQwHYrVQnSs4RFknVmRWBBcX06t0E8nsxzQ1M4KdHOyUQ3AECUlOsR5I0_kl3MwP3iBdaf-luWK2Ajr3SMxcY_i23ByUv5TFF5HKgOch2j8uYmoUjX3j1DWpsMdo1QykjWXsWS9nCs1T305rTGjhicZzh0epWAwyDg=1=4bf374d6-ae40-4614-a370-08df1279dbc0>
[Vimeo]<https://ca.content.exclaimer.net/?url=https%3A%2F%2Fvi

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

[Łukasz Dywicki]

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


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


Best,
Łukasz

On 17.10.2023 13:40, Patrick Boisclair wrote:

Hi Chris,

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

The PLC type is a "CX8190 / Standard"

I really appreciate your help on this.



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

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


Hi Patrick,

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

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

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

Chris

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

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

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

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

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

Any information would be grateful.

Thank you very much and best regards.



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

Re: [VOTE] Apache PLC4X 0.11.0 RC1

[Łukasz Dywicki]

+1

I've tested ADS with TwinCAT2 and TwinCAT3 (BSD), both work fine.
There are some minor troubles related to TC2 which can be addressed later.

Best,
Łukasz

On 2.10.2023 13:24, Unai Leria wrote:

+1

Built on Linux x86_64

Unai Lería (QuanticPony)

[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] Build the project according to the information in the README.md file.

Re: Convert the Milo-based test suite into one using our integration-test framework?

[Łukasz Dywicki]

Hello,
I don't mind having separate profile for milo based tests, we actually 
have some conditional activators in these (i.e. system kind for 
OpcuaPlcDriverTest), switching to profile will simplify control over these.
If ever these tests become stable enough we can re-consider switching 
profile to be active by default.


Cheers,
Łukasz

On 25.09.2023 13:00, Lukas Ott wrote:

+1 for disabling Milo, we should be able to build with docker compose up
without running into these issues.

If someone needs Milo test then actively enabling them seems like a
reasonable plan.

Lukad

Christofer Dutz  schrieb am Mo., 25. Sept. 2023,
10:59:


Hi Lukasz,

Well … we need a test-suite that runs reliably … in the past I usually ran
into issues with Milo not running on various configurations.
Admittedly I’m just no longer willing to invest the little time into
fixing issues with this bit of software.

For example, running “docker compose up” currently fails because in docker
something seems to fail to startup, which doesn’t fail when running on the
hardware directly.

I’m happy for a profile “option-with-milo-tests” that actively enables
Milo-based tests.
(I would insist on actively enabling it instead of actively disabling it
as otherwise people will continuously report problems with it)

Chris



Von: Łukasz Dywicki 
Datum: Montag, 25. September 2023 um 10:49
An: dev@plc4x.apache.org 
Cc: Patryk Gała 
Betreff: Re: Convert the Milo-based test suite into one using our
integration-test framework?
Milo is a bit painful, but it does more than we currently can do in our
opcua implementation. Also, from basic look I had into why some of tests
fail, it looks primarily like resource lookup issue. For example I
spotted a swallowed null pointer exception which comes from our code,
not Milo.

We will have difficult times making test framework for testing security
with certificates and Java crypto apis. Please hold on with major
changes in this area, as we intend using it to automate testing of UA
security policies (sign, sing) using various modes (basic rsa,
basic aes etc.).
Back then Patryk had an idea of making a "test container" for Milo which
would separate it into its own process. Obviously it will need a bit of
work and will become a prerequisite to eventual test refactoring,
however it will make it (fail) same way for everyone. ;)

Best,
Łukasz

On 25.09.2023 10:38, Christofer Dutz wrote:

Hi all,

I know that I have spent many days tracking down oddness of problem with

OPC-UA tests, that all tracked down to Milo behaving oddly on various
platforms (Doesn#t start in Parallells VMs, has issues being run in docker,
…).

When building PLC4X I put a lot of effort into our integration-test

framework, which should allow testing our drivers on various platforms and
languages without needing a real (or simulated) device.


I think we should translate the Milo based tests into ones using our

DriverTestsuite framework, as admittedly I’m fedup with Milo …



Chris

Re: Convert the Milo-based test suite into one using our integration-test framework?

[Łukasz Dywicki]

Milo is a bit painful, but it does more than we currently can do in our 
opcua implementation. Also, from basic look I had into why some of tests 
fail, it looks primarily like resource lookup issue. For example I 
spotted a swallowed null pointer exception which comes from our code, 
not Milo.


We will have difficult times making test framework for testing security 
with certificates and Java crypto apis. Please hold on with major 
changes in this area, as we intend using it to automate testing of UA 
security policies (sign, sing) using various modes (basic rsa, 
basic aes etc.).
Back then Patryk had an idea of making a "test container" for Milo which 
would separate it into its own process. Obviously it will need a bit of 
work and will become a prerequisite to eventual test refactoring, 
however it will make it (fail) same way for everyone. ;)


Best,
Łukasz

On 25.09.2023 10:38, Christofer Dutz wrote:

Hi all,

I know that I have spent many days tracking down oddness of problem with OPC-UA 
tests, that all tracked down to Milo behaving oddly on various platforms 
(Doesn#t start in Parallells VMs, has issues being run in docker, …).
When building PLC4X I put a lot of effort into our integration-test framework, 
which should allow testing our drivers on various platforms and languages 
without needing a real (or simulated) device.

I think we should translate the Milo based tests into ones using our 
DriverTestsuite framework, as admittedly I’m fedup with Milo …


Chris

Re: Connection Issue with Siemens PLC via OPC UA

[Łukasz Dywicki]

Actually I am wrong, we support username/password authentication scheme. :-)

On 29.06.2023 16:30, Łukasz Dywicki wrote:

Hello Antonio,
Apache PLC4X currently supports only anonymous connections. If your PLC 
is configured with some security (sign / sign and encrypt) then it will 
not work.
There is working on adding support for that, but its not finalized nor 
ready for review yet.


Kind regards,
Łukasz

On 29.06.2023 11:10, FARIELLO, ANTONIO wrote:

Dear PLC4x Team,

I'm writing to you to document a problem we encountered when trying to 
connect to a Siemens PLC via OPC UA using a Java client.


We programmed a Java client to establish a connection to the Siemens 
PLC, following the recommended methods and procedures.


However, we were unable to get a working connection. During our tests, 
we were connected to a switch via network cable, and the same switch 
was in turn connected to the PLC.


Running the test several times (without any changes to the code) we 
obtained 3 different results:


1) Error: "Connection terminated by remote"

2) Error: "An established connection was aborted by the software in 
your host machine"


3) Connection established successfully (very rarely).

I would like to point out that we have tested the functionality of 
other tools such as Apache Milo and UA Expert, which successfully 
connected to Siemens PLC using the same network environment. These 
tools established a connection without problems, proving that the PLC 
and its configuration are correct.


Therefore, we are interested in understanding what could be the cause 
of the problem we are having with the Java client that we have 
developed using PLC4x. We can rule out a malfunction of the PLC or its 
configuration, as other tools work fine.


Thank you for the attention dedicated to our request and I look 
forward to your response to resolve this issue.


Best regards,

Antonio.

*Antonio Fariello*

Professional | Industrial Operations Engineer

Capgemini Italia | Italy

antoniofarie...@capgemini.com <mailto:antoniofarie...@capgemini.com>

www.capgemini.com <http://www.capgemini.com/>

<https://www.capgemini.com/resources/get-the-future-you-want>

twitter <https://twitter.com/capgemini>linkedin 
<https://www.linkedin.com/company/capgemini>facebook 
<https://www.facebook.com/capgemini>youtube 
<https://www.youtube.com/profile?user=capgeminimedia>soundcloud 
<https://soundcloud.com/capgemini>Résultat de recherche d'images pour 
"instagram logo rond" 
<https://www.instagram.com/capgemini><https://www.slideshare.net/capgemini><https://www.glassdoor.com/Overview/Working-at-Capgemini-EI_IE3803.11,20.htm>


7  Switch off  |qRecycle |PPrint only if necessary

This message contains information that may be privileged or 
confidential and is the property of the Capgemini Group. It is 
intended only for the person to whom it is addressed. If you are not 
the intended recipient, you are not authorized to read, print, retain, 
copy, disseminate, distribute, or use this message or any part 
thereof. If you receive this message in error, please notify the 
sender immediately and delete all copies of this message.

Re: Connection Issue with Siemens PLC via OPC UA

[Łukasz Dywicki]

Hello Antonio,
Apache PLC4X currently supports only anonymous connections. If your PLC 
is configured with some security (sign / sign and encrypt) then it will 
not work.
There is working on adding support for that, but its not finalized nor 
ready for review yet.


Kind regards,
Łukasz

On 29.06.2023 11:10, FARIELLO, ANTONIO wrote:

Dear PLC4x Team,

I'm writing to you to document a problem we encountered when trying to 
connect to a Siemens PLC via OPC UA using a Java client.


We programmed a Java client to establish a connection to the Siemens 
PLC, following the recommended methods and procedures.


However, we were unable to get a working connection. During our tests, 
we were connected to a switch via network cable, and the same switch was 
in turn connected to the PLC.


Running the test several times (without any changes to the code) we 
obtained 3 different results:


1) Error: "Connection terminated by remote"

2) Error: "An established connection was aborted by the software in your 
host machine"


3) Connection established successfully (very rarely).

I would like to point out that we have tested the functionality of other 
tools such as Apache Milo and UA Expert, which successfully connected to 
Siemens PLC using the same network environment. These tools established 
a connection without problems, proving that the PLC and its 
configuration are correct.


Therefore, we are interested in understanding what could be the cause of 
the problem we are having with the Java client that we have developed 
using PLC4x. We can rule out a malfunction of the PLC or its 
configuration, as other tools work fine.


Thank you for the attention dedicated to our request and I look forward 
to your response to resolve this issue.


Best regards,

Antonio.

*Antonio Fariello*

Professional | Industrial Operations Engineer

Capgemini Italia | Italy

antoniofarie...@capgemini.com 

www.capgemini.com 



twitter linkedin 
facebook 
youtube 
soundcloud 
Résultat de recherche d'images pour 
"instagram logo rond" 



7  Switch off  |qRecycle |PPrint only if necessary

This message contains information that may be privileged or confidential 
and is the property of the Capgemini Group. It is intended only for the 
person to whom it is addressed. If you are not the intended recipient, 
you are not authorized to read, print, retain, copy, disseminate, 
distribute, or use this message or any part thereof. If you receive this 
message in error, please notify the sender immediately and delete all 
copies of this message.

Re: [D] [Java] How should we handle "loggers"? (plc4x)

[Łukasz Dywicki]

The static logger declaration is still a thing made by (older/elder? ;)) 
java developers, mainly because log4j 1.x/commons-logging/jul loggers 
were advised to be made like that. With switch to slf4j static is no 
longer mandatory/strongly recommended.
Most of code I make myself rely on logger field, but I've seen people 
who do it with `@Slf4j` annotation coming from Lombok.


Anyhow, is there a intention (not yet a plan) to unify this part of our 
code?


Best,
Łukasz

On 2.06.2023 08:35, chrisdutz (via GitHub) wrote:


GitHub user chrisdutz added a comment to the discussion: [Java] How should we handle 
"loggers"?

And here ... even the Slf4j folks no longer recommend any general way of doing 
things: https://www.slf4j.org/faq.html#declared_static
I guess in the past, there was a performance reason to to things, but this no 
longer seems to apply today.

GitHub link: 
https://github.com/apache/plc4x/discussions/973#discussioncomment-6068178


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

Re: [DISCUSS] Have some sort of multi-connection?

[Łukasz Dywicki]

We do have SingleProtocolStackConfigurer which suggests that somewhere 
in the past there was an intent to have a 
"MultiProtocolStackConfigurer". ;-)
Since we are reaching that point it raises a question what is the role 
of PlcConnection and how to coordinate it, in case if it covers multiple 
streams.
As far I remember one of protocols where we struggled with TCP and UDP 
was Ethernet/IP which uses first for setup and other for subscriptions. 
I believe that with work you are starting we will be able to get closer 
to EIP spec.


One important point is - whether we isolate netty completely from the 
game, and make protocol stack configurer a more independent thing or we 
keep pushing everything over netty. We have a number of troubles caused 
by netty - timeouts (with pending PR), we laso used to have connection 
and thread leaks. Netty, with all its optimizations, is fairly 
complicated underneath. Sometimes I feel we don't even get it. Its use 
also seems to be a bit historic, cause first drivers which got 
implemented by hand uses netty codecs.
Since our current way of setting up connection feels quite complicated, 
I fear that we will make it even harder to debug over time. Now we pack 
i.e. ether or canbus frames into a byte buffer just to spin netty's 
old-io loop which fires our handler which with decoding logic.


Best,
Łukasz

On 5.05.2023 15:17, Christofer Dutz wrote:

Hi all,

while going through Cesar’s changes I noticed that he actually addressed 
something I keept on avoiding ;-) ... Multi-Connections. I know I needed them 
for PROFINET (Raw base transport and UDP config) as well as ADS (TCP base 
transport and UDP config) ... I solved the problem by implementing the UDP 
stuff manually, completely avoiding Netty .. but I think it would be more in 
the spirit of PLC4X to do it in a cleaner way ... as Cesar did it.

However, Cesars version is hard-coded for S7 and S7HA. I would suggest to build 
a more generic solution ... what do you folks think?

Chris

Re: [DISCUSS] Have some sort of multi-connection?

[Łukasz Dywicki]

We do have SingleProtocolStackConfigurer which suggests that somewhere 
in the past there was an intent to have a 
"MultiProtocolStackConfigurer". ;-)
Since we are reaching that point it raises a question what is the role 
of PlcConnection and how to coordinate it, in case if it covers multiple 
streams.
As far I remember one of protocols where we struggled with TCP and UDP 
was Ethernet/IP which uses first for setup and other for subscriptions. 
I believe that with work you are starting we will be able to get closer 
to EIP spec.


One important point is - whether we isolate netty completely from the 
game, and make protocol stack configurer a more independent thing or we 
keep pushing everything over netty. We have a number of troubles caused 
by netty - timeouts (with pending PR), we laso used to have connection 
and thread leaks. Netty, with all its optimizations, is fairly 
complicated underneath. Sometimes I feel we don't even get it. Its use 
also seems to be a bit historic, cause first drivers which got 
implemented by hand uses netty codecs.
Since our current way of setting up connection feels quite complicated, 
I fear that we will make it even harder to debug over time. Now we pack 
i.e. ether or canbus frames into a byte buffer just to spin netty's 
old-io loop which fires our handler which with decoding logic.


Best,
Łukasz

On 5.05.2023 15:17, Christofer Dutz wrote:

Hi all,

while going through Cesar’s changes I noticed that he actually addressed 
something I keept on avoiding ;-) ... Multi-Connections. I know I needed them 
for PROFINET (Raw base transport and UDP config) as well as ADS (TCP base 
transport and UDP config) ... I solved the problem by implementing the UDP 
stuff manually, completely avoiding Netty .. but I think it would be more in 
the spirit of PLC4X to do it in a cleaner way ... as Cesar did it.

However, Cesars version is hard-coded for S7 and S7HA. I would suggest to build 
a more generic solution ... what do you folks think?

Chris

Re: [Opinion] NiFi integration Listener

[Łukasz Dywicki]

Hello Unai and Otto,
There are certain traps with this approach as not all protocols are 
equal in this regard. Currently 
PlcConnection.getMetadata().canSubscribe() determines if driver/protocol 
itself supports subscriptions, however it does not indicate that 
connection as a whole will handle it properly.
Given recent example of S7 updates - S7-1200 does not support 
subscriptions or supports it in very limited. S7-1500 will handle wider 
pool of areas where you can subscribe. Luckily we can attempt to guess 
what sits on other side of connection to dynamically determine if 
subscription is possible.
Pulling example further - with BACnet devices (such driver does not 
exist yet for Java) you have a single "logical connection" but multiple 
devices behind it. Each device behind that connection may or may not 
support subscription (change of values).
ADS on other hand I think have no limitations on what to subscribe, thus 
any field will work.


There are specific relations between driver, protocol and device and our 
ability to tell exactly if plc4x subscriptions will work. Bear in mind 
that while you will be working on a listener.


Cheers,
Łukasz

On 4.05.2023 09:37, Unai Leria wrote:

The idea is that the processor only allows the use of plc4x subscription 
requests. It would only work on drivers that support subscription.
I have made the assumption that the all plc4x subscriptions implementations are 
optimized listeners and are not based only on continuous polling.


De: "Otto Fowler" 
Para: "dev" , "unai leria" 
Enviados: Miércoles, 3 de Mayo 2023 16:38:08
Asunto: Re: [Opinion] NiFi integration Listener

So this would be a plc4x subscription listener not something polling? I don’t 
think that is a bad idea overall, as long as it is true
Unsolicited / subscription / Exception based processing and not polling in a 
background thread.






On May 3, 2023 at 4:36:03 AM, Unai Leria ( [ mailto:unai.le...@zylk.net.invalid 
| unai.le...@zylk.net.invalid ] ) wrote:


Hi Otto!

The idea was to use the processor to support plc4x subscriptions. Maybe the 
"listener" name was not the most appropriate one but I was trying to follow the 
NiFi naming convention.

Sorry for the misunderstanding

Unai

- Mensaje original -
De: "Otto Fowler" < [ mailto:ottobackwa...@gmail.com | ottobackwa...@gmail.com ] 
>
Para: "dev" < [ mailto:dev@plc4x.apache.org | dev@plc4x.apache.org ] >, "unai leria" 
< [ mailto:unai.le...@zylk.net | unai.le...@zylk.net ] >
Enviados: Miércoles, 3 de Mayo 2023 3:53:17
Asunto: Re: [Opinion] NiFi integration Listener

On May 2, 2023 at 9:52:08 PM, Otto Fowler ( [ mailto:ottobackwa...@gmail.com | 
ottobackwa...@gmail.com ] ) wrote:

Hi Unai!

So, this listener would listen for exception based or unsolicited messages?
If it is just polling on a background thread, I don’t think how you want to
do something in nifi, and we already have “polling” processors.



On May 2, 2023 at 11:09:33 AM, Unai Leria (unai.le...@zylk.net.invalid)
wrote:

Hi br/> <
I have been taking a look into the possibility of adding a PLC4x Listener
to the NiFi integration. br/> <
Under my research, and following how most of the ListenXXX processors in
the standard-bundle of NiFi are, a good solution would be:


* A processor that starts a thread when it is scheduled.
* That thread connects to the plc and appends the messages received into a
queue. br/> * The processor reads the messages from thiis queue only
running when not empty. br/> <
In particular ListenTCP and ListenUDP would be the closest ones to the
implementation I describe. br/> <
In order to account for inevitable disconnections I suggest including an
additional queue prior to the queue that connects to the processor. Its
function would be to check if the time to the last event is greater than x
amount and reconnect in that case. br/> <
As a proof of concept I already have a working version on
[ 
https://github.com/zylklab/plc4x/tree/feature/nifi-integration-record-listener 
| 
https://github.com/zylklab/plc4x/tree/feature/nifi-integration-record-listener 
] .
br/> <
I would appreciate your opinion on this feature. br/>If you like it I can
create a PR. br/> <
Thanks you for your time! br/> <
Unai Lería br/>

Re: Please don't merge mspec changes if you haven't built with all languages enabled

[Łukasz Dywicki]

Hello Chris,
What you asking for might effectively stop any contributions to protocol 
updates for entire project. There are very few people who can do Java, 
C, Go and eventually Python. I know one of goals of Apache PLC4X is 
supporting variety of languages, but what you suggest  mean that less 
and less people will be able contribute mspec fixes. There will be even 
less of them with each next language we introduce..
While I understand it is important to keep consistency, reality is we 
have far less people working on C than on Java. Some of languages we 
have code generators and drivers for, did and will fall behind.
I'd rather opt for keeping mspecs releases separate from drivers so 
plc4j/plc4c and plc4go can pick version they support and stick with it. 
This is the way in which we can avoid troubles with new changes which 
are implemented in one language but not others. What do you think about 
that?


Best,
Łukasz


On 3.05.2023 16:42, Christofer Dutz wrote:

Hi all,

we’re currently trying to get the S7 driver back working ... even if it seems 
as if it is working (When running the ManualS7Test) ... None of the 
Integration-Tests are running, because all are disabled.
This makes quality assurance quite difficult.

Also, the fact that the changes broke the C and the Go versions is “sub-ideal”.

We’ll try to fix the problems, but I guess it’s going to consume a lot of time 
to do so.

But in the future ... if you change mspecs for drivers, you might break things 
in other languages, so It’s super important to ensure stuff is working in all 
languages.

Also please don’t comment out tests ... I know I found a place where I did so 
too and I promise to not do it again.

We really have to pay a bit more attention on not reducing more and more of our 
tests.

Chris

Re: AW: Trying to fix the timeout issues ...

[Łukasz Dywicki]

If you have a look on test I pointed - its current weakness is that 
timeout do not occur if you do not have data packet incoming from 
network pipe.


Present implementation simply needs working network to spot timeout 
which contradicts the timeout concept in general:

https://github.com/apache/plc4x/blob/1045cf01a525acddf118ecfb1916df3f84921853/plc4j/spi/src/test/java/org/apache/plc4x/java/spi/Plc4xNettyWrapperTest.java#L94

If you remove that line driver handler will never be notified about failure.
Solution used by heyoulin/spnettec was to introduce watchdog thread on 
our end which is, fairly speaking, best way to do. Patch I made is there 
to define SPIs and cover its brief behavior with netty wrapper test. It 
will definitely help with i.e. ADS doing silent tcp_close on connections 
which result in no more plc traffic.


Cesar's approach addresses a bit different issue which is oriented 
towards HA, not sure if channels are targeted towards same or different 
PLCs.


Cheers,
Łukasz

On 17.03.2023 18:35, Christofer Dutz wrote:

Hi all,

I mean … I would feel more comfortable, if we came up with a test that 
demonstrates the current implementations weaknesses. This way we can prove 
another implementation addresses that issue. Otherwise it just feels like we’re 
swapping one option with another without any idea if this really will be better.

Who knows? Perhaps it addresses this one issue better but other situations in 
other usage-patterns worse?

I think if we work on stuff like this, we should sort of start implementing 
tests.

Chris

Von: Cesar Garcia 
Datum: Freitag, 17. März 2023 um 18:03
An: dev@plc4x.apache.org 
Betreff: Re: Trying to fix the timeout issues ...
Hello everyone,

For the S7HA version I used a different path for the timeout implementation.

 / NIOChannel B
PLC4X -> EmbeddedChannel ->
\ NIOChannel A

Channels A and B have timeout monitoring (IdleStateHandler) to handle
disconnection.

The EmbeddedChannel implementation contains all the state machines required
to manage TCP/IP.  It also handles the FailOver between the channels.

This way you don't have to recreate the connection from the client's point
of view (PLC4X).

The client is told to disconnect when the TCP/IP channels A and B are
actually disconnected. But it does not destroy the main pipe.

my grain of sand,

El vie, 17 mar 2023 a las 3:09, Christofer Dutz ()
escribió:


Hi all,

I would like to address the timeout handling in our Java driver core next.
Unfortunately, I am a bit unsure how to address that.
Usually, I would whip up a Unit-Test that causes the error and then to fix
it.

However, I don’t quite know how to produce the problem that people are
describing.

Would anyone here be able to assist me with at least that? I’m happy to do
the fixing.
I just feel uncomfortable just swapping some code out with random other
code.


Chris




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

*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
*Ing. César García*

*Cel: +58 414-760.98.95*

*Hotline Técnica SIEMENS: 0800 1005080*

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

Re: Trying to fix the timeout issues ...

[Łukasz Dywicki]

Hey Chris,
We do have one, fairly basic Plc4xNettyWrapperTest which covers timeout 
handling. The PR I made https://github.com/apache/plc4x/pull/822 was 
spotted by this test and showed that we had behavior change.


One thing which I still haven't found answer to is how to bind lifecycle 
of timeout manager with connection and how to let end user pass external 
timeout manager into driver (so he can centrally track degraded operations).


Best,
Łukasz

On 17.03.2023 08:09, Christofer Dutz wrote:

Hi all,

I would like to address the timeout handling in our Java driver core next.
Unfortunately, I am a bit unsure how to address that.
Usually, I would whip up a Unit-Test that causes the error and then to fix it.

However, I don’t quite know how to produce the problem that people are 
describing.

Would anyone here be able to assist me with at least that? I’m happy to do the 
fixing.
I just feel uncomfortable just swapping some code out with random other code.


Chris

Re: eblfisch.org: A Open-source runtime system for component-based implementation of automation solutions with Java

[Łukasz Dywicki]

Dear Bernd,
I had a look on eblfish and associated sources. Sadly it is based on GNU 
General Public License v3 which makes it impossible to use with Apache 
projects. Such restriction do not apply if you would like to consume 
Apache PLC4X in elbfish.


Kind regards,
Łukasz

On 3.03.2023 15:13, Bernd Schuster wrote:

Hi all,

recently i came across plc4x which is an awesome project. It might be 
interesting for you to check out http://www.elbfisch.org/ as well which 
is an open source framework for implementation of complex modular 
automation solutions.


It already incorporates the so called VIOSS (versatile I/O subsystem) 
which implements connectivity to S7,Modbus,OPC/UA,ADS with URI based 
addressing schemes which are similar to these of PLC4X.


Maybe we can cooperate, for example by integrating the PLC4X drivers 
into Elbfisch to make the automation world a better place.


Best

Bernd Schuster

--

Mit freundlichen Grüßen

*Bernd Schuster*
Geschäftsführung

T +49 40 839286 10
schus...@mskgmbh.com 

MSK Logo

MSK Gesellschaft für Automatisierung mbH
Holstenplatz 6
D-22869 Schenefeld
https://www.mskgmbh.com 

MSK Gesellschaft für Automatisierung mbH, Sitz der Gesellschaft: Schenefeld
Amtsgericht Pinneberg HRB 2960, UST: 18298932901 ID:DE353131142
Geschäftsführer: Bernd Schuster

Re: Issue with CachedPlcConnectionManager in nifi integration

[Łukasz Dywicki]

I think for that case we have connection state listener which might be 
help with such cases.


Best,
Łukasz

On 22.02.2023 11:58, youlin he wrote:

I have restored maxUserTime.

Sometimes we must hold the connection for a long time. For example, in the
loop retrieve PLC data.

If request timeout the base drive will throw a timeoutException and
cacheManage will close this real connection and set the isConnected of the
leased connection as false.
So we can determine whether the connection is closed in the loop and
automatically connect if it is closed.

If you can merge my New PR. We should remove maxUserTime again.

Christofer Dutz  于2023年2月22日周三 18:40写道：


Could you please summarize which changes these were exactly? Removing the
maxUserTime? Because if this is the case, we probably need to have a look
at how you are using the ConnectionCache.

Chris


From: Unai Leria 
Date: Wednesday, 22. February 2023 at 10:34
To: dev 
Subject: Re: Issue with CachedPlcConnectionManager in nifi integration
For the nifi integration to work I did only use the changes on
plc4x/plc4j/tools/connection-cache from spnettec/plc4x/tree/heyoulin.
Plus some minor changes in the nifi integration to add a timeout to all
processors.

Unai

- Mensaje original -
De: "youlin he" 
Para: "dev" , "Christofer Dutz" <
christofer.d...@c-ware.de>
Enviados: Miércoles, 22 de Febrero 2023 10:21:51
Asunto: Re: Issue with CachedPlcConnectionManager in nifi integration

But it should be based on driver base revision. Otherwise network
connection breaks would still happen.
@Christofer Dutz 

youlin he  于2023年2月22日周三 17:16写道：


Ok. I will create a PR

Christofer Dutz  于2023年2月22日周三 16:44写道：


Unfortunately, this is not a branch, but a fork … Would you be able to
pull the changes that made it work in a separate PR? Then we can more
quickly adopt the changes, because we definitely are not going to merge
that PR (At least I’m not going to do it)

Chris


From: Unai Leria 
Date: Wednesday, 22. February 2023 at 09:28
To: dev 
Subject: Re: Issue with CachedPlcConnectionManager in nifi integration
It does work in the heyoulin branch. Thanks you.

Unai

- Mensaje original -
De: "youlin he" 
Para: "dev" 
Enviados: Martes, 21 de Febrero 2023 14:54:14
Asunto: Re: Issue with CachedPlcConnectionManager in nifi integration

I removed the maxUseTime. I think it is unnecessary to add

request-timeout

feature in the next version.

youlin he  于2023年2月21日周二 21:48写道：


Can you test use https://github.com/spnettec/plc4x  heyoulin branch.

I

fixed this problem.

Unai Leria  于2023年2月21日周二 21:17写道：


Hi,

I've been working with the CachedPlcConnectionManager on the NiFi
integration and I have encountered a problem while looking at issue [
https://github.com/apache/plc4x/issues/623 | #623 ] :
When a successful connection is already stored in the cache and the
network connection breaks the connections in the cache are no longer
usable, but I have not been able to remove them.
This makes the processor not work until it is manually disabled and
enabled.

For the NiFi integration to work properly there should be a way of
removing a connection from the cache if it is invalid.

I would appreciate some guidance.

Unai

Re: [DISCUSS] Handling of ByteEncoding in Parser and Serializer?

[Łukasz Dywicki]

Hey Chris,
How does this apply to "with" encoding options Sebastian and you worked 
on before?
I guess that in such case, if we speak of modbus and application level 
byte encoding, it might be more of runtime setting which could be passed 
through connection options and propagated down to generated code. Since 
it is resolved at runtime we would not need to allocate additional 
fields and rely on connection/runtime context and request byte order 
from there.. if possible.


Cheers,
Łukasz

On 18.02.2023 17:48, Christofer Dutz wrote:

Hi all,

so in general we have the situation in which we usually have either BigEndian 
or LittleEndian encoding. Or we have dynamic encoding based on data in the 
packet itself (PROFINET). Now Ben added something I think we’ll be needing on 
other drivers too (Modbus) … that the encoding is passed in from the outside.

He solved this by passing in a custom type to the Parser and relying on this 
being saved in an artificial ParserArgument-Field.

I’m not a big fan of storing parser arguments in fields to be able to access 
them when serializing, because it sort of adds clutter to the model.

I would love to change things in a way, that if a parser argument of type 
“ByteEncoding” is defined, that this field is also automatically added to the 
serializer.

What do you folks think?

Chris

Re: [DISCUSS] Change the general tag-format to include "Encoding"?

[Łukasz Dywicki]

What do you think about making it two fold - one for making string 
encoding settable optionally for connection and separately at the tag level?


With regard to syntax, field/tag patterns themselves (AFAIK) so far do 
not use curly brackets anywhere, so its fine to begin with them.


Best,
Łukasz

On 18.02.2023 23:39, Christofer Dutz wrote:

Hi all,

As you know, I recently created a PR from the changes another github uses did 
based on our work. He also changed the syntax of the String tags in some 
drivers to include an encoding.

I didn’t like the format he chose (separating the encoding from the the rest 
with a pipe symbol). But in general I think it would be good, if we allowed 
specifying an encoding, if we want to use a non-default encoding.

So my proposal would be to add the encoding to all tags (not only strings) as I 
could also imagine that it might be beneficial to provide different types of 
integer, floating point, date and time encodings.

My proposal would be to have an additional encoding wrapped in curly braces at 
the end of the tag address:

Example:

%DB120.DBX234:STRING(10){ASCII}

Espeically for protocols like Modbus, I think this could be pretty good to have.

What do you think?

Chris

Re: [DISCUSS] Generally move to using "Context" objects inside our generated code?

[Łukasz Dywicki]

I don't think Cesar suggestion is far from Christofer's work.
Making a context which is a glue between information known at compile 
time and resolution done at runtime makes a lot of sense, since some 
data might depend not only on connection setup but also on extra 
resolution done on top of established connection. I could point here 
recent work made by Christofer on custom/complex types for ADS which is 
known only after making connection and clearly involves wire operations. 
Not sure about OPC UA encryption, but from what I remember it was also 
something which required a bit of adjustments from Ben.


There are more cases when serialization may require external input which 
does not align with connection options or make them insane long. A prime 
example could be a WM-Bus where one connection must handle multiple 
encryption keys for end device's (and you may have hundreds of them).


If you ask me, getting a concept of context included in generated 
serialization library, I'm all for it since it can streamline further 
work in multiple areas. I'd suggest to keep it as separate SPI/API 
element with known type, cause then it will be much easier to keep track 
of its use across multiple places. While Map's are great giving insane 
flexibility, tracing their use is extremely hard.


Best,
Łukasz

On 4.02.2023 19:19, Christofer Dutz wrote:

I'm more talking about a serialization and parse-context. Driver context would 
be something separate and I think we already have that, don't we?

Gesendet von Outlook für Android

From: Cesar Garcia 
Sent: Saturday, February 4, 2023 6:47:54 PM
To: dev@plc4x.apache.org 
Subject: Re: [DISCUSS] Generally move to using "Context" objects inside our 
generated code?

+1, If there's a way to get the driver's context, something like
"PlcDriver.getContext()", and pass pipe information, interesting.

El sáb, 4 feb 2023 a las 6:18, Christofer Dutz ()
escribió:


Hi all,

recently I have been working on supporting dynamic tags like “_itemCount”,
“_curItem” and “_lastItem” in array elements.

In java I used ThreadLocals for this as it felt like a Java-Native way and
it wouldn’t blow up the signatures of our Parser, Serializer and
GetLengthInXYZ methods.

Now when looking for something similar in Go, it seems in such cases
Contexts are used. These are sort of like a HashMap wrapped with little
util methods. In this HashMap you pass along values that are “in context” …
if you change the context, a copy of the old context is created and then
the updated/added values are updated/added to the HashMap.

So, in an array I add the additional information to the existing one by:

arrayCtx := spiContext.CreateArrayContext(ctx, int(_numItems),
int(_curItem))


and then simply pass in the „arrayContext”. And for accessing it I simply
for this:

spiContext.GetLastItemFromContext(ctx)



Admittedly I’m not a big fan of crating copies of the full context every
time, I would prefer to be able to push to sort of a context stack, but I
guess that’s the way things work in Go.



When I wanted to add the functionality of Java and Go to PLC4C I was a bit
stuck, as neither concept really existed.



However thinking a bit more about it, adding the concept of Contexts to C
was actually quite simple.



Now that got me thinking:

Shouldn’t we implement the same pattern for Java? It should be easy to
implement.



And while I was thinking, I even thought: Shouldn’t we extend this idea
and also get the ReadBuffer, WriteBuffer, the Encoding, the ByteOrder and
anything we’re currently passing along with “WithXYZOption” var-args, into
these Contexts and simply pass along one Context object?

I think this would clean up the code quite a bit.



What do you think?



Chris








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

*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
*Ing. César García*

*Cel: +58 414-760.98.95*

*Hotline Técnica SIEMENS: 0800 1005080*

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

Re: [NOTICE] Updated Code-Generation ....

[Łukasz Dywicki]

Hey Chris & Sebastian,
That's a great addition cause I've ran into parser issues while trying 
to extend ADS mspec. My trouble was a frame with error code which lead 
to a nested type switch.
For proof of concept I moved typeSwitch to another discriminatedType 
which worked, but caused a massive change to the generated code and 
logic of drivers.
Looking at your example I have a new hope that amount of changes can be 
reduced. :-)


Kind regards,
Łukasz

On 27.01.2023 12:48, Christofer Dutz wrote:

Hi all,

I guess most people won’t care about this, but for anyone writing MSPECs, this 
is HUGE.

Sebastian and I implemented some changes to mspec and the Java code-generation 
that now allow using typeSwitch fields inside cases of typeSwitches.

This allows multiple layers of polymorphism.

Here our example mspec that we tested with:

[discriminatedType TypeSwitchInTypeSwitchParentType
 [discriminator uint 8 typeNumber]
 [simple uint 8 parentFieldHurz]
 [typeSwitch typeNumber
 ['0x00' *Child0
 [discriminator uint 8 childNumber]
 [simple uint 8 childFieldwolf]
 [typeSwitch childNumber
 ['0x01' *Infant0
 [discriminator uint 8 infantNumber]
 [simple uint 8 infantSomeField00]
 [typeSwitch infantNumber
 ['0x98' *InfantsChild0
 [simple uint 8 infantsChild0SomeField00]
 ]
 ['0x99' *InfantsChild1
 [simple uint 8 infantsChild1SomeField00]
 ]
 ]
 ]
 ['0x02' *Infant1
 [simple uint 8 infantSomeField01]
 ]
 ['0x03' *Infant2
 [simple uint 8 infantSomeField02]
 ]
 ]
 ]
 ['0x10' *Child1
 [discriminator uint 8 childNumber]
 [simple uint 8 childFieldLamm]
 [typeSwitch childNumber
 ['0x11' *Infant3
 [simple uint 8 infantSomeField1ß]
 ]
 ['0x12' *Infant4
 [simple uint 8 infantSomeField11]
 ]
 ['0x13' *Infant5
 [simple uint 8 infantSomeField12]
 ]
 ]
 ]
 ['0x20' *Child2
 [discriminator uint 8 childNumber]
 [simple uint 8 childFieldGrueneWiese]
 [typeSwitch childNumber
 ['0x21' *Infant6
 [simple uint 8 infantSomeField21]
 ]
 ['0x22' *Infant7
 [simple uint 8 infantSomeField22]
 ]
 ['0x23' *Infant8
 [simple uint 8 infantSomeField23]
 ]
 ]
 ]
 ]
]

While working on the code-gen and fixing some issues with a new protocol I’m 
working on, I noticed that we were generating unneeded properties into our 
types, that required us to set some dummy values.

I’ve changed this that this no longer is needed but can be switched on via 
code-generation options.


   c-bus
   java
   read-write
   src/main/generated
   
 
true
 
 
true
   


I’ve also removed the dummy values from the drivers in all drivers except c-bus 
and bacnet.

Still doing the last tweaks but hope to be able to push soon.

So far the update :-)

Chris

Re: [DISCUSS] Send dependant emails to commits@ or a new list (notifications@)?

[Łukasz Dywicki]

+1

Makes ton of sense to shift them as most of us receive these 
notifications via github itself and email is redundant.
Moving them to commits or notifications list will clear up list from 
unnecessary noise.


Cheers,
Łukasz

On 20.01.2023 15:56, Christofer Dutz wrote:

Done (I hope)

I redirected them to “commits” for now … we can always create a “notifications” 
list.

Chris

From: Niklas Merz 
Date: Friday, 20. January 2023 at 14:39
To: dev@plc4x.apache.org 
Subject: Re: [DISCUSS] Send dependant emails to commits@ or a new list 
(notifications@)?
+1

This would be much appreciated.

On January 20, 2023, Tobias Tschinkowitz
 wrote:

+1


Am 20.01.2023 um 13:47 schrieb Otto Fowler

:


+1

From: Christofer Dutz 

Reply: dev@plc4x.apache.org 



Date: January 19, 2023 at 12:08:07
To: dev@plc4x.apache.org 



Subject: [DISCUSS] Send dependant emails to commits@ or a new list
(notifications@)?

Hi all,

today I learned, that it’s possible to redirect bot-notifications to
different lists.
I would really love to rid us from the dependabot emails.
I guess nobody pays much attention to them as Sebasitan constantly

takes

care of them.

Having these emails out of our list would be great.

https://cwiki.apache.org/confluence/display/INFRA/Git+-

+.asf.yaml+features#Git.asf.yamlfeatures-Specialschemesforbots


What do you think?

Chris

Re: modbus word/byte/bitorder on datatypes > 16bits

[Łukasz Dywicki]

With modbus each assumption can be questioned. ;-)
Spec says big endian encoding for each word, but (according to openHAB 
[1] which quotes it), there is no specification for 32 and 64 bit types. 
So OH folks come with "swap" concept which reverse byte order of read 
value. This lead to types such as int32 and int32_swap (same for uint, 
float, int64 and uint64). I wouldn't be surprised if there would be 
devices which return data in one encoding and expect writing in other!


Since data retrieved over modbus always goes over some sort of byte 
array making it anything is not difficult. We just need to stick with 
ReadBuffer/WriteBuffer apis or ship small overlay on top of it.


Cheers,
Łukasz

[1] 
https://github.com/openhab/openhab-addons/tree/3.4.0/bundles/org.openhab.binding.modbus#uint64



On 16.01.2023 12:47, Christofer Dutz wrote:

Hi Jukka,

Well, I think right now we read everything as Big Endian, as the Spec generally 
defines.

However, do we know that this is not sufficient for all devices.
One option we discussed, but which needs to find someone to volunteer to 
implement, is that we generally assume big-endian, but make it possible to set 
the connection to treat the words in different endianness.

Want to get your fingers dirty? ;-)

Chris


From: Jukka Sirviö 
Date: Monday, 16. January 2023 at 09:54
To: dev@plc4x.apache.org 
Subject: modbus word/byte/bitorder on datatypes > 16bits
Hello,
How are you guys dealing with word ordering on modbus datatypes that are larger 
than 16 bits (DINT, DWORD..)? There is variation between PLC vendors how they 
handle this. Don't know if also the bitordering (little vs big endian) may 
differ between PLC vendors.

for example:

word 1 byte 1
word 1 byte 2
word 2 byte 1
word 2 byte 2

vs

word 2 byte 1
word 2 byte 2
word 1 byte 1
word 1 byte 2



-Jukka



Tämä sähköpostiviesti (liitteineen) saattaa sisältää luottamuksellista tietoa, 
joka on tarkoitettu
vain vastaanottajalleen. Jos et ole oikea vastaanottaja, ilmoita viestin 
lähettäjälle tapahtuneesta
virheestä ja tuhoa viesti välittömästi. Viestin luvaton julkaiseminen, 
kopioiminen, jakelu tai muu
käyttö tai toimenpiteisiin ryhtyminen sen perusteella on ehdottomasti kielletty.

This message (including any attachments) may contain confidential information 
intended for
the person or entity to which it is addressed. If you are not the intended 
recipient, notify the
sender and delete this message immediately. Notice that disclosing, copying, 
distributing or any
other use of the message and its information, or taking any action based on it, 
is strictly prohibited.

Re: [DISCUSS] Removing the Apache Feather from our logos?

[Łukasz Dywicki]

Not sure what final resolution at ASF level will be, but it brings a lot 
of question on trademarks which been registered on behalf of foundation. 
Not only graphical ones, but also "verbal". Given all that I would 
rather wait with any changes until board makes a resolution, if it does 
then it will become a coordinated effort spanning across many places.


Best,
Łukasz

On 16.01.2023 07:20, Lukas Ott wrote:

Yeah sure we can remove the feather. We have a lot of other Toddy Logos
with PLC s and so on anyway.

I am just wondering how we could at least incorporate the colors from the
ASF.

Cheers
Luk

Christofer Dutz  schrieb am So., 15. Jan. 2023,
12:21:


Hi all,

I know that initially I had our designer add the feather to our logo, to
lay emphasis on the relation to the ASF.

Now over the last few years there have been many rounds of fruitless
discussions on changing the name of the Apache Software Foundation as it
would be harming the Native American Cultural Groups.
Many people are discussing on how we could rename the ASF or which steps
we could do.

One argument, that even if “Apache Webserver” was derived from “A Patchy
Webserver” as it initially was a webserver with a lot of patches. Nobody
can argue against the fact that the feather does refer more to native
Americans than towards a set of patches.

So, I thought … how about us starting to do a first step and we remove the
feather from our logo?

What are your thoughts on this?

Chris

Re: [Modbus] Handling 'too large' blocks of registers

[Łukasz Dywicki]

I am really glad you are moving it forward and fighting it!

It is fairly difficult to get modbus code aligned and working 
automatically because different devices behave differently with even 
most basic requests.
I remember that one of electric meters I had to work with did support 
read multiple registers but did not support going over "empty" indexes. 
By empty  I mean these which were not declared in the documentation, 
even if it was still below 125 limit.


Effectively I could draw three primary options to cover:
- read continuous (just keep expanding requests up to the limit)
- read blocks (group indexes into blocks up to limit, if they are 
continuous)

- read single (read multiple registers is not supported)

Some devices, especially older PLCs may also require extra delay after 
data retrieval, so you have to wait between finishing one request and 
starting another. Some inverters and official dongles made by fairly 
large Chinese manufacturer, which brand I won't mention here, as well as 
primitive tcp/rtu bridges, may require "after connection delay" in order 
to establish rtu connection they use to serve tcp session.


All this makes modbus option list rather long, compared to abilities it 
gives!


Cheers,
Łukasz


On 15.01.2023 17:05, Niels Basjes wrote:

Hi,

No, I'm reading many logical values where the needed registers combined
exceed the 125 mark.
Assume my application needs a set of values and asks for such a block of
registers.
Then the modbus library that gets the request for 200 registers can no
longer reliably split it into multiple parts that yield the correct value.

What I understand of your S7 example (I do not know this device) seems like
a device that offers a single value that exceeds the limits of modbus and
thus I expect they made it so you can fetch it step by step.

I'll see if I can do a wireshark dump for you.

What should I make the issue say? I currently do not see this as a bug or
problem with plc4x.

Niels

On Sun, Jan 15, 2023 at 4:46 PM Christofer Dutz 
wrote:


Hi Niels,

I think this might be related to what happens when reading Strings in S7
without providing a length.
In this case each string is 255 charaters long and it already exceeds the
size-limit of 200 or so of a S7 1200.

In S7 we use some code to split up multiple tags into multiple requests,
but rewriting the query to support automatic splitting of one single tag
into multiple requests is quite a bit more difficult.

I thought you were reading multiple tags that in sum exceeded the 125
registers and for that case simply something similar to the S7 query
updater should also work for other protocols.

Do I understand you correctly, that in your case you want to read one tag,
that is bigger?

Chris

From: Niels Basjes 
Date: Sunday, 15. January 2023 at 16:38
To: dev@plc4x.apache.org 
Subject: [Modbus] Handling 'too large' blocks of registers
Hi,

A few weeks ago some code of mine was merged to limit the number of
registers that can be requested in a single ModbusTag because asking for
more than 125 registers in a single request will always fail (because of
the way modbus works).
https://github.com/apache/plc4x/pull/721

One of the comments was asking if it can be automated in a generic way to
split a "too large" request into multiple smaller requests.
So If I ask for a block of 200 registers then plc4x would simply split it
into multiple requests (like 125 and 75 for example, or 100 and 100) and
afterwards merge the resulting registers of the two requests back into a
single block of 200 registers for the upstream application to analyze.

I said I would look into this and this is what I found while doing some
experimenting with my real solar converter.
This device uses the SunSpec standard for defining meaning to modbus
registers.

My current conclusion at this point is that it is impossible to handle this
at the modbus level and I'm looking for you guys to challenge me in this.

Why do I say this?
One of the logical values you can retrieve is the name of the Manufacturer
and the Model of the device that are both stored as UTF-8 in a set of 16
registers (i.e. usually 32 characters).
https://github.com/sunspec/models/blob/master/json/model_1.json#L27
https://github.com/sunspec/models/blob/master/json/model_1.json#L36

I found that if I try to fetch only a part of this logical value I get
either an error (INVALID_ADDRESS) or bad data.
When I fetch the entire value I get the 16 registers which hold the correct
data.

Output of my test program that fetches the Model of the device (which is in
my case "SB3.6-1AV-41" ).
ModbusTag[4x40021:UINT[16]]:  0x5342 0x332E 0x362D 0x3141 0x562D 0x3431
0x 0x 0x 0x 0x 0x 0x 0x 0x 0x
ModbusTag[4x40021:UINT[15]]: INVALID_ADDRESS
ModbusTag[4x40022:UINT[15]]:  0x 0x 0x 0x 0x 0x
0x 0x 0x 0x 0x 0x 0x 0x 0x

So if I retrieve the correct block I get it.
If I try to get 1 register 

Re: Something I've learnt about ADS in the last few days

[Łukasz Dywicki]

Hey Chris,
The "back" connection from PLC could be the reason why PLC4X connection 
does not show "connected" status in route window when using Beckhoff 
engineering tools. I remember that using TC2 stuff a while ago I often 
saw a "read_device_request" coming from PLC end to the PLC4X client.


According to other repositories I found at bitbucket [1] there is 
probably a wider range of operations performed over ADS. Stuff which is 
being published at Beckhoff's github did grew over past couple of years, 
but its still fairly small, even comparing to findings implemented in 
our project. From bitbucket repositories I mentioned there seem to be a 
"device specification" of some kind which allow to use ADS function 
blocks on PLC end while fetching or writing the data to other network 
participant. Looking at official documentation there is nothing more 
than a packet structure. Either there is better docs or it is being 
distributed across so many places that nobody can sum it up into 
something more consistent.


[1] https://bitbucket.org/jmikucki/cpp-ads/ [it does not compile, be 
aware it does not declare any license too]


Best,
Łukasz

On 14.01.2023 15:52, Christofer Dutz wrote:

Hi all,

I guess we‘ll have to think a bit about the ADS protocol.
So-far we have been connecting to the PLC using ADS, but I have just recently 
learnt that we can actually do a lot more.

For example, the thing with the AmsNetId, where we simply add “.1.1” to the IP. 
I can also reach the TwinCAT master that is attached to my PLC by connecting to 
the same IP, but using the AmsNetId “.3.1” at the end.
Also did I notice that what we do with: reading out the symbol tables and the 
datatypes only seems to work with the PLC instance. If I connect to the Device 
Manager for reading out telemetry, this doesn’t work. Also don’t the 
multi-item-requests work.
Now I’m experimenting with reading data from some IO cards, that are attached 
to my PLC via EtherCat adapter.

I really should find out how to detect which features work and to add fallback 
layers (Like switching from Multi-Item-Requests to Single-Item-Requests if 
that’s not supported).

But really interesting stuff you can theoretically do with our driver in it’s 
current state.


Chris

Re: [DISCUSS] Having a in-person community meetup?

[Łukasz Dywicki]

I live in country next to Germany, have direct flight to Frankfurt, so I 
can show up. From my point of view a lot depends on actual dates.
I will arrange travel and accommodation on my own. I would love if TAC 
would have more cash for these who come from far.
Given scope of discussion for now is a weekend, traveling from other 
half of globe should include time to at least heal jet lag!


Best,
Łukasz

On 10.01.2023 14:33, Christofer Dutz wrote:

Hi Cesar,

I guess the distance problem would apply to the Chinese people in our community 
too.
I guess if I had numbers on:
- Who would attend and from where if we did such a meetup

Then I could start the discussion.
Considering international participants, I think the best option would be to do 
it in Frankfurt.
Here codecentric would offer us their offices for working over the weekend and 
there are not too expensive hotels around.
Also are flights to Frankfurt probably better than ones to Stuttgart, I think?

As I could simply put things in a rental-car/van. I could probably bring all my 
equipment with me: Demo Factory, Profinet Stuff, Logo Robot, different PLCs 
from different vendors.

So please speak up … who would be interested to come? And who would need 
assistance and if yes: from where you would be coming.


Chris

From: Cesar Garcia 
Date: Tuesday, 10. January 2023 at 14:22
To: dev@plc4x.apache.org 
Subject: Re: [DISCUSS] Having a in-person community meetup?
How are they?

I am interested in participating, but if possible I would opt for the
support regarding the transfer/accommodation.

I'm a bit far from Europe.

My points of interest for discussion:

1. Profinet Driver (we need the hardware).
2.S7 Driver
3. PLC4X APP (NetBeans platform)

The date is important and in what city would the meeting be?

Best regards,

El mar, 10 ene 2023 a las 6:25, Christofer Dutz ()
escribió:


Good point … the one we should be deleting because of its GPL2 dependency
:-(

From: Dominik Riemer 
Date: Tuesday, 10. January 2023 at 10:30
To: dev@plc4x.apache.org 
Subject: RE: [DISCUSS] Having a in-person community meetup?
Hi,

great idea, I would also try to join the meetup and maybe we can also do
some hacking on the PLC4X UI 

Cheers
Dominik


-Original Message-
From: Christofer Dutz 
Sent: Monday, January 9, 2023 10:05 AM
To: dev@plc4x.apache.org
Subject: Re: [DISCUSS] Having a in-person community meetup?

Well … I was thinking of asking TAC and setting something up.
As I mentioned. That would be quite a bit of work for me and the rest of
the TAC folks.
So we’d only do it if offering this, would make a great difference.

Chris


From: Xiangdong Huang 
Date: Monday, 9. January 2023 at 08:51
To: dev@plc4x.apache.org 
Subject: Re: [DISCUSS] Having a in-person community meetup?
Ah... if there is TAC support, I will forward this message to IoTDB
community to see if there are committers want to join for the Historian
development face to face.

---
Xiangdong Huang
School of Software, Tsinghua University

Christofer Dutz  于2023年1月5日周四 18:59写道：


Hi Jinlin,

Would you be willing and able to attend such an event?
You would be more than welcome.

As I’m also part of the Apache Travel Assistance committee … I’d also

like to ask any others here too:

Would you like to attend such an event, but the costs of travelling are

what you can’t afford or would have a too big impact on your budget to be
willing to come?


Because there theoretically is the option of having Apache cover the

costs for travelling and accommodation. However, this would put quite a lot
of extra work for us for setting it up and running it.

So, if it’s only 1-2 people, this probably doesn’t make much sense, but

if there were more, it might make sense.


And please … don’t say: “I can’t afford it and would like assistance”,
if the problem is that the fuel has become too expensive for your
Ferrari or the parking costs for your private jet are skyrocketing ;-)

And if you don’t want to publicly answer … feel free to DM me.

Chris


From: jl hong 
Date: Thursday, 5. January 2023 at 02:16
To: dev@plc4x.apache.org 
Subject: Re: [DISCUSS] Having a in-person community meetup?
This sounds exciting :)

Jinlin

Lukas Ott  於 2023年1月5日 週四 上午12:11寫道：


cool :-) would be fun so that I can finally ask all my questions in
person
;-)

Am Mi., 4. Jan. 2023 um 16:37 Uhr schrieb Ben Hutcheson <
ben.hut...@gmail.com>:


Sounds like fun.

Ben

On Wed, Jan 4, 2023 at 4:30 PM Christofer Dutz <

christofer.d...@c-ware.de>

wrote:


Ok …

Uwe from codecentric FFM (the new office) was delighted my me
asking if codecentric would be willing to accommodate us during

the hackathon.

So, that would be one option … I guess Sebastian would like that
option

;-)


Chris


From: Christofer Dutz 
Date: Wednesday, 4. January 2023 at 16:24
To: dev@plc4x.apache.org 
Subject: [DISCUSS] Having a in-person community meetup?
Hi all,

some of you remember the times around our graduation. We had
loads of 

Re: [DISCUSS] Refactor the PlcDriverManager in Java?

[Łukasz Dywicki]

Hey Chris,
I second approach with interfaces as it clearly cuts implementation and 
declaration of operations. It could also help people who use OSGi 
because making a PlcDriverManager valid osgi service will be easier 
(lighter) with interface. It boils down to runtime where proxy for 
interface type is built in JVM while proxy for class involves cglib/asm etc.


Best,
Łukasz

On 8.01.2023 15:35, Christofer Dutz wrote:

Hi all,

I’m currently working on a new Connection Cache for Java and have stumbled over 
two things:

The one is the fact, that the PlcDriverManager is a class and not an interface.
This makes it problematic for me to have the PlcDriverManager implement the 
same interface.
I could probably override every method, so this is not a big problem.
However, having a PlcDriverManager interface would be the cleaner solution.
This would require us to change the name of the current PlcDriverManager class 
to something like DefaultPlcDriverManager… this would be a breaking change.

Another is that the getConnection doesn’t return a Future … the main reason for 
this was the try-with-resources pattern, that automatically closes the 
PlcConnection returned from getConnection.
However, returning a future might be the better option and it would be more 
like in the other languages.
Especially when we’re working with cached connections. Here a client might be 
waiting a while till it gets a connection handle.
This also would be a breaking change.


What do you folks think?

Chris

Re: Modbus addresses offset by 1?

[Łukasz Dywicki]

Based on my own experience with modbus devices - you might also face 
situation where manufacturer starts addressing with own offset by not 
following official guidance. A fairly common practice I observed is use 
of addresses ie. 0, 1, 4 for coil/input/holding which are 
being called "entity numbers". [1]
Out of tens of modbus devices I interfaced with I had a matching 
combination of manufacturer docs, library approach and actual device 
addresses once or twice. Speaking here about heat pumps, inverters, 
electric meters and PLCs, all are subject of same trouble.


Maybe implementing whole driver is not needed as you can try to use 
optimizer which lives between your program code and driver and can 
re-arrange fields/tags before they reach device?


Best,
Łukasz

[1] https://en.wikipedia.org/wiki/Modbus#Entity_numbers_and_addresses

On 8.01.2023 12:27, Niels Basjes wrote:

Hi,

Understood. Keep the offset it is.
But why does the ModbusTagExtendedRegister not have this shift? Is that a
bug?

Also there are a few other problems I found in this area, one is that the
getAddressString will yield a different address (which is also unparsable).
I'll see if I can fix those.

Niels

On Sat, Jan 7, 2023 at 8:35 PM Christofer Dutz 
wrote:


Hi all,

yeah … just wanted to say … this stupid offset is by spec that way.
I would say, that in this case we have two different specs with a common
base.
Perhaps if we had “variants” of drivers, we could make different
assumptions.

If you get a Modbus TCP connection things are the way, they currently are.
If you get a Modbus TCP connection with “SunSpec” variant, then you don’t
have the offsets.

Cause … if we undid the “+1” shift, then other would start complaining
because their specked registers are in different locations.

I have also heard that for EIP for full support of the PLC features, we’ll
have to have Allen Bradley, Schneider Electric variants next to the default
ones.
I was told most of the major vendors do all the complex types and browsing
differently :-(

Chris

From: Niels Basjes 
Date: Saturday, 7. January 2023 at 18:31
To: dev@plc4x.apache.org 
Subject: Re: Modbus addresses offset by 1?
Ok, the "off by one" problem is ancient.
Looking around the internet I read that in the past when register 123 was
needed you would have to request for 122 over modbus.

I find the transition from the logical number to the technical number a
responsibility of the application, not of this library.
Take for example the SunSpec (modbus standard for solar systems)
specification it states:

*6.1.1 **Modbus Address Location*
*All Modbus device maps MUST be in the holding register address space.*
*The beginning of the device Modbus map MUST be located at one of three
Modbus addresses*
*in the Modbus holding register address space: 0, 4 (0x9C40) or 5
(0xC350). These*
*Modbus addresses are the full 16-bit, 0-based addresses in the Modbus
protocol messages.*
*The first two Modbus registers at the start address MUST have the
following well-known*
*constant values as a marker: 0x5375, 0x6E53 (hexadecimal values of the
ASCII string SunS).*


On my solar inverter if I request 2 registers at 4 I get the mentioned
0x5375, 0x6E53.
Yet with plc4j/modbus I must specify address 40001 because the library
shifts it by one.
It took me the better part of today to figure that one out.

Niels

On Sat, Jan 7, 2023 at 6:13 PM Niclas Hedhman  wrote:



I am not sure what you are asking; But Modbus documentation addresses
are (in my experience) always offset by 1, which I think goes back to
the 1970s when we weren't yet sure whether numbers started at 0 or at 1,
and number ranges were a scarce resource so we wouldn't sacrifice one
for consistency... Those were the days.

Niclas

On 2023-01-07 17:27, Niels Basjes wrote:

Hi,

I ran into the effect that all modbus addresses I specify are shifted
down
by 1.
This turns out to be code in most of the ModbusTag implementations (not
all) which have a PROTOCOL_ADDRESS_OFFSET to shift it by.

Why was this done?
If I'm writing software to read modbus addresses and I follow the
manufacturer specified information it will run into unexpected effects
(like I have today).

Also: Now getAddressString()  yields something different then what I
used
to build the tag with.





--
Best regards / Met vriendelijke groeten,

Niels Basjes

Re: [DISCUSS] Check in generated Java code?

[Łukasz Dywicki]

Maven have "sources.jar" files which serve purpose of retaining all 
sources, not only generated ones. I would rather look for tool such 
https://abi-laboratory.pro/ which can interact with these than opening a 
pandora box or stick with cafecompare [1].


Having generated sources checked in will lead to unclear situations 
where we might not know which sources are being used with library - the 
checked ones or newly generated from target directory. We often refer 
people to try snapshot or local build when they have problems, which 
guarantees they will see same results as we. How will we keep checked 
sources up to date if generation template was changed, how often we will 
update it? How we will prevent PRs with changes to code we wish to 
generate? (there are bots which submit PRs because of certain imports in 
Java code found)  Who is responsible for that and how we can assure that 
we do not have partial failures?
Sorry, but checking-in generated sources creates more troubles for 
little benefit. The github diff is great, but feature Ben linked is 
about *excluding* generated sources from PR diffs, which effectively 
force to manually navigate and check each file, and these changesets are 
going to be huge. BACnet mspec is creating hundreds of files, making 
them appear only in the list of files included in commits attached to PR 
will make submitter, reviewer and our browsers suffer a lot.


If we go into path where we must check in sources of each and every 
language this library supports it will be better if we will separate 
generated sources from main repository in first place.


[1] https://github.com/GraxCode/cafecompare

Best,
Łukasz

On 25.11.2022 21:43, Ben Hutcheson wrote:

+1

I like the idea of keeping a history of what has changed.

This may help?
https://medium.com/@clarkbw/managing-generated-files-in-github-1f1989c09dfd

On Fri, Nov 25, 2022 at 9:03 AM Łukasz Dywicki  wrote:


-1 from my side

I don't think its a good idea, generated code currently changes far too
often to make sense of it and its history. We rather track code for
generators and templates which produce it. As long as language is fine
with automatically generated sources, I opt for not polluting our SCM
with millions of LOCs which bring no real value.

Letting people checkout and play is fine, but lets face truth, people
who would like to do quick start have to install some kind of maven
tooling which will generate code for them anyway.
If interested party is not using any IDE, it will still need a command
line tool to compile sources.

Best,
Łukasz

On 25.11.2022 11:27, Christofer Dutz wrote:

Hi all,

I know it’s sort of considered bad practice to check in generated code,

when you’re working with maven.


However, we’ve already started to check-in generated code for all other

languages.

Especially today when working on the Time and Date stuff I really have

learned to appreciate to see what changed, when working on code-generation.


I would like to propose to also start checking in the generated

java-code.


But I would like to generate it into a separate directory and use the

build-helper-plugin in order to keep things separate (This way we can
simply delete the directory, run the build and we get rid of obsolete types)


I would propose to generate code into a “src/main/generated” directory.

The upside would be: Everyone can simply check out plc4x and use it in

any IDE without having to build first.


What do you folks think?


Chris

Re: [DISCUSS] Check in generated Java code?

[Łukasz Dywicki]

-1 from my side

I don't think its a good idea, generated code currently changes far too 
often to make sense of it and its history. We rather track code for 
generators and templates which produce it. As long as language is fine 
with automatically generated sources, I opt for not polluting our SCM 
with millions of LOCs which bring no real value.


Letting people checkout and play is fine, but lets face truth, people 
who would like to do quick start have to install some kind of maven 
tooling which will generate code for them anyway.
If interested party is not using any IDE, it will still need a command 
line tool to compile sources.


Best,
Łukasz

On 25.11.2022 11:27, Christofer Dutz wrote:

Hi all,

I know it’s sort of considered bad practice to check in generated code, when 
you’re working with maven.

However, we’ve already started to check-in generated code for all other 
languages.
Especially today when working on the Time and Date stuff I really have learned 
to appreciate to see what changed, when working on code-generation.

I would like to propose to also start checking in the generated java-code.

But I would like to generate it into a separate directory and use the 
build-helper-plugin in order to keep things separate (This way we can simply 
delete the directory, run the build and we get rid of obsolete types)

I would propose to generate code into a “src/main/generated” directory.

The upside would be: Everyone can simply check out plc4x and use it in any IDE 
without having to build first.

What do you folks think?


Chris

Re: [DISCUSS] Rename Fields -> Tags?

[Łukasz Dywicki]

Hey Chris,
I do not insist on any side. Knowing how hard it is to get a "common 
understanding" on certain things I think it is easier if we stick with 
project specific concept.


Other point, we do not need to re-use a PlcField and field notion 
everywhere. For example output from browse api might be a descriptor 
which can be used to construct a field address. After all, a browsing 
functionality might provide more information than needed to fetch data - 
ie. human readable name, description or other elements which are 
irrelevant for driver to get data.


As a side note, I do acknowledge that best time to do naming and larger 
API alignments is prior 1.x release.


Best,
Łukasz

On 6.11.2022 13:32, Christofer Dutz wrote:

Hi Lukasz,

even in protocols like ADS and EIP at Rivian everyone is referring to any data 
point as a “Tag”.
So far, I haven’t come across a single person saying something else on LinkedIn.
https://www.linkedin.com/feed/update/urn:li:activity:6994584721582088192

And keep in mind: PLC4X is meant to be the bridge between IT and OT, and we 
chose a lot of stuff (Like the address patterns, etc.) to match the OT 
expectations. After all, I will most probably be an IT person asking the OT 
person: Please give me the address for Field/Tag XYZ. So, I think naming it 
“Tag” would be better.

I would like to name it to match the most used term: I know that this isn’t 
always a perfect match in all protocols, but I guess that’s the difference 
between providing a “shared API” or building individual drivers for each 
protocol.

And currently we name it “Query” in Go … so you currently say: “AddQuery” 
instead of “AddField”.

Chris


From: Łukasz Dywicki 
Date: Sunday, 6. November 2022 at 11:45
To: dev@plc4x.apache.org , Christofer Dutz 

Subject: Re: [DISCUSS] Rename Fields -> Tags?
Hey Chris,
I am not certain if "tag" is standardized or not. Earlier, knowing only
modbus registers and bacnet objects, I been confused multiple times what
the tag is. For regular IT tag is rather a marker placed on something to
categorize elements. Our field currently specifies rather a unique data
point than a tag.
If tag meaning comes from IEC standard then I'd opt in for a change. If
its not standardized then I'd advice staying with a field. Our use is
mixed IT/OT (with probably still more IT?), if we stick too much to
automation industry terminology then we will need to bake definition of
a tag, fight situations where we miss a "common understanding" cause we
can't beg others for unification of their meaning.

I've seen tag used in context of ethernet/ip (more precisely Rockwell
PLCs), but haven't done a research of why. Keep in mind we have also
object oriented protocols such as BACnet (with `device.object.property`)
and CANopen (with `device.sdo` or `device.tpdo..`) thus in their context
tag is far less meaningful than field.

Cheers,
Łukasz

On 5.11.2022 12:23, Christofer Dutz wrote:

Hi all,

I’m currently working on harmonizing our different API variants a bit and 
hopefully finalizing our Browse API (Which sort of wen’t through multiple 
levels of change between Java and Go, back to Java and now back to Go.

One thing I learned at Rivian is, that everyone seems to be talking about 
“Tags” on PLCs. So I asked on LinkedIn and it seems pretty obvious that “Tag” 
seems to be the term mostly used in the automation industry.

So, I would like to consequently rename “Field” to “Tag”.

What do you folks think?

Chris

Re: [DISCUSS] Rename Fields -> Tags?

[Łukasz Dywicki]

Hey Chris,
I am not certain if "tag" is standardized or not. Earlier, knowing only 
modbus registers and bacnet objects, I been confused multiple times what 
the tag is. For regular IT tag is rather a marker placed on something to 
categorize elements. Our field currently specifies rather a unique data 
point than a tag.
If tag meaning comes from IEC standard then I'd opt in for a change. If 
its not standardized then I'd advice staying with a field. Our use is 
mixed IT/OT (with probably still more IT?), if we stick too much to 
automation industry terminology then we will need to bake definition of 
a tag, fight situations where we miss a "common understanding" cause we 
can't beg others for unification of their meaning.


I've seen tag used in context of ethernet/ip (more precisely Rockwell 
PLCs), but haven't done a research of why. Keep in mind we have also 
object oriented protocols such as BACnet (with `device.object.property`) 
and CANopen (with `device.sdo` or `device.tpdo..`) thus in their context 
tag is far less meaningful than field.


Cheers,
Łukasz

On 5.11.2022 12:23, Christofer Dutz wrote:

Hi all,

I’m currently working on harmonizing our different API variants a bit and 
hopefully finalizing our Browse API (Which sort of wen’t through multiple 
levels of change between Java and Go, back to Java and now back to Go.

One thing I learned at Rivian is, that everyone seems to be talking about 
“Tags” on PLCs. So I asked on LinkedIn and it seems pretty obvious that “Tag” 
seems to be the term mostly used in the automation industry.

So, I would like to consequently rename “Field” to “Tag”.

What do you folks think?

Chris

Re: [DISCUSS] Change the UI framework for the GUI application

[Łukasz Dywicki]

It's pity that javafx has this trouble. We are compiling our code 
against java standard library which is *the* same license. Yet, we do 
not distribute standard library, but we would need to distribute javafx 
binaries and construct executable form in a proper way. I do not insist 
on staying with javafx but I think it is easiest for developer 
experience, given quick win Chris had there. Why not letting ASF LEGAL 
sorting this stuff for us, given that ISIS, Netbeans, Sis and others 
still use it?


I used swing and swt with jface a long time ago. Swing was a bit of pain 
due to limited set of widgets, swt was pain due to native library 
handling. Some parts of jface are emulated, if platform does not have 
corresponding widget ie. tree table.
I guess we won't have a perfect match any more. We can't do qt, 
wxwidgets have custom license too, text ui might be too hard for end 
users. With regard to netbeans it gives us some infrastructure, but it 
is essentially a swing with all its shine and shadows. :/


I looked for swt sources to see how active its development is, and it 
seems to be maintained:

https://git.eclipse.org/r/plugins/gitiles/platform/eclipse.platform.swt/
yet eclipse project page indicates "archived" status. [1] (its probably 
merged with other project)
Its binaries should be possible to fetch via maven repositories. I also 
found another animal called XWT which is a declarative UI approach 
similar to fxml: https://wiki.eclipse.org/XWT_Documentation, however 
this one is based on P2 so it does not usable maven poms.
As far I recall Eclipse folks were debating how to approach P2-maven 
repository ecosystem integration for years already, so I do not expect 
any quick resolution here.


Best,
Łukasz

[1] https://projects.eclipse.org/projects/eclipse.platform.swt/developer

On 24.10.2022 17:03, Cesar Garcia wrote:

Hello,

Netbeans, all in one place.

1. Easy integration of libraries,
2. Graphical interface based on the venerable and stable Swing.
3. Graphing tools already available.

and much more.

Against, the learning curve.

I'm already over it

best regards,

El lun, 24 oct 2022 a las 10:07, Christofer Dutz ()
escribió:


Hi all,

today we noticed that JavaXF is GPL 2.0 (With classpath exception)
licensed.

As we don’t want to jump through all the hoops needed to release this in
an Apache project, we are planning on switching the UI framework we are
basing everything on.

Any suggestions?

We also might consider building a Web-based application instead …
personally I’m open to all.

However, I would really like feedback that’s not based on having heard
something is cool but having first-hand experience with it. And even better
if you’re willing to help execute the migration.

Chris

Re: BOOLeans ;-)

[Łukasz Dywicki]

Not sure if it is a valid assumption, but if we have a single bit (bool) 
value in given address then getting 5 bools out of it is kind of odd. 
Shouldn't we just construct a request with coil:1:BOOL, coil:2:BOOL etc. 
to not confuse people more?
I know we can get multiple values through single modbus poll, but then 
it is still a range of coils rather than an array. Virtually it is a 
coil:1..5:BOOL and not coil:1:BOOL[5].


Best,
Łukasz


On 14.10.2022 15:34, Christofer Dutz wrote:

Hi Ji,

well … I know that you can theoretically interpret 8 digital inputs as a byte, 
but Coils in my understanding are usually directly mapped to digital inputs on 
the Modbus device. So a COIL is technically just a bit … so with 
“coil:1:BOOL[5], you’d be reading coil:1:BOOL, coil:2:BOOL, coil:3:BOOL, 
coil:4:BOOL, coil:5:BOOL. It would become “problematic if someone started 
reading coil:1:BOOL[5] and coil:3:BOOL[5] as he’d be reading stuff double. 
Wasn’t objecting this, just wanted to point it out.

I guess the reason your INT differs from BOOL-array is that you might be using 
a LittleEndian PLC and there two-byte values are read in a different order.

Does that help?

I really think we should be writing up how we expect different things to be 
read and then to ensure all drivers follow that schema.

Chris

From: jl hong 
Date: Friday, 14. October 2022 at 00:55
To: dev@plc4x.apache.org 
Subject: Re: BOOLeans ;-)
Hi, Chris.
I'm sorry to interrupt your trip.
1. Regarding "a coil is a single-valued boolean .. Not sure what the
offset means here?" issue, I just tried it and it works like any other data
type, but there are 2 small issues to deal with.
(1) When we read the INT type, it returns a binary sort of "AB CD", while
the BOOL type returns "BA DC", so we need to deal with the binary before
reading the BOOL.
(2) The Quantity needs to be added to Offset.

2. How to represent the offset and the number of arrays, I think it's fine,
as long as it's clearly described.

Christofer Dutz  於 2022年10月13日 週四 晚上10:10寫道：


Well, I guess mostly I‘ve seen it more treated like: If there’s no “..”
the number is the size of the array, … if there’s a “..” then the prefix is
the offset. And yes: the Golang approach is again very different to what I
have seen be used in industrial automation.

Chris

From: Sebastian Rühl 
Date: Thursday, 13. October 2022 at 09:06
To: dev@plc4x.apache.org 
Subject: Re: BOOLeans ;-)
In some language I saw that being used as ranges:

BOOL[5] would be one bool at index 5
BOOL[:5] would be 5 bools till index 5
BOOL[3:5] would be 3 bools from index 3 to 5
BOOL[2:] would be all bools from index 2
BOOL[:-1] would be all bools till the last index -1

So maybe I'm wrong, but when you write 5.3:BOOL[5] you mean
5.3:BOOL[:5], right?

Sebastian

On 2022/10/13 13:40:08 Christofer Dutz wrote:

Hi all,

seems we got a PR where someone implemented my proposal for handling

Booleans (
https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields
)

For Modbus in Go (https://github.com/apache/plc4x/pull/545)

I think we should probably finish some of the discussions on this and

document them in the project.


With the latest discussions on the Browse API and how to deal with

(muti-dimensional) arrays … I think probably a notation:


5:BOOL[3..8]

Would be better than:

5.3:BOOL[5]

What do you think?

Chris

Re: Profinet Driver - Multiple Devices

[Łukasz Dywicki]

Hey Ben,
I think it is a fair finding and proper pattern for all connections 
which end up with multiple participants on single connection.


Looking forward to see further evolution of that API cause it could form 
a pattern which can be later utilized in BACnet and CANopen drivers as 
well as Modbus over serial.


Cheers,
Łukasz

On 11.10.2022 16:15, Ben Hutcheson wrote:

Hi,

Just looking for some comments and feedback on the approach we're going
with the Profinet Driver.

As Profinet is a fieldbus, communicating to multiple devices at once is
fairly standard, however it makes it difficult with the current connection
string format to define multiple devices.

Using the local ip address of the driver in the target and moving the
device configuration to the parameters section would allow this though.
e.g. profinet:raw://{local ip address}?devices=[00:00:01:02:03:04,
00:00:01:02:03:05]=[[submodule1, submodule2],[submodule1,
submodule2]]

I've then encapsulated the connection to each device within a
ProfinetDevice class which handles opening and closing separate UDP
connections and receives messages from the common UDP port via a handle.
Setting up the connection to multiple devices then ends up being simple.

for (Map.Entry device :
configuration.configuredDevices.entrySet()) {
 device.getValue().onConnect();
}


Ben

Re: BACnet tests and doubts

[Łukasz Dywicki]

I do not plan work in this area since I am still stuck with
bacnet4j-wrapper I made few years ago.
First I need to catch up with 0.10 release and changes in plc4x browse
api in order to see if and how we could migrate functionality.

There are some complex parts in bacnet which will impact driver logic
ie. recognition of supported services, segmentation of requests,
optional nature of change of value (COV) on the device end not to
mention defined semantics of certain objects.
As an example - PLC4X API currently expects that driver itself is able
to tell developer if subscription is supported, but in case of bacnet
it is determined per device basis. One controller can support that,
other might not, hence usefulness of
plcConnection.getMetadata().canSubscribe() might be questioned.

Best,
Łukasz

czw., 6 paź 2022 o 11:54 Iñigo Angulo  napisał(a):
>
> ok, thank you Lukasz for the guide.
> if I can help here in the future, at least for doing tests or something, let 
> me know.
>
> best,
> iñigo
>
>
> - Mensaje original -
> De: "Łukasz Dywicki" 
> Para: "dev" 
> Enviados: Jueves, 6 de Octubre 2022 11:34:00
> Asunto: Re: BACnet tests and doubts
>
> BACnet handshake was not implemented and it worked only on PCAP transport.
> I was trying to do it a while ago (~2 years)
> https://github.com/apache/plc4x/tree/feature/bacnet-active, but back
> then it was not possible due to optional fields which were not handled
> properly. Now they are supported, but my changes are not compatible any
> more and have to be done from scratch.
>
> Long story short - currently bacnet driver is not an "online" driver.
>
> Best,
> Łukasz
>
>
> On 6.10.2022 11:26, Iñigo Angulo wrote:
> > Hi all,
> >
> > I started doing some tests with BACnet, and wanted to ask a question about 
> > using the driver. I am pretty newbie to this protocol, so hope this will 
> > make sense... :)
> >
> > I am using this project (https://github.com/bacnet-stack/bacnet-stack) to 
> > simulate a BACnet device on Linux. Using the server script, it creates a 
> > device with a UDP endpoint (port 47808) on my local network IP. I can see 
> > this endpoint using nmap or nc commands, so I would assume it is available 
> > and ready to receive requests.
> >
> > Then using PLC4X, I created a java main method to try to establish the 
> > connection to the device. The connection string looks as follows:
> >
> > String connectionString = "bacnet-ip:udp://192.168.0.93:47808";
> >
> > try (PlcConnection plcConnection = new 
> > PlcDriverManager().getConnection(connectionString)) {
> > if (!plcConnection.getMetadata().canRead()) {
> > System.out.println("This connection doesn't support reading.");
> > return;
> > }
> > ...
> >
> >
> > However, when running the code, I get the following exception "Active 
> > connections not yet supported":
> >
> > WARNING: An exceptionCaught() event was fired, and it reached at the tail 
> > of the pipeline. It usually means the last handler in the pipeline did not 
> > handle the exception.
> > org.apache.plc4x.java.api.exceptions.PlcRuntimeException: Active 
> > connections not yet supported
> > at 
> > org.apache.plc4x.java.bacnetip.protocol.BacNetIpProtocolLogic.onConnect(BacNetIpProtocolLogic.java:92)
> > at 
> > org.apache.plc4x.java.spi.Plc4xNettyWrapper.userEventTriggered(Plc4xNettyWrapper.java:203)
> > ...
> >
> > So, I saw there is this 'passive' booelan attribute that gets initiated as 
> > false, and have to admit Im pretty lost about where it is set... maybe the 
> > problem is related to the actual device? or is it something I am missing on 
> > the configuration of the connection?
> >
> > By the way, I am using the code from 'origin/rel/0.10' branch, getting the 
> > build as 0.10.1-SNAPSHOT
> >
> > Thank you in advance! (and sorry if is a misconception about using the 
> > protocol itself...)
> >
> > regards,
> > iñigo
> >
> >
> >

Re: BACnet tests and doubts

[Łukasz Dywicki]

BACnet handshake was not implemented and it worked only on PCAP transport.
I was trying to do it a while ago (~2 years) 
https://github.com/apache/plc4x/tree/feature/bacnet-active, but back 
then it was not possible due to optional fields which were not handled 
properly. Now they are supported, but my changes are not compatible any 
more and have to be done from scratch.


Long story short - currently bacnet driver is not an "online" driver.

Best,
Łukasz


On 6.10.2022 11:26, Iñigo Angulo wrote:

Hi all,

I started doing some tests with BACnet, and wanted to ask a question about 
using the driver. I am pretty newbie to this protocol, so hope this will make 
sense... :)

I am using this project (https://github.com/bacnet-stack/bacnet-stack) to 
simulate a BACnet device on Linux. Using the server script, it creates a device 
with a UDP endpoint (port 47808) on my local network IP. I can see this 
endpoint using nmap or nc commands, so I would assume it is available and ready 
to receive requests.

Then using PLC4X, I created a java main method to try to establish the 
connection to the device. The connection string looks as follows:

String connectionString = "bacnet-ip:udp://192.168.0.93:47808";

try (PlcConnection plcConnection = new 
PlcDriverManager().getConnection(connectionString)) {
if (!plcConnection.getMetadata().canRead()) {
System.out.println("This connection doesn't support reading.");
return;
}
...


However, when running the code, I get the following exception "Active connections 
not yet supported":

WARNING: An exceptionCaught() event was fired, and it reached at the tail of 
the pipeline. It usually means the last handler in the pipeline did not handle 
the exception.
org.apache.plc4x.java.api.exceptions.PlcRuntimeException: Active connections 
not yet supported
at 
org.apache.plc4x.java.bacnetip.protocol.BacNetIpProtocolLogic.onConnect(BacNetIpProtocolLogic.java:92)
at 
org.apache.plc4x.java.spi.Plc4xNettyWrapper.userEventTriggered(Plc4xNettyWrapper.java:203)
...

So, I saw there is this 'passive' booelan attribute that gets initiated as 
false, and have to admit Im pretty lost about where it is set... maybe the 
problem is related to the actual device? or is it something I am missing on the 
configuration of the connection?

By the way, I am using the code from 'origin/rel/0.10' branch, getting the 
build as 0.10.1-SNAPSHOT

Thank you in advance! (and sorry if is a misconception about using the protocol 
itself...)

regards,
iñigo

Re: Account Application for PLC4X Project Lab

[Łukasz Dywicki]

You still can play with plc4x api by using cheap modbus devices 
available everywhere or running modbus tcp simulator.. or running plc 
simulator we have in our codebase.


You do not need physical device for start.

Best,
Łukasz

On 1.10.2022 17:37, Christofer Dutz wrote:

Unfortunately we no longer have that. Well... I do have the lab, but I just 
can't provide access to it anymore.

Should probably take that page offline.

Chris

Holen Sie sich Outlook für Android

From: wuwenqing (A) 
Sent: Thursday, September 29, 2022 1:18:44 AM
To: dev@plc4x.apache.org 
Cc: Zhangxiangyong 
Subject: Account Application for PLC4X Project Lab

Hello PLC4X project team:
I am a R engineer from China Huawei Company. Now I am learning the PLC4X 
project code. In order to access the hardware of the IoT laboratory, I would like 
to apply for an account and hope for approval.
thank you very much.

Re: [PROPOSAL] Implement a Java GUI application for browsing PLCs with PLC4X

[Łukasz Dywicki]

I agree that electron is a great tool.
It gives you all the problems you had with desktop combined with all 
complexity of modern web development. ;-)


If goal is getting data from protocol available via serial port then 
electron is an unnecessary complication. You need to launch local server 
with an API to let gui receive data (assuming gui is in js or similar).
Given that we don't have many UI folks who do webdev on daily basis I am 
afraid we could be easily burred by that part.


Sure, without trying we just speculate, so anyone who wants promote 
specific tech is welcome to start working on the thing. :)


BTW for further comparisons, I recall there is also a wx-widgets toolkit 
which is cross platform.


Cheers,
Łukasz

On 23.06.2022 18:31, Lukas Ott wrote:

What about https://cordova.apache.org/ and creating an Electron App?

https://cordova.apache.org/docs/en/11.x/guide/platforms/electron/index.html

So we can deploy easily to all kinds of platforms?

Example for a very successful Frontend application:
https://github.com/jgraph/drawio

Interesting discussion a few years ago:
https://twitter.com/tuxtor/status/1167454864932319232

-> Electron is de facto the standard for Desktop Applications at least at
the moment.

https://medium.com/the-web-tub/electron-on-cordova-29ede5d6d789

https://www.reddit.com/r/javahelp/comments/lrg2ho/web_app_vs_java_fx_vs_electron_js/

My five cents to this conversation ;-)

Luk

Am Do., 23. Juni 2022 um 16:19 Uhr schrieb Sebastian Rühl 
:



I would vote doing it as a terminal application with tcell :D

https://github.com/gdamore/tcell
https://github.com/gcla/gowid

good example for that is termshark

- Sebastian

On 2022/06/23 13:47:29 Christofer Dutz wrote:

Hi all,

Great to see this discussion here :-)

Well, I agree that going down the lane of basing something on NetBeans,

Eclipse, IntelliJ, VSCode makes the tool a bit too big and complicated.
Integrating something based on Eclipse into our build also would add
Nightmares to that.


I probably would have chosen Java/Kotlin with JavaFX ... but I would

say, those who actually work on it should choose what they are comfortable
with.


So perhaps we could see who's actually interested, willing and able to

help on the coding and then these people should discuss how to implement
it. I'll be available as a "Mentor" if any help is needed in integrating
that into the build or if PLC4X related help is needed.


Chris


-Original Message-
From: Stephen Snow 
Sent: Donnerstag, 23. Juni 2022 15:31
To: dev@plc4x.apache.org
Subject: Re: [PROPOSAL] Implement a Java GUI application for browsing

PLCs with PLC4X


Truly,
To scaffold an application that can be rapidly utilized in Java/Kotlin I

would strongly recommend Quarkus from https://quarkus.io/. It likes to
use the GraalVM and readily can build out to native or native in container.
It can be deployed ootb in development mode with ci happening as you
develop in netbeans say.


Just my 2c worth.

Regards,
Stephen
On Thu, 2022-06-23 at 14:59 +0200, Łukasz Dywicki wrote:

I been wrapping head around this as I had a necessity to watch CANopen
traffic decoded by plc4x. I ended up building fairly basic web page
which displayed most recent frames (so I could stay with local
socketcan transport), yet it was far from useful or portable. Recently
I also did struggle a lot with bloody modbus. My usecases are often
focused on making the commissioning to generate further software
configuration.

My little research in topic of desktop applications ended up at javafx
which allows to make it small and compile to native binary thanks to
graal. My experiences with RCP platforms are rather bad (I did some
small Eclipse RCP projects), even if I have no issues with OSGi.
Problem
I see in RCP platforms is sparse development documentation, I also
perceive both Eclipse RCP and Netbeans as focused mainly on organizing
navigation while strongly depending on UI frameworks (jface/swt or
swing/awt). Effectively you still need to build tables and so on, but
with much more overhead.
Please do not take above too seriously in context of Netbeans, I don't
know much about it and its flexibility. I don't know how to build it
with Maven, hence it feels strange.
For the Kotlin stuff and frameworks there - I can say that any UI
project which Google is pushing is a red flag to me. Looking at GWT,
Angular 1.x (I used both) I simply fear that they can step back from
"experiment" after a year or two leaving everything to the community.
I
looked at kootlin and javafx a while ago and there is not much
happening there. I don't know if is because of maturity, javafx issues
or shift to other UI approaches.

As I had no time to work on it I just postponed that to a future.
Yet, I
still dream from time to time about proper "fieldbus.app". ;-)

Cheers,
Łukasz

On 23.06.2022 14:46, Michal Harakal wrote:

Hi,

I would be also interested in, having a strong opinion on technolog

Re: [PROPOSAL] Implement a Java GUI application for browsing PLCs with PLC4X

[Łukasz Dywicki]

I been wrapping head around this as I had a necessity to watch CANopen 
traffic decoded by plc4x. I ended up building fairly basic web page 
which displayed most recent frames (so I could stay with local socketcan 
transport), yet it was far from useful or portable. Recently I also did 
struggle a lot with bloody modbus. My usecases are often focused on 
making the commissioning to generate further software configuration.


My little research in topic of desktop applications ended up at javafx 
which allows to make it small and compile to native binary thanks to 
graal. My experiences with RCP platforms are rather bad (I did some 
small Eclipse RCP projects), even if I have no issues with OSGi. Problem 
I see in RCP platforms is sparse development documentation, I also 
perceive both Eclipse RCP and Netbeans as focused mainly on organizing 
navigation while strongly depending on UI frameworks (jface/swt or 
swing/awt). Effectively you still need to build tables and so on, but 
with much more overhead.
Please do not take above too seriously in context of Netbeans, I don't 
know much about it and its flexibility. I don't know how to build it 
with Maven, hence it feels strange.
For the Kotlin stuff and frameworks there - I can say that any UI 
project which Google is pushing is a red flag to me. Looking at GWT, 
Angular 1.x (I used both) I simply fear that they can step back from 
"experiment" after a year or two leaving everything to the community. I 
looked at kootlin and javafx a while ago and there is not much happening 
there. I don't know if is because of maturity, javafx issues or shift to 
other UI approaches.


As I had no time to work on it I just postponed that to a future. Yet, I 
still dream from time to time about proper "fieldbus.app". ;-)


Cheers,
Łukasz

On 23.06.2022 14:46, Michal Harakal wrote:

Hi,

I would be also interested in, having a strong opinion on technology stack, but 
fully open to design and function.

My suggestion is writing a Desktop App with Kotlin Jetpack Compose for Desktop:

Props:
* modern, state of the art, way to write reactive UI (natural way to implement 
unidirectional data flows architectures)
* JVM target
* open source, backed by Google And Jetbrains (they use it in their critical 
products)
* Kotlin provides 1A class interoperability support with Java and JVM
* since Jetpack Compose is originally created and used by Android, you can have 
an Android App out of the box, with little effort
* integration with Jetbrains Intellij
* even if you don't know Jetpack Compose Framewrok, you can contribute too with 
your Java/Kotlin skills imedialtely on domain/bussines etc. parts of code ..
* easy to learn
* with multiplatform support are native apps with their native UI frameworks 
(e.g. iOS)

Cons:
* Still in Alpha
* backed by Google and Jetbrains
* Kotlin is probably not the number one programming language here


Best regards,
Michal

Christofer Dutz  hat am 23.06.2022 10:55 geschrieben:


Hi all,

Again, I was in need of a simple application to simply monitor the values on a 
Modbus device (I’m currently configuring my Wago PFC200 Modbus Slave interface).
I could use stuff like the “Modbus Poll” GUI tool, but my trial expired and I’m 
not willing to pay 130€ for this limited functionality.

So, I thought, it would be an awesome addition to PLC4X if we had some sort of 
GUI application, that uses the Discover functionality to find possible PLCs and 
list them in a tree view.
If the use double clicks on one of these connections, it connects and possibly 
executes the Browse functionality and lists up what it finds.

I know that I could simply start working on something like that, but I thought 
this would also be a great thing for someone else to implement as it doesn’t 
require too deep knowledge of PLC4X internals.

And I suck at building beautiful UIs :-)

Anyone interested?

Chris

Re: Subscription Simulation

[Łukasz Dywicki]

FYI, I moved the decorator stuff (as well as osgi related modules) to 
separate repo:

http://github.com/connectorio/plc4x-extras/

I made first release, so it will be in maven central in coming hours.

You can pull it via maven coordinates:

  org.connectorio.plc4x.extras
  org.connectorio.plc4x.extras.decorator
  0.8.0


Difference between this and scrapper is complexity - scrapper is a 
separate executable while extras I link are supplements to plc4x apis 
which could be embedded in your thing.


Best,
Łukasz


On 1.06.2022 19:24, Andy Grebe wrote:

Thanks Ben, I'll check this out.

On Sun, May 29, 2022 at 5:46 PM Ben Hutcheson  wrote:


Andy, I'm not sure if you're aware but there is a scraper
https://plc4x.apache.org/users/tools/scraper.html which you can use to
continuously poll data even when the driver doesn't support subscriptions.

On Mon, May 30, 2022 at 7:42 AM Łukasz Dywicki 
wrote:


The simulation of subscriptions require probably more options than just
"event" or so. You probably need to configure higher frequency for
polling and ideally manage thread pool for that independently from
netty/connection itself to have control over its reliability.

If I could have one suggestion.. try making it via decoration of
connection/driver. It gives you most of the flexibility without going to
close with driver.

I made some decorator support earlier. Base structure is here:



https://github.com/ConnectorIO/connectorio-addons/tree/master/bundles/org.connectorio.plc4x.decorator/src/main/java/org/connectorio/plc4x/decorator

example of "retry" logic for connection read/write/subscribe:



https://github.com/ConnectorIO/connectorio-addons/blob/master/bundles/org.connectorio.plc4x.decorator.retry/src/main/java/org/connectorio/plc4x/decorator/retry/RetryDecorator.java


If you find it useful for your thing we can move it into develop and
maintain together.

Best,
Łukasz


On 29.05.2022 23:34, Andy Grebe wrote:

hmmm...  I should probably push those CIP changes first :)

On Wed, May 25, 2022 at 10:14 AM Christofer Dutz <

christofer.d...@c-ware.de>

wrote:


Hi Andy,

It still is our plan :-)

Just nobody did it yet ;-)

Chris

-Original Message-
From: Andy Grebe 
Sent: Mittwoch, 25. Mai 2022 15:58
To: dev@plc4x.apache.org
Subject: Subscription Simulation

  From the Getting Started guide,  So if a protocol doesn’t support
subscription based communication it is our goal to simulate this by

polling

in the background so it is transparent for the users.

Has this been implemented for any of the protocols?

Thanks,
Andy

Re: Subscription Simulation

[Łukasz Dywicki]

The simulation of subscriptions require probably more options than just 
"event" or so. You probably need to configure higher frequency for 
polling and ideally manage thread pool for that independently from 
netty/connection itself to have control over its reliability.


If I could have one suggestion.. try making it via decoration of 
connection/driver. It gives you most of the flexibility without going to 
close with driver.


I made some decorator support earlier. Base structure is here:
https://github.com/ConnectorIO/connectorio-addons/tree/master/bundles/org.connectorio.plc4x.decorator/src/main/java/org/connectorio/plc4x/decorator
example of "retry" logic for connection read/write/subscribe:
https://github.com/ConnectorIO/connectorio-addons/blob/master/bundles/org.connectorio.plc4x.decorator.retry/src/main/java/org/connectorio/plc4x/decorator/retry/RetryDecorator.java

If you find it useful for your thing we can move it into develop and 
maintain together.


Best,
Łukasz


On 29.05.2022 23:34, Andy Grebe wrote:

hmmm...  I should probably push those CIP changes first :)

On Wed, May 25, 2022 at 10:14 AM Christofer Dutz 
wrote:


Hi Andy,

It still is our plan :-)

Just nobody did it yet ;-)

Chris

-Original Message-
From: Andy Grebe 
Sent: Mittwoch, 25. Mai 2022 15:58
To: dev@plc4x.apache.org
Subject: Subscription Simulation

 From the Getting Started guide,  So if a protocol doesn’t support
subscription based communication it is our goal to simulate this by polling
in the background so it is transparent for the users.

Has this been implemented for any of the protocols?

Thanks,
Andy

Higher level device API for drivers - stepping above a plc field

[Łukasz Dywicki]

Hello,
I been thinking of issues I so far found within plc4x api and one of 
them is field-centric approach which bounds client to think in the same 
way. Yet, some protocols think in different categories and there 
field-centric work turns out into a nightmare.


For example within CANopen it is possible to read an variable length 
array of values through SDO transfer (ie. object 0x5000). Yet, in order 
to do that using plc4x apis it is necessary to construct a first call 
(0x5000/0x0) which reads array length and then goes over sub-indexes 
(0x5000,0x1..N). This is not a big burden, but as soon as same structure 
is used across multiple places amount of code to orchestrate array 
retrieval grows. More over, I think that everyone who will get into 
CANopen and SDO read outs will sooner or later copy this logic to his code.
I thought if driver could get it better, but I don't think it would 
without .. object dictionary which is specific to CANopen. Not sure of 
other protocols, as they seem to be rather fine with field level access, 
but I don't think that this measure fits all is right. Looking at more 
complex protocols such as BACnet it is indeed possible to make a client 
which rely on fields, but it will turn caller code into a mess forcing 
further structuring of layers above plc4x just to reflect protocol 
philosophy. On other hand we have a M-Bus which in most of the cases 
works by returning all device measurements at one shot breaking the 1:1 
mapping between request and reply item. We haven't made a consensus how 
it could be addressed, but to me this protocol (as well as WM-Bus) is 
not well fit to keep above contract.


Because of rather bad code I made in 2020 while working on first CANopen 
binding for openHAB I started to re-structure it and improve its 
internal design in 2021. A bit of time have passed and I am again in a 
place where I don't think my work back then was going into right 
direction. First of all, I extracted CoNode, CoConnection and several 
more interfaces, but still at interaction level it does not involve 
object dictionary describing device abilities which is crucial in quick 
bootstrapping of integration. As I am preparing myself to another 
attempt to untie connectorio canopen binding code from specific vendor 
flavor I had to implement, I am back to the problem of 1) where to put 
higher level API 2) how to structure it.
While I currently do not running bacnet not profinet driver from plc4x I 
do smell very similar troubles there, especially with bacnet objects 
(ie. schedules) and profinet configs which reflect GSDML and other 
descriptors out there. Obviously we can always make everything a field, 
but will it make a sense?


_just an idea (tm)_
My brief thinking is about possibility to define an 
"ExtendedDriver" interface (rq - request container, rp - response 
container), which would provide us a generic purpose request/response 
logic as well as subscription stuff. I am sure it will be a bunch of 
work, however in some ways this might feel easier to implement than 
mapping everything to fields and back. This could be compared to a 
stored procedure call within JDBC api which is usually vendor specific. 
Caller of such procedure usually has to handle result according to 
database provider.
In our case through definition of request/response container we could at 
least enforce some basic contract between various equipment.
It would let us also to define a higher level types (subset of PlcObject 
convertible to a PlcStruc's?) to interact:


ExtendedDriver extendedDriver;
// assuming CompletableFuture as outcome
// maybe request could optionally have a SDO entry mapper?
extendedDriver.read(new CANopenSDORequest(0x5000, CANopenType.ARRAY))
  .whenComplete((CANopenResponse r, Throwablee ) -> {
// CANopen specific logic, but well, it is interacting with CANopen
// and this code knows what to do with it
MappedData[] data = r.getArray(/*maybe SDO mapper here?*/);
// CANopenObject o = r.getPlcObject() ??
  })

I don't really have any time frame nor pursue to work on that topic, 
however I wanted to bring it up as I feel we could improve (simplify 
till some degree) device interaction in some cases. Maybe not all, but 
these which are more "object oriented" for sure. I want also to give 
myself enough of time to think of how to make a first attempt without 
making it too dumb nor too complicated.
Above, I think, could also be used for discovery of symbols or objects 
through connections which rely on the same transport as driver itself. 
For example Beckhoff symbols are just read from index within TCP 
connection we make to PLC. Also, if we look at udp discovery in BACnet, 
its just one of operations defined in protocol. Both give us different 
outcome, yet they do work over connection we already made. Obviously it 
can be mapped through connection metadata. While it would fit into this 
API (which is not used anywhere I guess), this approach also 

Re: Need help for canopen in kafka

[Łukasz Dywicki]

Hey Naveen (hope its fine),

I can't provide you much of the input in regard to kafka, but I can 
guide you, at least briefly, on details.


1. Kafka component in PLC4X is just an PLC4X api caller, so you need to 
configure it. It works independently of the driver. Please check 
examples, I think it might be a "kafka connect" thingy.

https://plc4x.apache.org/users/integrations/apache-kafka.html
Connection properties mentioned in webpage can be found here:
https://github.com/apache/plc4x/blob/v0.9.1/plc4j/integrations/apache-kafka/config/plc4x-source.properties
2. CANopen driver is a CANbus "client" which is capable of sending 
requests and listening to bus communication. For more detailed docs on 
query syntax please visit:

https://plc4x.apache.org/users/protocols/canopen.html
Please be aware that this driver is not a full blown CANopen master so 
you need to set them in automatic boot mode. PLC4X does not verify and 
assure that state of nodes is fine for SDO/PDO transfer.


Additional note - plc4x source processor does not support subscription 
API which is most effective for CANopen. You might need to try first 
with SDO (request-response) and see if everything assembles into a 
working pipeline. Please keep in mind that CAN support so far is limited 
only to linux platforms.


Best,
Łukasz

On 9.05.2022 13:35, Reddy Naveenkumar wrote:

Hi Team,

I am doing some feasibility study, can you please provide some documents
related to canopen in kafka.

Best Regards,
Naveen Kumar.R.

Re: Scope of using PLC4x as simulated driver for PLC projects

[Łukasz Dywicki]

Hey Chris,
Sorry for mixing authorship. I didn't check simulator since a while, 
hence was not certain if its up to date.


My point is about reusing network layer which PLC4X provides in order to 
simulate a device. This is how you normally interact with PLC so it is a 
natural way to make an "integration test" at this level. It is not 
beyond typical BDD which is more about defining scenarios. How they are 
actually executed depend on a BDD toolkits and how they integrate with 
test or build environment.
I get that scope of Peter work is to emulate a PLC runtime, that's why I 
mentioned IEC grammars (so he can somehow parse or compile entire 
program), which is the hardest part.
Once program can be interpreted and executed (ie. by turning ST into 
LLVM and firing graalvm or c runtime or simply running it with one of 
existing tools such as openplc), the remaining part will be possible 
after proper adoption of code generated from MSpec.
Looking at amount of "soft plc" projects I have no doubts that its 
possible. Its just matter of how much time and simplifications we can 
accept.
I agree that we don't have a capacity nor will to dive into even more 
specific parts of how PLCs work. If somebody else has such interest I 
will definitely look for results and see if we could improve our part 
afterwards.


Best,
Łukasz

On 4.05.2022 09:09, Christofer Dutz wrote:

Hi Lukasz,

I intentionally didn't mention the simulator, as I understood Peter, that he's 
looking for something to run his PLC programs on for testing. Yes, the 
simulator we have could be used to simulate being a PLC, but it can't actually 
simulate the PLC itself. That's not the scope of that thing. I think 
implementing the internal stuff needed to create a simulator where you can 
deploy a program from TIA Portal is totally unthinkable, considering how many 
different PLCs are out there.

Perhaps we should name it differently in order to manage expectations. 
"plc-mock"?

And our simulator was actually created by me and it's up-to-date and we just 
recently checked that it still works with the StreamPipes folks, as they were 
looking for something to use in their StreamPipes integration-tests.

Chris

-----Original Message-
From: Łukasz Dywicki 
Sent: Dienstag, 3. Mai 2022 22:47
To: dev@plc4x.apache.org
Cc: pe...@petersaxton.uk
Subject: Re: Scope of using PLC4x as simulated driver for PLC projects

Hey Peter, welcome on mailing lists. First of all thank you for showing a 
interest in a project and bringing interesting topic!

Just to oppose a little bit what Chris says, I would say there is no real 
blocker for trying to do a PLC simulator within PLC4X. We do (or
did) have a S7 simulator in sandbox already. It was built a while ago by Julian 
based on netty tcp server and I think 0.6 structures, so it might be a little 
bit behind of what we currently have in a develop branch.

Technically speaking what you need in most of the cases is launching a TCP 
server (in case of ADS/Modbus/S7) or a serial receiver (Modbus RTU/till some 
degree CANopen) and answering requests which come over such communication 
channel. If you get closer to basic fieldbus like a Modbus RTU or CANopen 
difference between sending a request and answering it is not that large.
Few remarks - we currently do not have any support beside mentioned sandbox 
project. If you decide to do such thing, it will be a far away from a realtime, 
yet TCP/UDP stuff involving IP routing by definition is not! You will still 
have to invest a ton of time in order to mimic a complete PLC behavior. I 
suppose it might be problematic to keep it up with manufacturer tooling, simply 
cause they can share some libraries or specifications unseen by any of us. Also 
a device behavior can change with firmware upgrade, so you have to keep a close 
look on that.
If you can sacrifice realtime requirement which is often crucial to 
certification, live with above simplifications and caveats, then infrastructure 
available in PLC4X will serve you better than any other open source components 
available out there.

Before we go too optimistic, a fairly common problems is how devices react on 
read/write operations. Each brand does it in an unique way, some models have 
extended functionality, plus each device report errors differently. There is 
also handling of parallel/overlapping requests which we handle partially even 
in client side.
ADS for example has an internal notion of an routing table which is somehow 
associated with communication peer, it has support for read single and read 
multiple addresses, it has also support for subscriptions which you have to 
coordinate. If you are not afraid of it, the communication structures will be 
provided by MSpec. :)

I think that this is still a major advantage of MSpec approach and code 
generation framework provided by PLC4X which awaits more use cases.
MSpec gives us a symmetric read/write operations which we prove thr

Re: Scope of using PLC4x as simulated driver for PLC projects

[Łukasz Dywicki]

Hey Peter, welcome on mailing lists. First of all thank you for showing 
a interest in a project and bringing interesting topic!


Just to oppose a little bit what Chris says, I would say there is no 
real blocker for trying to do a PLC simulator within PLC4X. We do (or 
did) have a S7 simulator in sandbox already. It was built a while ago by 
Julian based on netty tcp server and I think 0.6 structures, so it might 
be a little bit behind of what we currently have in a develop branch.


Technically speaking what you need in most of the cases is launching a 
TCP server (in case of ADS/Modbus/S7) or a serial receiver (Modbus 
RTU/till some degree CANopen) and answering requests which come over 
such communication channel. If you get closer to basic fieldbus like a 
Modbus RTU or CANopen difference between sending a request and answering 
it is not that large.
Few remarks - we currently do not have any support beside mentioned 
sandbox project. If you decide to do such thing, it will be a far away 
from a realtime, yet TCP/UDP stuff involving IP routing by definition is 
not! You will still have to invest a ton of time in order to mimic a 
complete PLC behavior. I suppose it might be problematic to keep it up 
with manufacturer tooling, simply cause they can share some libraries or 
specifications unseen by any of us. Also a device behavior can change 
with firmware upgrade, so you have to keep a close look on that.
If you can sacrifice realtime requirement which is often crucial to 
certification, live with above simplifications and caveats, then 
infrastructure available in PLC4X will serve you better than any other 
open source components available out there.


Before we go too optimistic, a fairly common problems is how devices 
react on read/write operations. Each brand does it in an unique way, 
some models have extended functionality, plus each device report errors 
differently. There is also handling of parallel/overlapping requests 
which we handle partially even in client side.
ADS for example has an internal notion of an routing table which is 
somehow associated with communication peer, it has support for read 
single and read multiple addresses, it has also support for 
subscriptions which you have to coordinate. If you are not afraid of it, 
the communication structures will be provided by MSpec. :)


I think that this is still a major advantage of MSpec approach and code 
generation framework provided by PLC4X which awaits more use cases. 
MSpec gives us a symmetric read/write operations which we prove through 
serialization unit tests. This is unseen in most of libraries as they 
usually focus on one of the sides - either a client/master or 
server/slave structures and handle only half which is needed by them. A 
prime example could be a S7 client which does a request serialization 
and reply deserialization or S7 server which does request serialization 
and response serialization. Code generated by PLC4X handles both ways. 
Even if we miss a support for making server side framework, its 
something you can definitely do on top of what PLC4X provide.
An interesting benefit you could get from relying on PLC4X is 
possibility to make a test of different communications for assumed 
simulation logic. If you find a way for example to write a PLC program 
in some portable way, then by mapping such program inputs and outputs to 
PLC specific communication semantics you get a very nice training suite. 
If you search for ie. ANTRL IEC 61131-3 you will find a bunch of grammar 
files allowing to parse structured text programs. From there you "just" 
need to make interpreter working with one of languages supported by 
PLC4X code generators.
Making a partial toolkit, even for a single brand/product line, is a lot 
of work and code to be made. This code is potentially hard to maintain 
due to various firmware versions, yet nothing really blocks you from 
trying. Do your thing and report your findings if you wish. I am eager 
to hear your feedback. I believe with your work we could improve our 
client side implementations too!


Cheers,
Łukasz

On 3.05.2022 13:55, Christofer Dutz wrote:

Hi Peter,

well simulating a real PLC generally would totally be out of scope of PLC4X. I 
was more referring to the code to extract the program from a PLC and to deploy 
it somewhere (like in a simulator or in case of Codesys you could run the 
runtime on a test-server). But there are simulators out there. Usually, the PLC 
vendors have them. Unfortunately, they usually are not for free. But I know 
Siemens has various simulators to which you could deploy your program and then 
interact with PLC4X.

Well, I guess you would need to find out how to make a software like TIA portal 
believe your application is a S7 PLC and then need to implement the parts of 
the protocol, that we haven't implemented yet. As S7 doesn't have a public 
spec, you'll have to reverse engineer most of it. And another problem will be 
that newer S7 

Re: [DISCUSS] how to read bool and bool-arrays?

[Łukasz Dywicki]

Hello Chris, Myhongk, Stephen,
I would say.. watch how others do it.. openHAB modbus binding for 
example has an additional parameter of "offset", so you can read status 
bit and ie. float value on remaining 15 or 31 bits separately.
While I haven't seen such strange encoding of floats (but I saw it in 
CANopen), the bit encoded alarm flags are quite popular. Especially in 
modbus land.

I see two ways to approach problem:
1) force values to be read as an bit array, then you can adjust offset 
in a caller code or define offset.
2) define an offset parameter for fields, then we probably need to think 
how to align that.
Bit is essentially a boolean so it should fly always without touching 
how booleans work. I found it earlier that booleans are read as kind of 
bitset, but that was (I think) aligned by Chris sometime ago.


Cheers,
Łukasz

On 22.04.2022 13:18, Christofer Dutz wrote:

Hi Stephen,

Well, it sort of touches that area ... generally big endian/little endian 
handles the byte order ... so this would more have an effect on the order of 
the bytes inside the register too. In general I would love to handle BE/LE as 
an option on the connection string. So per default it's Big Endian (As the spec 
says), but you could switch to LE, if you need to.

Chris



-Original Message-
From: Stephen Snow 
Sent: Freitag, 22. April 2022 12:57
To: dev@plc4x.apache.org
Subject: Re: [DISCUSS] how to read bool and bool-arrays?

Hi Chris and Myhongk, et al

Depending on the processor (this would include embedded IIOT devices) they 
could be big or little endian, which may complicate matters for the modbus 
driver. Being able to set this as a parameter when using the driver in an app 
being built which may talk to many modbus devices of either endian arrangement 
would likely be beneficial. Byte swapping in PLC land is common in 
communication between PLC's/PC's and periphery devices or other control 
elements.

I don't know if that is what you're referring to, but it sure sounds like 
endian issues I have encountered in the past (and still today).

Be well,

Stephen
On Fri, 2022-04-22 at 10:26 +, Christofer Dutz wrote:

Hi all,

Myhongk just brought up an issue in the Modbus driver, which I think
could probably also come up in other protocols.

When reading a BOOL or BOOL[] the driver generally reads chunks of 16
bits (words). Now we need to define how we count the bits.

Currently when reading a simple BOOL we do this (0 = skipped, 1 =
read):

 0001

So, the least significant bit is the value and the ones before are
skipped.

When reading an array, we currently start at the end. So reading
BOOL[6] would be this:

1100 

In this case we start at the most significant bits.

Both variants have its logic and it's downsides.

Downside by starting at the least significant bits is as soon as we
read more than 16 bits.
So, if we read BOOL[19] we'd probably have this

   0XXX

Where the indexes in the array would probably be:

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0   X X X X X X X X    X X X X
X 18 17 16

Or would it be different?

Another option would be to start at the end of the last word read and
to count "from right to left"


If we start at the most significant bits, it would make things easier
for multiple elements, as we'd have this for BOOL[19]:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 X X X X X X X X
X X X X X

But we would have only read the register value: 32768 or 0x8000 as
"True".


Would be cool to know what's the default industry way to do thins (I'm
sort of expecting an "it depends").
Possibly we could make it configurable (Which would complicate things
a bit).

Another thing is ... in S7 we can address parts of a byte as BOOL by
using a Bit address ... would it be cool to extend the Modbus to allow
this too?

So something like this would work:

51.4:BOOL[3]

Which would return (assuming we start counting at the most significant
bit):

X X X X X 1 2 3    X X X X X X X X


Feedback highly appreciated :-)

Chris

Re: [DISCUSS] Rename "modbus" to "modbus-tcp"?

[Łukasz Dywicki]

There are multiple things which have M and Bus in name. Primary 
candidate would be M-Bus which I saw called "mb" in SKU codes.


Best,
Łukasz

On 10.03.2022 18:58, Cesar Garcia wrote:

Hi everyone,

+1,

Why not use the shorter name like "mb-tcp" , etc.?

Best regards,

El jue, 10 mar 2022 a las 11:07, Otto Fowler ()
escribió:


  +1, this is in my experience how these “drivers” used to be presented in
scada/hmi apps



From: Christofer Dutz 

Reply: dev@plc4x.apache.org  
Date: March 9, 2022 at 09:19:33
To: dev@plc4x.apache.org  
Subject:  [DISCUSS] Rename "modbus" to "modbus-tcp"?

Hi all,

I'm currently working on the modbus RTU stuff ... as in general the
protocols are referred to modbus-tcp, modbus-rtu und modbus-ascii, I would
like to rename the "modbus" to "modbus-tcp" ... While modbus-tcp will not
be many variants, will the modbus-rtu and ascii also be available as
"modbus-rtu:tcp" if a tcp tunnel is used.

What do you think?

Chris

Re: [DISCUSS] Rename "modbus" to "modbus-tcp"?

[Łukasz Dywicki]

Why not keeping modbus as protocol family, encoding as option with 
transport as part of URI?


Full uri would look like modbus::.

Then defaults could be:
modbus:serial:/ => rtu, same as modbus:rtu:serial:/
modbus:ascii:serial:/ => ascii over serial
modbus:tcp:/ => tcp
modbus:rtu:tcp:/ => rtu traffic tunneled over TCP socket

I know we have generated drivers but clearly we have a whole bunch of 
logic which is same no matter which encoding and transport is being 
used. Isn't it?
We probably need to adjust driver base for that, but that's possible 
with work we made with custom protocol stack which was needed for CAN.
Above way keeps us away from making a separate variant of driver for 
each case as long as protocol logic is same across them. I didn't look 
at implementations so I don't know if there are major differences 
between rtu over tcp and rtu itself, but that's other thing.


Best,
Łukasz

On 9.03.2022 19:29, Ben Hutcheson wrote:

-0

Having an alias for modbus-tcp as modbus would probably be good practice,
but hey if no one complains then go for it.

Currently the modbus-tcp also supports udp, it would look funny as
modbus-tcp:udp
I haven't actually seen it over udp but apparently they're out there.

Modbus+ should definitely be ignored. It is a proprietary protocol by
Schneider which uses it's own ASIC.
The Quantum PLC platform, I believe were the last ones that had it by
default, it also wasn't commonly used for most installations.

Ben

On Thu, Mar 10, 2022 at 3:13 AM Niclas Hedhman  wrote:


On 2022-03-09 17:07, Christofer Dutz wrote:

Hi Lukas,

I think that Modbus+ is a completely different thing. Seems to be
related to routing of Modbus traffic ... haven't looked too deep at
it.


I think it was an attempt to modernize Modbus for the 21st century, but
I have not seen any devices on the field with it. I suggest it can be
ignored.


 From the Spec side there are 3 variants:
- Modbus TCP
- Modbus RTU
- Modbus ASCII


Yes, that is the norm. Sometimes written Modbus/RTU or Modbus/TCP.



In general Modbus RTU and ASCII are sort of the same (Serial) ... the
main difference is the encoding of the payload and the termination of
frames. That's why I'll leave the ModbusSerialAdu as topmost packet in
both Modbus RTU and ASCII, as the difference is handled on the level
between the transport and the driver.


Practically all Modbus devices on RS-485 supports RTU, and a huge number
of them supports ASCII as well. But the only times I have seen Modbus
ASCII used, is long ago (1980s ?) with hand terminals where astute
operators entered the arbitrary packets by hand. Landis followed
that "fashion" and also had a line-by-line, near-human operatable,
protocol format (with CRC for computers, and without CRC if typed by
hand).
That skill slowly disappeared as hand terminals and/or troubleshooting
software became more sophisticated and hid such low-level stuff and
typically just run RTU mode. I doubt anyone would truly miss ASCII if it
is not available. OTOH, basically just encoding difference.


Please correct me if I'm wrong,


You got it right.


Niclas

Re: New feature: Protocol Versions

[Łukasz Dywicki]

This is fair point and I guess we reached place where we need to start 
handling it, isn't it?


Currently all negotiations we have end up in "protocol logic" which 
should handle that, so implementer must handle that. However if we end 
up with two protocol versions where one requires some extra data, how 
shall we handle that? Shall we have two separate protocol logic 
implementations or find a way to cope with that in single one? If so, 
who is responsible for managing type creation? I guess that S7 stuff is 
close to that case, especially after insane amount of work Cesar put in 
it on subscriptions. Not only that subscriptions become conditional, but 
also some of the structures I think are specific to bigger PLCs.
There are many questions and I believe first implementation you working 
on will show where we have gaps which needs to be filled up. Also we 
don't have much of server stuff on our end, beside simulator Julien did 
some time ago, so client part was a bit easier to get.
I'd say that for some of wire level operations we could have a "type 
factory" and "type builder" (both likely to be generated) whereas first 
would return builder for specific protocol version and later could 
return  structures specific for proto V1 or V2 and so on. Looking on how 
much crap we sometimes need to put in protocol logic to construct each 
frame it feels so wrong.
Guess that by this way we could go a little bit closer to Sebastian's 
idea of generating wrappers and flows leading us towards taking ower 
universe. :-)


Cheers,
Łukasz


On 28.01.2022 13:02, Christofer Dutz wrote:

Hi all,

when working on the "plc4x" protocol, Sebastian brought up a good point: The 
protocol I'm implementing might need changes in the future ... how do we ensure to 
support multiple versions of a protocol?

So, we extended the Protocol interface with a "getVersion()" (defaults to 
returning an empty optional).
The code generation now allows providing a "protocolVersion" tag to the 
execution.

If a protocol module defines a version, you need to specify the version to use 
(even if there is only one). If the protocol doesn't support versions, you 
shouldn't supply it.

So far it generally shouldn't have any effect on any of the existing protocols 
and drivers, but we'll be extending the code generation to generate the classes 
in different packages (One more level between the protocol-name and the variant.

Chris

Re: [DISCUSS] Extend PlcDriver with "supportedTransports"?

[Łukasz Dywicki]

Chris by accident sent answer to me (we both love Thunderbird for that). ;-)

There is a bit of risk with listing all transports as for modbus as we 
will effectively end up with tcp, serial and udp (at some point, who 
knows what else?). ;-) I need to check how optional runtime dependencies 
gets propagated by maven, maybe we could reduce impact on downstream 
projects by optional + scope markers.


From OSGi point of view we need to update metadata to list compatible 
transports using "optional" flag. I could do that in 0.10 as this is 
something I found problematic with prior releases.


Other way is using constructions such as "require-capability: 
plc4x-transport;kind=tcp", but this gets us on complicated path which I 
don't think we need nor will be able to fully utilize in coming year.


Best,
Łukasz

On 19.01.2022 12:00, Christofer Dutz wrote:

Well the problem with eagerly including transports is:
For example, using Modbus ... most transports being used will probably be onls 
TCP. And with Modbus-RTU it should only work with Serial, but there are people 
using serial-to-network converters, so you also could use Modbus-RTU via TCP 
transport ... also, if we ever support passive-mode we would be adding 
raw-passive. I think initially I made the drivers explicitly depend on the 
default transports and have people include the optional ones. I think for the 
raw transports on some systems you needed to run the application as root or 
with privileged network access.

But admittedly this has been so many years ago .. I don't even know if this is 
a problem today.

My reasoning on using "supported" is that these are the transports we are aware of and 
explicitly support, if the user uses S7 with Serial for example, that's not "supported" 
and if he has trouble with this ... well I guess it's his problem ;-)

So, what would you be proposing on returning? @Łukasz Dywicki ... instead of returning "tcp" to 
return "Class" (or however we do it)?

Chris


-Original Message-
From: Łukasz Dywicki  
Sent: Mittwoch, 19. Januar 2022 11:47

To:dev@plc4x.apache.org
Subject: Re: [DISCUSS] Extend PlcDriver with "supportedTransports"?

I come over this issue yesterday, but on other end. While trying to get
0.10 running under OSGi I found that "wiring" if fine but whole thing fails to 
work at runtime.
This boils down to several things, but Transport SPI lookup too. I agree that 
listing supported transports types (tcp/udp/serial/can) is fine for start. On 
other hand it is unlikely we will ever get S7 working over serial line so we 
could in theory declare that it works only with TcpTransport. Later one is 
actually beneficiary, at least for OSGi, cause it makes S7 driver classpath 
aware of TcpTransport requirement.
This was issue Etiane was facing back then while working with Camel components 
to wire everything in.

Anyhow, I am fine with both, with some level of preference for listing 
transports directly. If we scope dependencies properly end users will get 
drivers working out of the box with very few entries in their build tool.

Best,
Łukasz

On 19.01.2022 10:44, Christofer Dutz wrote:

Hi Cesar,

right now, I would only like to give back a list of strings that are the codes 
of the supported transports.
Perhaps we should extend the transports to give tooling more assistance on how 
a given transport is to be configured.

Chris


-Original Message-
From: Cesar Garcia
Sent: Sonntag, 9. Januar 2022 17:29
To: Apache PLC4X
Subject: Re: [DISCUSS] Extend PlcDriver with "supportedTransports"?

How are they?

Not only the transport, but also the data structures of the items.

This would allow the user to have a reference of what you can request in the 
items.

Looking to the future, this would be a must for the OPC-UA server.

Kind regards,

El dom, 9 ene 2022 a las 6:10, Christofer Dutz
()
escribió:


Hi all,

I know initially I built the Plc4X API to generally allow any form of
driver to use any form of transport.
However, this only would have worked in theory.

I think we should probably have every driver provide a list of
supported transports.
This would also help make tool integration easier.

If we see that for example sometimes, we have ModbusRTU passed along
TCP/UDP connections via serial-to-ethernet adapters, we can
definitely support that and if we come across a mode of operation,
that we haven't encountered, it should be easy to extend.

But this way we could ensure that we build the drivers in a way that
they know what to expect.

What do you think?



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

--
Email Signature
Ł

Re: [DISCUSS] Remove commons-beanutils dependency

[Łukasz Dywicki]

I could argue here as reducing external dependencies for smallish 
utilities is usually a good thing. If we can get rid of one dependency 
in favor of our own small targeted reflection helper which doesn't do 
much this change is good. Bringing 250kb commons for single class isn't 
something I would appreciate. Note I didn't track hoe extensively we use 
beanutils.


Best,
Łukasz

On 21.01.2022 11:01, Sebastian Rühl wrote:

Hi Yang,

could you please try bring that issue up to the upstream project? We don't want 
to replicate this logic in PLC4X if this can be solved upstream (at 
common-beanutils). Maybe there is a alternative implementation for java pojos 
that I'am currently not aware of. Other than that it's better to use methods 
supplied by org.apache.commons.lang3.reflect.FieldUtils rather than doing the 
direct implementation like you suggested.

- Sebastian

On 2022/01/19 12:54:22 杨 林 wrote:

Hi all,

I’m using plc4j in Android, commons-beanutils is the only thing to obstacle me 
to do that ,because Android does not have java.beans.PropertyDescriptor.

org.apache.commons.beanutils.BeanUtils is used only in 
org.apache.plc4x.java.spi.configuration.ConfigurationFactory (Line 93 and Line 
103). I think It could be replace by simple reflect:

field.setAccessible(true);

if (field.getType() == String.class) {
 field.set(instance, valueString);
} else if ((field.getType() == boolean.class) || (field.getType() == 
Boolean.class)) {
 field.setBoolean(instance, Boolean.parseBoolean(valueString));
} else if …

Any help?

Yang Lin

Re: Testing - my hardware list, and change of topic

[Łukasz Dywicki]

h Siemens Canada as I was back then. Not sure any of
my old contacts would be around.

Stephen

Chris



-Original Message-
From: Stephen Snow 
Sent: Mittwoch, 19. Januar 2022 13:33
To: dev@plc4x.apache.org; Łukasz Dywicki

Subject: Re: [DISCUSS] Extend PlcDriver with "supportedTransports"?

Hello,
I would like to just add to this conversation if I may.
On Wed, 2022-01-19 at 11:00 +, Christofer Dutz wrote:

Well the problem with eagerly including transports is:



For example, using Modbus ... most transports being used will
probably
be onls TCP.

Not entirely true, there is Modbus Ascii which is used over serial
and is not limited in scope like RTU. Sometimes referred to as
extended.

And with Modbus-RTU it should only work with Serial, but there are
people using serial-to-network converters, so you also could use
Modbus-RTU via TCP transport

Yes, been there done that.

... also, if we ever support passive-mode we would be adding raw-
passive. I think initially I made the drivers explicitly depend on
the
default transports and have people include the optional ones. I
think
for the raw transports on some systems you needed to run the
application as root or with privileged network access.


So for this project, which is an API to talk to any PLC presumably, I
think that the end use case does determine the extent to which
discovery is desirable. In my use case(s) I am trying to make a
viable product from, I am finding the driver inflexible in the
regards to messaging. As an example, I can connect both via TCP and
via Serial transport to the same PLC. After a bit of bashing, I was
able to get a response via Modbus-RTU from a lone address in the PLC.
But the physical serial connection was established and I could also
build a message manually and just use the serial transport to
send/receive it and works fine. I was getting netty.io complaints
going through the PLC4X protocol. The TCP connection is EIP protocol
and the PLC is a Rockwell Automation Micro820, so at this time I am
going to dig into the EIP protocol bit to determine why the message
is failing with it since the structure is what the PLC is expecting.
I believe that there was some discussion of Allen-Bradley CIP
protocol issues, I'm going to dig into that presently.

But admittedly this has been so many years ago .. I don't even know
if
this is a problem today.

My reasoning on using "supported" is that these are the transports
we
are aware of and explicitly support, if the user uses S7 with
Serial
for example, that's not "supported" and if he has trouble with this
... well I guess it's his problem ;-)


So, I have worked as a Systems Integrator, a Solution Provider, and a
machine builder (turn-key solutions) for a long time and have seen
almost everything that was made for purpose 'A' being made to work
for purpose 'B'. The one thing about PLC's is that they can be used
for a broad range of tasks, though they are more specialized
generally, but that is usually I/O count or motion capability. IMO,
the driver(s) should work with whatever transport is available
(within reason). I frequently am connected (out in the field) to one
device on a network, using one driver, and talking to two or more
devices on the network via pass-thru, which most OEM's like Siemens
support, does PLC4X contemplate supporting such? From the POV of the
user, I would like to connect to a e'net switch, and browse to
connect, this is my current goal, discoverable PLC with automatic
connection.
I understand my use case is likely very specific in that I am a sole
proprietor and follow my customers needs while trying to look out for
their future needs, so I am not always doing the latest and greatest,
just what they require (and are willing to pay for).


So, what would you be proposing on returning? @Łukasz Dywicki ...
instead of returning "tcp" to return "Class" (or
however
we do it)?


I would return a transport object, ie the instance that was created.
I need to be able to after connection change things like baud rate
etc., or in the case of Modbus-RTU protocol, the timing of the
communication instructions needs to be configurable and should be
easily exposed with getter/setter methods. Also, from the POV of a
serial transport, I need to be able to set the port mode in some
cases (RS-232 or RS-485 or RS-
422) for whatever purpose, like talking on an RS-232/RS-485/RS-422
network all over the serial port.

Stephen


Chris


-Original Message-
From: Łukasz Dywicki 
Sent: Mittwoch, 19. Januar 2022 11:47
To: dev@plc4x.apache.org
Subject: Re: [DISCUSS] Extend PlcDriver with "supportedTransports"?

I come over this issue yesterday, but on other end. While trying to
get
0.10 running under OSGi I found that "wiring" if fine but whole
thing
fails to work at runtime.
This boils down to several things, but Transport SPI lookup too. I
agree that listing supported transports types (tcp/udp/serial/can)
is
f

Re: [DISCUSS] Remove commons-beanutils dependency

[Łukasz Dywicki]

From formal point of view CAN is secondary element. We just need to 
solve classpath thing which is affecting Android.


The Transport API for CAN was updated especially for cases where we need 
to go over specific hardware. It is a great news if you could utilize it 
within your project!


Best,
Łukasz

On 19.01.2022 14:39, Christofer Dutz wrote:

Ooooh ...

this is exciting ...

and I be Lukasz will be happy to hear CAN being used :-)

And thanks for the willingness to prepare a PR ... believe me ... it's great to 
know something you did something that's now part of something big ;-)

If you need help with that, please let me know, and I'll do my best to help you 
with it.

Chris


-Original Message-
From: 杨 林 
Sent: Mittwoch, 19. Januar 2022 14:31
To: dev@plc4x.apache.org
Subject: 回复: [DISCUSS] Remove commons-beanutils dependency

Hi Chris,

Thank you for reply. The device is used for medical megentic bead transferring.

The schema is Android -> Ethernet to CAN converter -> CANOpen Node … -> CANOpen 
Node. It has implemented in PC, now I’m migrating the host node program to Android.

I will try to send PR

Yang Lin


发件人: Christofer Dutz
发送时间: 2022年1月19日 21:05
收件人: dev@plc4x.apache.org
主题: RE: [DISCUSS] Remove commons-beanutils dependency

HI Yang,

welcome to our little community.

That's interesting feedback. I didn't know about that. But ... Android -> PLC 
... would you mind elaborating a tiny bit on the use-case (Just out of curiosity)?

How about you whip up a PR and submit your first PR to the project ... that 
would make us even happier than fixing this for you :-)

Chris



-Original Message-
From: 杨 林 
Sent: Mittwoch, 19. Januar 2022 13:54
To: dev@plc4x.apache.org
Subject: [DISCUSS] Remove commons-beanutils dependency

Hi all,

I’m using plc4j in Android, commons-beanutils is the only thing to obstacle me 
to do that ,because Android does not have java.beans.PropertyDescriptor.

org.apache.commons.beanutils.BeanUtils is used only in 
org.apache.plc4x.java.spi.configuration.ConfigurationFactory (Line 93 and Line 
103). I think It could be replace by simple reflect:

field.setAccessible(true);

if (field.getType() == String.class) {
 field.set(instance, valueString);
} else if ((field.getType() == boolean.class) || (field.getType() == 
Boolean.class)) {
 field.setBoolean(instance, Boolean.parseBoolean(valueString));
} else if …

Any help?

Yang Lin

Re: We should start adding "getSupportedOptions" to drivers, transport, etc ;-)

[Łukasz Dywicki]

Makes tons of sense as constructing query strings in URI is simple, but 
validating them is much harder. ;-)


Best,
Łukasz

On 19.01.2022 13:58, Christofer Dutz wrote:

Hi,

In contrast to my last email, I just noticed that we don't seem to have any 
"getSupportedOptions" methods in PlcDriver or PlcTransport ... I think we 
should start adding them to simplify tool integration.

What do you think?

Chris

Re: [DISCUSS] Extend PlcDriver with "supportedTransports"?

[Łukasz Dywicki]

I come over this issue yesterday, but on other end. While trying to get 
0.10 running under OSGi I found that "wiring" if fine but whole thing 
fails to work at runtime.
This boils down to several things, but Transport SPI lookup too. I agree 
that listing supported transports types (tcp/udp/serial/can) is fine for 
start. On other hand it is unlikely we will ever get S7 working over 
serial line so we could in theory declare that it works only with 
TcpTransport. Later one is actually beneficiary, at least for OSGi, 
cause it makes S7 driver classpath aware of TcpTransport requirement.
This was issue Etiane was facing back then while working with Camel 
components to wire everything in.


Anyhow, I am fine with both, with some level of preference for listing 
transports directly. If we scope dependencies properly end users will 
get drivers working out of the box with very few entries in their build 
tool.


Best,
Łukasz

On 19.01.2022 10:44, Christofer Dutz wrote:

Hi Cesar,

right now, I would only like to give back a list of strings that are the codes 
of the supported transports.
Perhaps we should extend the transports to give tooling more assistance on how 
a given transport is to be configured.

Chris


-Original Message-
From: Cesar Garcia 
Sent: Sonntag, 9. Januar 2022 17:29
To: Apache PLC4X 
Subject: Re: [DISCUSS] Extend PlcDriver with "supportedTransports"?

How are they?

Not only the transport, but also the data structures of the items.

This would allow the user to have a reference of what you can request in the 
items.

Looking to the future, this would be a must for the OPC-UA server.

Kind regards,

El dom, 9 ene 2022 a las 6:10, Christofer Dutz ()
escribió:


Hi all,

I know initially I built the Plc4X API to generally allow any form of
driver to use any form of transport.
However, this only would have worked in theory.

I think we should probably have every driver provide a list of
supported transports.
This would also help make tool integration easier.

If we see that for example sometimes, we have ModbusRTU passed along
TCP/UDP connections via serial-to-ethernet adapters, we can definitely
support that and if we come across a mode of operation, that we
haven't encountered, it should be easy to extend.

But this way we could ensure that we build the drivers in a way that
they know what to expect.

What do you think?




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

*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César 
García*

*Cel: +58 414-760.98.95*

*Hotline Técnica SIEMENS: 0800 1005080*

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

Re: [LAZY-CONSENSUS] Clean up in our branches?

[Łukasz Dywicki]

Few notes

Below contains mspec for LLDP which isn't update since a while, yet this 
might be something interesting from profinet perspective where lldp is 
actually being used
> 
feature/link-layer-discovery-protocol 
(2 years)


These were initial works I did on DCP, the profinet2 is branch I worked 
with Adrian Lazar. I don't think these got merged, but Chris work on 
profinet superseded these
> 
feature/profinet 
(2 years)
> 
feature/profinet2 
(I think this is merged, right?)


This one was an attempt to swap bacnet driver from passive mode to 
normal, yet it did get stuck due to incompleteness of mspec back then 
(optional fields), I believe now this issue is solved with recent work 
from Sebastian
> 
feature/bacnet-active 
(2 years)


I can move the LLDP and bacnet active branches to my fork and bring them 
back to origin if I have chance to work on them.

So from my perspective feel free to cleanup these.

Best,
Łukasz

On 15.12.2021 10:23, Christofer Dutz wrote:

Hi all,

I have just tried to revive a not so old branch (feature/plc4net) and that is a 
LOT of work.

Considering how many super-old branches we have; I would like to propose to 
clean up all branches that haven't been touched for at least a year.
(I know one or two I stripped from this list, because they were mine and I want 
to update them or they are release branches, which I think we should keep)

Right now, we have 48 branches.

The ones I would delete are:

Stale for longer than 12 months:
feature/code-gen-julian
 (3 years)
too-many-open-files 
(2 years)
fix-netty-usage (2 years)
fix-bytebuff-leaks (2 
years)
feature/big_integer_support_on_driver_base
 (2 years)
feature/optimizer-for-next-gen
 (2 years)
develop-test (2 years)
feature/profinet (2 
years)
feature/plc-simulator
 (2 years)
feature/bacnet-active
 (2 years)
bugfix/close-eventloop-after-channel
 (16 months)
feature/parser-tracing
 (16 months)
issue/PLC4X-258 (13 
months)
feature/grpc-proxy (13 
months)
issue/PLC4X-252 (14 
months)

Newer branches, that I think might be obsolete or forgotten to be deleted ...
feature/sparkplug-gateway
 (9 months)
fix/modbus_string (is 
this obsolete? What's the status on this?)
feature/profinet2 (I 
think this is merged, right?)
feature/updated-mspec-string
 (I think this is obsolete, right?)
issue/PLC4X-304 (I think 
this is merged, right?)
issue/PLC4X-311 (I think 
this is merged, right?)
s7event (I think this is merged, 
right?)

So, anyone wanting to keep one of these branches ... please reply in let's say 
the next 7 days and if I don't hear back from you, I'll delete the listed 
branches.

Chris

Re: CANOpen_cant send data to vcan on linux(Ubuntu)

[Łukasz Dywicki]

I did forward this mail to 蒋怀川. I had no get any reply for that.
Do we know if he/she subscribed to our mailing list?

This is first external attempt to use CANopen beside myself, so I don't 
want this to fail! :)


Best,
Łukasz

On 22.11.2021 10:20, Xiangdong Huang wrote:

And I might add, that you should subscribe to the mailinglist, by sending an 
empty email to dev-subscr...@plc4x.apache.org


If so, I think he may do not receive email replies ...


---
Xiangdong Huang
School of Software, Tsinghua University

  黄向东
清华大学 软件学院

Christofer Dutz  于2021年11月17日周三 下午8:48写道：


And I might add, that you should subscribe to the mailinglist, by sending an 
empty email to dev-subscr...@plc4x.apache.org

I had to moderate your email manually... If you're subscribed this happens 
automatically.

Chris

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

From: Łukasz Dywicki 
Sent: Wednesday, November 17, 2021 1:40:33 PM
To: dev@plc4x.apache.org 
Subject: Re: CANOpen_cant send data to vcan on linux(Ubuntu)

Hey,
There might be several reasons why you can't see anything on the interface.

1. Interface is down, make sure you perform both commands:
sudo ip link add dev vcan1 type vcan
sudo ip link set up vcan1
2. The candump command might not list "loopback" messages, I am not sure of
that, but you need to verify its options.
You can also use interface statistics to see if counters go up:
ip -details -statistics link show vcan1

Let me know if any of above helps. The PDO address you use is valid and
should trigger message on the bus.

Best,
Łukasz


śr., 17 lis 2021 o 13:26 蒋怀川  napisał(a):



中文==

你好，导师，我是一名java程序员，我在使用canopen当中遇到一些相关的疑问。如下面的截图所示，我向vcan发送数据，但是Vcan没有打印出任何提示信息。这种问题我需要如何处理，谢谢。



English
Hello, tutor, I'm a java developer,I have some questions about using
CANopen. As shown in the screenshot below, I sent data to Vcan, but Vcan
did not print any prompt information. How do I deal with this problem?
Thank you.



code==
 
 
 
 org.apache.plc4x
 plc4j-driver-canopen
 0.8.0
 
 

===
package com;


import org.apache.plc4x.java.api.exceptions.PlcConnectionException;
import org.apache.plc4x.java.api.messages.PlcWriteRequest;
import org.apache.plc4x.java.api.messages.PlcWriteResponse;
import org.apache.plc4x.java.canopen.CANOpenPlcDriver;
import org.apache.plc4x.java.spi.connection.DefaultNettyPlcConnection;


import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutionException;


public class CANOpenVcanDemo {
 public static void main(String[] args)
 throws PlcConnectionException, ExecutionException,
InterruptedException {
 String canInterface = "vcan1";
 String connectionString =
 String.format("canopen:socketcan://%s?nodeId=11",
canInterface);
 DefaultNettyPlcConnection plcConnection =
 (DefaultNettyPlcConnection) new
CANOpenPlcDriver().getConnection(connectionString);
 plcConnection.connect();
 if (plcConnection.isConnected()){
 System.out.println("Connected");
 }else {
 System.out.println("not Connected");
 return;
 }
 if (plcConnection.getMetadata().canWrite()) {
 PlcWriteRequest.Builder builder =
plcConnection.writeRequestBuilder();
 //String address = "SDO:11:0x1600/0x01:INTEGER64";
 String address = "RECEIVE_PDO_1:11:INTEGER64";
 //CANOpenDataType
 builder.addItem("rpdo_0x200", address,123);
 PlcWriteRequest plcWriteRequest = builder.build();
 CompletableFuture completableFuture =
 (CompletableFuture)
plcWriteRequest.execute();
 System.out.println("===>flag");
 PlcWriteResponse plcWriteResponse = completableFuture.get();

System.out.println(plcWriteResponse.getResponseCode("rpdo_0x200"));
 }
 }
}

Re: CANOpen_cant send data to vcan on linux(Ubuntu)

[Łukasz Dywicki]

Hey,
There might be several reasons why you can't see anything on the interface.

1. Interface is down, make sure you perform both commands:
sudo ip link add dev vcan1 type vcan
sudo ip link set up vcan1
2. The candump command might not list "loopback" messages, I am not sure of
that, but you need to verify its options.
You can also use interface statistics to see if counters go up:
ip -details -statistics link show vcan1

Let me know if any of above helps. The PDO address you use is valid and
should trigger message on the bus.

Best,
Łukasz


śr., 17 lis 2021 o 13:26 蒋怀川  napisał(a):

>
> 中文==
>
> 你好，导师，我是一名java程序员，我在使用canopen当中遇到一些相关的疑问。如下面的截图所示，我向vcan发送数据，但是Vcan没有打印出任何提示信息。这种问题我需要如何处理，谢谢。
>
>
>
> English
> Hello, tutor, I'm a java developer,I have some questions about using
> CANopen. As shown in the screenshot below, I sent data to Vcan, but Vcan
> did not print any prompt information. How do I deal with this problem?
> Thank you.
>
>
>
> code==
> 
> 
> 
> org.apache.plc4x
> plc4j-driver-canopen
> 0.8.0
> 
> 
>
> ===
> package com;
>
>
> import org.apache.plc4x.java.api.exceptions.PlcConnectionException;
> import org.apache.plc4x.java.api.messages.PlcWriteRequest;
> import org.apache.plc4x.java.api.messages.PlcWriteResponse;
> import org.apache.plc4x.java.canopen.CANOpenPlcDriver;
> import org.apache.plc4x.java.spi.connection.DefaultNettyPlcConnection;
>
>
> import java.util.concurrent.CompletableFuture;
> import java.util.concurrent.ExecutionException;
>
>
> public class CANOpenVcanDemo {
> public static void main(String[] args)
> throws PlcConnectionException, ExecutionException,
> InterruptedException {
> String canInterface = "vcan1";
> String connectionString =
> String.format("canopen:socketcan://%s?nodeId=11",
> canInterface);
> DefaultNettyPlcConnection plcConnection =
> (DefaultNettyPlcConnection) new
> CANOpenPlcDriver().getConnection(connectionString);
> plcConnection.connect();
> if (plcConnection.isConnected()){
> System.out.println("Connected");
> }else {
> System.out.println("not Connected");
> return;
> }
> if (plcConnection.getMetadata().canWrite()) {
> PlcWriteRequest.Builder builder =
> plcConnection.writeRequestBuilder();
> //String address = "SDO:11:0x1600/0x01:INTEGER64";
> String address = "RECEIVE_PDO_1:11:INTEGER64";
> //CANOpenDataType
> builder.addItem("rpdo_0x200", address,123);
> PlcWriteRequest plcWriteRequest = builder.build();
> CompletableFuture completableFuture =
> (CompletableFuture)
> plcWriteRequest.execute();
> System.out.println("===>flag");
> PlcWriteResponse plcWriteResponse = completableFuture.get();
>
> System.out.println(plcWriteResponse.getResponseCode("rpdo_0x200"));
> }
> }
> }
>
>
>
>
>
>
>
>

Re: Driver PLC4J S7

[Łukasz Dywicki]

Hey Cesar,
I see that you do awesome progress with all complicated parts of S7
communication. By looking at code and updated docs I see that most of this
functionality is intended for S7-400 and will not work with low end
S7-1200. This brings me to a question if our present
"PlcConnection.canSubscribe()" method is sufficient to let know user
application that it can subscribe? Does it return false for S7-1200 and
true for 300 and 400?

Main question is how we could keep user applications aware of subscription
possibilities without complicating PLC4X end too much. If subscription
support is similar (alarm, mode, user) and available only in higher end
models then we can live with current APIs, but if subscription support vary
between models we need to think how to express that to end user. After all
doing a subscription request which fails is least effective way to find
that driver and connected plc does not support specific subscription kind.

Best,
Łukasz

śr., 17 lis 2021 o 06:43 Cesar Garcia  napisał(a):

> Hello,
>
> This PR includes the following features for the S7 driver.
>
> 1. Subscribe to Alarm8.
>2. Recognition of events.
>3. Alarm text processing.
>4. Subscription to cyclical values.
>5. Diagnostic Record Readings (SZL).
>6. Proposal for documentation.
>
> Thank you very much for your support in the documentation proposal, several
> sections are missing, but I think your observations are extremely
> important.
>
> Best regards,
>
> --
> *CEOS Automatización, C.A.*
> *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
> *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*
>
> *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
> *Ing. César García*
>
> *Cel: +58 414-760.98.95*
>
> *Hotline Técnica SIEMENS: 0800 1005080*
>
> *Email: support.aan.automat...@siemens.com
> *
>

Re: AW: AW: ClassCastException: class org.apache.plc4x.java.opcua.readwrite.ServiceFault cannot be cast to class org.apache.plc4x.java.opcua.readwrite.ReadResponse

[Łukasz Dywicki]

REMOTE_ERROR could be better, but to make it right we need to look into 
actual ServiceFault header and its result code. Possibly we will find 
there a better indication of what the error is.


If you will look at my last commit on develop you will find right place 
to put OPC <> PLC4X status mapping logic.


Kind regards,
Łukasz


On 22.10.2021 09:59, Torsten Uhr wrote:

Hi Łukasz,

thanks for the very quick response. It works as expected.
Did You think the response code "REMOTE_ERROR" might more suite than 
"INTERNAL_ERROR"?

With best regards

Torsten Uhr
SQL Projekt AG  ▪ Franklinstraße 25 a  ▪ 01069 Dresden

Telefon:(0351) 87619-0
Telefax:(0351) 87619-99
E-Mail: torsten@sql-ag.de
Web:www.sql-ag.de

Aufsichtsratsvorsitzender: Jürgen Bittner
Vorstand: Stefan Ehrlich, Jens Gärtner (Sprecher)
Handelsregister: HRB 38924 Amtsgericht Dresden
Die Zertifizierungsstelle der TÜV SÜD Management Service GmbH bescheinigt, dass die 
SQL Projekt AG für den Geltungsbereich "Entwicklung
und Vertrieb von Datenbank- und Integrationslösungen sowie Beratung, Training 
und Support auf dem Gebiet datenbankgestützter
Softwareprodukte" ein Qualitätsmanagementsystem eingeführt hat und anwendet.


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten 
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. 
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail oder Inhalte 
ist nicht gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error) 
please notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.

-----Ursprüngliche Nachricht-
Von: Łukasz Dywicki 
Gesendet: Donnerstag, 21. Oktober 2021 23:21
An: dev@plc4x.apache.org
Betreff: Re: AW: ClassCastException: class 
org.apache.plc4x.java.opcua.readwrite.ServiceFault cannot be cast to class 
org.apache.plc4x.java.opcua.readwrite.ReadResponse

Thank you for test case.

I've implemented basic fix for issue based on my sparse knowledge of OPC UA. 
Issue was missing a callback call when server returned an error.

I improved that, now you sohuld get at least failed answer back.
Original reply is logged. I did not map yet status code from server.

Pushed to developer for 0.10, please test.

Best,
Łukasz


On 21.10.2021 14:03, Christofer Dutz wrote:

Hi Thorsten,

first of all: Thank you for providing a Unit Test for demonstrating
your problem ... that makes our lives a lot easier :-)

I'm sure someone on the community will have a look at the issue soon. I'll try 
to ping the right people for that.

Chris

-Ursprüngliche Nachricht-
Von: Torsten Uhr 
Gesendet: Donnerstag, 21. Oktober 2021 13:12
An: dev@plc4x.apache.org
Betreff: ClassCastException: class
org.apache.plc4x.java.opcua.readwrite.ServiceFault cannot be cast to
class org.apache.plc4x.java.opcua.readwrite.ReadResponse

Hi all,

if I create an OPCUA connection (to milo) and wait 5 minutes before sending a 
read request the error attached below is logged and the read execution blocks 
infinitely.
I'm used codebase 0.9.0 and 0.10.0 snapshot.
Note: The wait simulates a connection created earlier and get from a connection 
pool in a managed environment like application server.
I think theres a timeout for pending connections on the server side. I would 
expect, that the driver should throw an exception rather blocking?

[nioEventLoopGroup-2-1] WARN io.netty.channel.DefaultChannelPipeline - An 
exceptionCaught() event was fired, and it reached at the tail of the pipeline. 
It usually means the last handler in the pipeline did not handle the exception.
io.netty.handler.codec.DecoderException: java.lang.ClassCastException: class 
org.apache.plc4x.java.opcua.readwrite.ServiceFault cannot be cast to class 
org.apache.plc4x.java.opcua.readwrite.ReadResponse 
(org.apache.plc4x.java.opcua.readwrite.ServiceFault and 
org.apache.plc4x.java.opcua.readwrite.ReadResponse are in unnamed module of 
loader 'app')
  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:379)
  at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
  at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
  at 
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
  at 
io.netty.handler.co

Re: AW: ClassCastException: class org.apache.plc4x.java.opcua.readwrite.ServiceFault cannot be cast to class org.apache.plc4x.java.opcua.readwrite.ReadResponse

[Łukasz Dywicki]

Thank you for test case.

I've implemented basic fix for issue based on my sparse knowledge of OPC 
UA. Issue was missing a callback call when server returned an error.


I improved that, now you sohuld get at least failed answer back. 
Original reply is logged. I did not map yet status code from server.


Pushed to developer for 0.10, please test.

Best,
Łukasz


On 21.10.2021 14:03, Christofer Dutz wrote:

Hi Thorsten,

first of all: Thank you for providing a Unit Test for demonstrating your 
problem ... that makes our lives a lot easier :-)

I'm sure someone on the community will have a look at the issue soon. I'll try 
to ping the right people for that.

Chris

-Ursprüngliche Nachricht-
Von: Torsten Uhr 
Gesendet: Donnerstag, 21. Oktober 2021 13:12
An: dev@plc4x.apache.org
Betreff: ClassCastException: class 
org.apache.plc4x.java.opcua.readwrite.ServiceFault cannot be cast to class 
org.apache.plc4x.java.opcua.readwrite.ReadResponse

Hi all,

if I create an OPCUA connection (to milo) and wait 5 minutes before sending a 
read request the error attached below is logged and the read execution blocks 
infinitely.
I'm used codebase 0.9.0 and 0.10.0 snapshot.
Note: The wait simulates a connection created earlier and get from a connection 
pool in a managed environment like application server.
I think theres a timeout for pending connections on the server side. I would 
expect, that the driver should throw an exception rather blocking?

[nioEventLoopGroup-2-1] WARN io.netty.channel.DefaultChannelPipeline - An 
exceptionCaught() event was fired, and it reached at the tail of the pipeline. 
It usually means the last handler in the pipeline did not handle the exception.
io.netty.handler.codec.DecoderException: java.lang.ClassCastException: class 
org.apache.plc4x.java.opcua.readwrite.ServiceFault cannot be cast to class 
org.apache.plc4x.java.opcua.readwrite.ReadResponse 
(org.apache.plc4x.java.opcua.readwrite.ServiceFault and 
org.apache.plc4x.java.opcua.readwrite.ReadResponse are in unnamed module of 
loader 'app')
 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:379)
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
 at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
 at 
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
 at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
 at 
io.netty.handler.codec.ByteToMessageCodec.channelRead(ByteToMessageCodec.java:103)
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
 at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
 at 
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
 at 
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
 at 
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
 at 
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
 at 
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
 at 
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
 at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
 at 
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
 at 
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
 at 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
 at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.ClassCastException: class 
org.apache.plc4x.java.opcua.readwrite.ServiceFault cannot be cast to class 
org.apache.plc4x.java.opcua.readwrite.ReadResponse 
(org.apache.plc4x.java.opcua.readwrite.ServiceFault and 
org.apache.plc4x.java.opcua.readwrite.ReadResponse are in unnamed module of 
loader 'app')
 at 
org.apache.plc4x.java.opcua.protocol.OpcuaProtocolLogic.lambda$read$0(OpcuaProtocolLogic.java:177)
 at 

Re: Modbus choosing the correct write function

[Łukasz Dywicki]

Looking once again at the issue I can see flaw in our modbus logic.

1. Driver by default assume it is used with single field optimizer, 
meaning it does not support multiple reads and multiple writes.
2. Despite of above it does assume write multiple coil, even if there is 
just one bit to be set.


The logic is not that difficult to fix, yet I don't see currently a way 
we could support odd configurations such as read multi/write single and 
vice versa.
This is something which is not reflected currently by API which does not 
let user to pick optimizer or change it at runtime. On other hand 
changing field syntax for that will require updates to all languages.


Soeren, can you create a bug/feature request describing your issue? This 
way it will not fade over time.


Best,
Łukasz

On 08.10.2021 06:28, Niclas Hedhman wrote:

On 2021-10-07 23:33, Łukasz Dywicki wrote:

As
far I know Murphy's law we will then find devices which require write
multiple even for single register. ;-)


I can confirm that I have come across that too, and pretty sure it 
applies to both reads and writes. One could argue that such devices are 
not compliant, but since there is no strong certification and everyone 
claiming "Modbus protocol", I think it is something that needs to be 
handled.


Cheers
Niclas

Re: Fwd: plc4x bug question

[Łukasz Dywicki]

Looking on the problem description and sources it looks to me that we 
might miss a proper lifecycle call for transport/channel factory.
Yet from 0.9 release we do have proper implementation of 
PlcDriver#close() which fires disconnect event handled by our netty 
wrapper. I believe that its intention is to trigger termination of 
active connection. Is this problem is confirmed for 0.9?


Best,
Łukasz


On 08.10.2021 19:25, Christofer Dutz wrote:

Forwarding again..

Holen Sie sich Outlook f?r Android

From: wq 
Sent: Thursday, October 7, 2021 5:53:51 AM
To: dev-ow...@plc4x.apache.org 
Subject: plc4x bug question


class NettyChannelFactory
/**
* Event Loop Group to use.
* Has to be in accordance with {@link #getChannel()}
* otherwise a Runtime Exception will be produced by Netty
* 
* By Default Nettys {@link NioEventLoopGroup} is used.
* Transports which have to use a different EventLoopGroup have to override 
{@link #getEventLoopGroup()}.
*/
public EventLoopGroup getEventLoopGroup() {
return new NioEventLoopGroup();
}

Memory leak problem: When the server is disconnected or restarted, the Netty 
client reconnects, and the thread cannot be released, and increases each time. 
When the number reaches a certain point, the program cannot connect.
[X]

Revised:

class NettyChannelFactory

private static NioEventLoopGroup nioEventLoopGroup = new NioEventLoopGroup();
/**
* Event Loop Group to use.
* Has to be in accordance with {@link #getChannel()}
* otherwise a Runtime Exception will be produced by Netty
* 
* By Default Nettys {@link NioEventLoopGroup} is used.
* Transports which have to use a different EventLoopGroup have to override 
{@link #getEventLoopGroup()}.
*/
public EventLoopGroup getEventLoopGroup() {
if (nioEventLoopGroup == null || nioEventLoopGroup.isShutdown()) {
nioEventLoopGroup = new NioEventLoopGroup();
}
return nioEventLoopGroup;
}

The number of threads began to stabilize
[X]



I hope PLC4X will do better and better. In the process of use, I found many 
problems, which are relatively basic. Seriously affect the use of production.

Re: Modbus choosing the correct write function

[Łukasz Dywicki]

Hey Soeren,
Indeed this might be a gap in current protocol logic. Given that write 
requests might contain multiple data points/registers we assumed 
write-multiple as default. Restrictions you mentioned are very common 
for many devices hence we shall update logic somehow.
Currently, as far I know, we have no clear way for calling program to 
define "write" kind. Obviously we can always try to assume that single 
write request should be handled as single write and not multiple. As far 
I know Murphy's law we will then find devices which require write 
multiple even for single register. ;-)


There are no good answers yet, but its good you brought issue up.
Maybe we need to open write api a little bit to let caller pass some 
portion of driver specific metadata?


Best,
Łukasz


On 07.10.2021 20:41, Soeren Sprenger wrote:

Hi folks,

I just have a little problem controlling my Keba wallbox with Modbus 
TCP. Reading all values works fine with the PLC4X Modbus driver in 
version 0.9.0, but I have a problem writing.
The Modbus driver uses - no matter what I do - the function code 16 
"Write Multiple Registers", but I am only allowed to use function code 6 
"Write Single Register" in the PLC.

It should work like this:
builder.addItem("charging_current", "holding-register:5004:UINT", 8000);

I started debugging, with my plain-old-c implementation i get it done, 
the resulting packed to the PLC is like:



With the PLC4X:


So i started digging in the code, i found the ModbusProtocolLogic class, 
in the "getWriteRequestPdu" there is no support for getting any instance 
of the required ModbusPDUWriteSingleHoldingRegistersRequest, just for 
ModbusPDUWriteMultipleHoldingRegistersRequest.

This seams like a conceptual problem in here, or i misunderstood the code.

Can you please give me a hint, how you would fix this?
Maybe we need something like holding-register: vs holding-registers: in 
the field specification, or make the getWriteRequestPdu more 
sophisticated to find out that there is just a write to a single field.


Thank you,
    Soeren


--
AereA GmbH
Sitz: Wüstenstein 18, 91346 Wiesenttal
Geschäftsführerin: Franziska Sprenger
Handelsregister: Bamberg B10466
E-Mail: i...@aerea.de 
Web: http://www.aerea.de 
Fon: +49 (0) 36424 760823
Fax: +49 (0) 36651 1390009

Re: AW: Changes on mspec: parameterized type refs, assert, try, const

[Łukasz Dywicki]

elf the try is self sufficient and behaves indeed 
like an optional without an expression. Other than that you can always group 
dependended fields as a complex... but let's see how this evolves.
These blocks could be indeed come in handy as an option to define things...

- Sebastian

On 2021/09/25 20:23:08, Łukasz Dywicki  wrote:

Hey Sebastian,
Not that far ago we had a similar discussion. Yet then it was mainly
about optionals. See "[DISCUSS] Change the way we use "optional".

Back then we did not do any changes to mspec, just ranted about
possible approach to make better use of optional fields.
I remember that current mspec/code can't for example handle ie. a
bacnet whois without all fields. Looking at your example I guess you
try to solve that puzzle.

I don't have any strong feelings here, but why not using optional
field with additional "reset" flag?
To me what rings a bell in your mail is an assumption that try is
always followed by optional field. This tells me that 'try' should
rather be a block than a field. By this way we will be able to pair
these visually as well as handle situation when there is one try
statement but multiple optional fields.

Best,
Łukasz


On 24.09.2021 23:52, Sebastian Rühl wrote:

Hi together,

I have some exciting changes in the pipeline regarding the mspec:

1. parameters on type refs
  with that change it is now possible to target a discriminated child in 
advance.
2. assert keyword
  with that change it is possible to throw a
ParserAssertException (in java, or errors in other languages). This field is 
similar to a const but instead of a ParseException a ParserAssertException is 
thrown. In contrast to a const the check expression can be dynamic (e.g. 
virtual fields now working on develop) 3. try keyword to prefix fields:
  with that change it is possible to try to parse some content and in case 
an assert fails it resets the buffer.
4. const is now extended to type reference
 this change allows enums to be used as const values.

All theses changes allow to encapsulate behavior in complex types so you don't 
need to DRY.

Here is a example working with bacnet:
  ['0x07' BACnetUnconfirmedServiceRequestWhoHas
  [try simple BACnetComplexTagUnsignedInteger ['0', 
'BACnetDataType.UNSIGNED_INTEGER' ] 'deviceInstanceRangeLowLimit'  ]
  [optional   BACnetComplexTagUnsignedInteger ['1', 
'BACnetDataType.UNSIGNED_INTEGER' ] 'deviceInstanceRangeHighLimit' 
'deviceInstanceRangeLowLimit != null']
  [try simple BACnetComplexTagOctetString ['2', 
'BACnetDataType.OCTET_STRING' ] 'objectIdentifier' ]
  [optional   BACnetComplexTagOctetString ['3', 
'BACnetDataType.OCTET_STRING' ] 'objectName' 'objectIdentifier == null' ]
  ]

The logic if a type matches is asserted in the type itself. The second optional 
implies when the first element appears the second must be present. The last one 
tries to read and if it fails it uses the second type.

Here is the snippet from the parent type:

[discriminatedType 'BACnetComplexTag' [uint 4 'tagNumberArgument', 
BACnetDataType 'dataType']
  [assertuint 4   'tagNumber' 
'tagNumberArgument'   ]
  [const TagClass 'tagClass'  
'TagClass.CONTEXT_SPECIFIC_TAGS'  ]
  [simpleuint 3   'lengthValueType' 
]
  .
  [virtual   uint 32  'actualLength' 'lengthValueType == 5 
']
  [typeSwitch 'dataType'
  
  ['OCTET_STRING' BACnetComplexTagOctetString [uint 32 'actualLength']
  // TODO: The reader expects int but uint32 get's mapped to long 
so even uint32 would easily overflow...
  [virtualuint16   
'actualLengthInBit' 'actualLength * 8']
  [simple string 'actualLengthInBit' 'ASCII'   'theString']
  ]

Would love to hear some opinions! If there are no objections I would push this 
change to develop soon.

- Sebastian

PatchContent:
Index:
code-generation/protocol-base-mspec/src/main/antlr4/org/apache/plc4x
/plugins/codegenerator/language/mspec/MSpec.g4
<+>UTF-8
===
diff --git 
a/code-generation/protocol-base-mspec/src/main/antlr4/org/apache/plc4x/plugins/codegenerator/language/mspec/MSpec.g4
 
b/code-generation/protocol-base-mspec/src/main/antlr4/org/apache/plc4x/plugins/codegenerator/language/mspec/MSpec.g4
--- 
a/code-generation/protocol-base-mspec/src/main/antlr4/org/apache/plc4x/plugins/codegenerator/language/mspec/MSpec.g4
(revision ef35531d5a872f29dccddb3a11a135b166958185)
+++ 
b/code-generation/protocol-base-mspec/src/main/antlr4/org/apache/plc4x/plugins/codegenerator/language/mspec

Re: [DISCUSS] Dealling with endianess switches ...

[Łukasz Dywicki]

man, these samples are pretty long to go with, but from overall issue it 
seems like we need to do reflect multi layer protocols in a better way.


As far I understand the problem - it boils down to underlying buffer 
which is started with BE and we need to read things using LE.

I see issue in two areas:
1) We have no BE/LE switch for buffer other than constructor argument
2) The switch in case of profinet is contextual and depends on protocol 
layer we're currently in.


Given the 1 - which is currently the base layer I think going with any 
of ways you mentioned we will probably need a "flip" operation to swap 
endianness or so.
Personally I think making the switch at the type level is easiest to get 
since we had this attempt in the past. Having an extra block for it 
seems like a bigger change (yet we discuss another block idea).
Making a contextual switches for fields is doable since new APIs made by 
Sebastian for reader/writer allow to pass "withOptions" which would 
really work well in this scenario.


So if you'd ask me I'd opt for type level and field level switch. With 
this we could in theory simulater a block with a a complex type having a 
endianness switch.


Best,
Łukasz


On 26.09.2021 15:59, Christofer Dutz wrote:

Hi all,

I'm currently working on the PROFINET ... here I have the challenge, that I 
have multiple layers of different protocols.

UDP -> DCE/RPC -> PROFINET IO CM (Block Container) -> PROFINET IO CM Blocks

The problem is:


   *   UDP is Big Endian
   *   PROFINET IO CM Blocks are Big Endian
   *   DCE/RPC is big or little endian depending on a variable inside the 
DCE/RPC packet
   *   Profinet IO CM (block container) is the same encoding as the DCE/RPC 
packet

At first I thought if I force my request to big endian, then the response would 
be accordingly.
Unfortunately that's not the case ... So if I send a request with Big Endian 
DCE/RPC (Hence, makeing the entire message Big endian). I still get a response 
back with DCE/RPC in Little Endian. So I have to be able to handle both.

Now I had multiple ideas:

   *   A new sort of block "endianessSwitch" (or a better name) ... which takes an 
argument and which simply switches the endianess of the buffers to the given one. This would 
probably be pretty simple to implement with a "try-finally" block in Java.
   *   We add an optional additional option to the complex-type declarations. 
This would however have us split types into two.

Here comes the example of the PN DCE/RPC packet with an endianessSwitch:

[discriminatedType 'DceRpc_Packet'
 [const uint 8'version'   '0x04'
 ]
 [discriminator DceRpc_PacketType 'packetType'  
 ]
 [typeSwitch 'packetType'
 ['REQUEST'  DceRpc_Packet_Req
 [reserved uint 1 '0x0' 
 ]
 [constuint 1 'broadcast''0'
 ]
 [constuint 1 'idempotent'   '1'
 ]
 [constuint 1 'maybe''0'
 ]
 [constuint 1 'noFragmentAcknowledgeRequested'   '0'
 ]
 [constuint 1 'fragment' '0'
 ]
 [constuint 1 'lastFragment' '0'
 ]
 [reserved uint 1 '0x0' 
 ]
 ]

 ['RESPONSE' DceRpc_Packet_Res
 [reserved uint 1 '0x0' 
 ]
 [constuint 1 'broadcast''0'
 ]
 [constuint 1 'idempotent'   '0'
 ]
 [constuint 1 'maybe''0'
 ]
 [constuint 1 'noFragmentAcknowledgeRequested'   '1'
 ]
 [constuint 1 'fragment' '0'
 ]
 [constuint 1 'lastFragment' '1'
 ]
 [reserved uint 1 '0x0' 
 ]
 ]

 ['REJECT' DceRpc_Packet_Rej
 [reserved uint 1 '0x0' 
 ]
 [constuint 1 'broadcast''0'
 ]
 [constuint 1 'idempotent'   '0'
 ]
 [constuint 1 'maybe''0'
 ]
 [constuint 1 'noFragmentAcknowledgeRequested'   '0'
 ]
 [constuint 1 'fragment' '0'
 ]
 [constuint 1 'lastFragment' '0'
 ]
 [reserved uint 1 '0x0' 
 ]
 ]
 ]
 [reserved  uint 6'0x00'

Re: Changes on mspec: parameterized type refs, assert, try, const

[Łukasz Dywicki]

Hey Sebastian,
Not that far ago we had a similar discussion. Yet then it was mainly 
about optionals. See "[DISCUSS] Change the way we use "optional".


Back then we did not do any changes to mspec, just ranted about possible 
approach to make better use of optional fields.
I remember that current mspec/code can't for example handle ie. a bacnet 
whois without all fields. Looking at your example I guess you try to 
solve that puzzle.


I don't have any strong feelings here, but why not using optional field 
with additional "reset" flag?
To me what rings a bell in your mail is an assumption that try is always 
followed by optional field. This tells me that 'try' should rather be a 
block than a field. By this way we will be able to pair these visually 
as well as handle situation when there is one try statement but multiple 
optional fields.


Best,
Łukasz


On 24.09.2021 23:52, Sebastian Rühl wrote:

Hi together,

I have some exciting changes in the pipeline regarding the mspec:

1. parameters on type refs
 with that change it is now possible to target a discriminated child in 
advance.
2. assert keyword
 with that change it is possible to throw a ParserAssertException (in java, 
or errors in other languages). This field is similar to a const but instead of 
a ParseException a ParserAssertException is thrown. In contrast to a const the 
check expression can be dynamic (e.g. virtual fields now working on develop)
3. try keyword to prefix fields:
 with that change it is possible to try to parse some content and in case 
an assert fails it resets the buffer.
4. const is now extended to type reference
this change allows enums to be used as const values.

All theses changes allow to encapsulate behavior in complex types so you don't 
need to DRY.

Here is a example working with bacnet:
 ['0x07' BACnetUnconfirmedServiceRequestWhoHas
 [try simple BACnetComplexTagUnsignedInteger ['0', 
'BACnetDataType.UNSIGNED_INTEGER' ] 'deviceInstanceRangeLowLimit'  ]
 [optional   BACnetComplexTagUnsignedInteger ['1', 
'BACnetDataType.UNSIGNED_INTEGER' ] 'deviceInstanceRangeHighLimit' 
'deviceInstanceRangeLowLimit != null']
 [try simple BACnetComplexTagOctetString ['2', 
'BACnetDataType.OCTET_STRING' ] 'objectIdentifier' ]
 [optional   BACnetComplexTagOctetString ['3', 
'BACnetDataType.OCTET_STRING' ] 'objectName' 'objectIdentifier == null' ]
 ]

The logic if a type matches is asserted in the type itself. The second optional 
implies when the first element appears the second must be present. The last one 
tries to read and if it fails it uses the second type.

Here is the snippet from the parent type:

[discriminatedType 'BACnetComplexTag' [uint 4 'tagNumberArgument', 
BACnetDataType 'dataType']
 [assertuint 4   'tagNumber' 
'tagNumberArgument'   ]
 [const TagClass 'tagClass'  
'TagClass.CONTEXT_SPECIFIC_TAGS'  ]
 [simpleuint 3   'lengthValueType'  
   ]
 .
 [virtual   uint 32  'actualLength' 'lengthValueType == 5 
']
 [typeSwitch 'dataType'
 
 ['OCTET_STRING' BACnetComplexTagOctetString [uint 32 'actualLength']
 // TODO: The reader expects int but uint32 get's mapped to long so 
even uint32 would easily overflow...
 [virtualuint16   
'actualLengthInBit' 'actualLength * 8']
 [simple string 'actualLengthInBit' 'ASCII'   'theString']
 ]

Would love to hear some opinions! If there are no objections I would push this 
change to develop soon.

- Sebastian

PatchContent:
Index: 
code-generation/protocol-base-mspec/src/main/antlr4/org/apache/plc4x/plugins/codegenerator/language/mspec/MSpec.g4
<+>UTF-8
===
diff --git 
a/code-generation/protocol-base-mspec/src/main/antlr4/org/apache/plc4x/plugins/codegenerator/language/mspec/MSpec.g4
 
b/code-generation/protocol-base-mspec/src/main/antlr4/org/apache/plc4x/plugins/codegenerator/language/mspec/MSpec.g4
--- 
a/code-generation/protocol-base-mspec/src/main/antlr4/org/apache/plc4x/plugins/codegenerator/language/mspec/MSpec.g4
(revision ef35531d5a872f29dccddb3a11a135b166958185)
+++ 
b/code-generation/protocol-base-mspec/src/main/antlr4/org/apache/plc4x/plugins/codegenerator/language/mspec/MSpec.g4
(date 1632518519426)
@@ -34,7 +34,7 @@
   ;
  
  fieldDefinition

- : LBRACKET field (LBRACKET params=multipleExpressions RBRACKET)? RBRACKET
+ : LBRACKET tryParse? field (LBRACKET params=multipleExpressions RBRACKET)? 
RBRACKET
   ;
  
  dataIoDefinition

@@ -49,6 +49,7 @@
   | discriminatorField
   | enumField
   | implicitField
+ | assertField
   | 

Re: [DRAFT] [ANNOUNCE] Apache PLC4X 0.9.0 released

[Łukasz Dywicki]

I'd like to propose two more points.

For drivers:
- GenericCan

For incubating elements.
- CAN Transport (Hardware Abstraction Layer)

These are things which are definitely new in 0.9.

Kind regards,
Łukasz

On 21.09.2021 19:55, Christofer Dutz wrote:

The Apache PLC4X team is pleased to announce the release of Apache PLC4X 0.9.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.

The current release contains drivers able to communicate with industrial PLCs 
using one of the following protocols:

   *   AB-ETH
   *   Beckhoff ADS
   *   CanOpen
   *   EtherNet/IP / EIP
   *   Firmata
   *   KNXNet/IP
   *   Modbus
   *   OPC UA
   *   Siemens S7 (0x32)

Beyond that we also provide integration modules for the following Apache 
projects and frameworks:

   *   Apache Calcite
   *   Apache Camel
   *   Apache Edgent (Incubating / Retired)
   *   Apache Kafka (Kafka Connect)
   *   Apache NiFi

It also provides an `OPC UA Server` which can act as a bridge between legacy 
systems and OPC UA.

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

NOTICE: In contrast to the content of the README, please be sure to build PLC4X 
at least with Java 11

Regards,
The Apache PLC4X team

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

Re: [DISCUSS] Which Java version to use as baseline?

[Łukasz Dywicki]

I believe we don't need to stress much since all our dependencies 
(except one) are still compatible with Java 1.8.


I agree that we can switch to Java 11 when 1.8 fades away. This change 
does not cost us much cause we develop (as life shown) mainly on 11 already.


Long time ago Java 11 was issue for Karaf, now it shouldn't be a case.

Best,
Łukasz

On 21.09.2021 10:30, Christofer Dutz wrote:

Hi all,

up to now PLC4J has been built in a way, that we can run PLC4J applications on 
VMs down to Java 1.8. Initially the main reason for sticking to 1.8 was that I 
knew that a lot of edge devices simply only supported Java 1.8. This might have 
changed.

Currently Java 11 seems to be the version a lot of other projects are 
targetting. I would strongly suggest that we not target any newer versions, in 
order to not exclude too many plaforms form using PLC4J.

I just had a look at the support roadmap of LTS versions from Oracle:

1.7 has ended premier support, but extended support is still available.
1.8 will be ending premier support next March (2022) and extended support is 
available till December 2030
11 will be ending premier support on Septermber 2023 and extended support on 
September 2026
17 will be the next LTS version with premier support till September 2026 and 
extened support till September 2029

Would like to reach an agreement before investing too much time in addressing 
the OPC-UA test issue with Java 1.8

My general opinion would be to stay compatible with 1.8 for now and to fix the 
issue and to move up to 11 as soon as support runs out some time next year.

Christ

Re: [VOTE] Apache PLC4X 0.9.0 RC2

[Łukasz Dywicki]

+1

 [x] Download all staged artifacts under the url specified in the 
release vote email.

 [x] Verify the SHA512 hashes.
 [x] Unzip the archive.
 [x] Build the project with empty local repo.

Best,
Łukasz

On 20.09.2021 10:39, Sebastian Rühl wrote:

+1 (binding)

Sebastian Rühl

[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] Search for SNAPSHOT references: Only found some in the dummy website copy 
in the integration-tests
[x] Search for Copyright references, and if they are in headers, make sure 
these files containing them are mentioned in the LICENSE file.
[x] Build the project according to the information in the README.md file.

On 2021/09/18 16:15:34, Christofer Dutz  wrote:

Apache PLC4X 0.9.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.9.0

Hash for the release tag: e9e9a58b057d7df827463f1262ded3a34015666a



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

[2] https://dist.apache.org/repos/dist/dev/plc4x/0.9.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

Re: [DISCUSS] Conscious Language Checker

[Łukasz Dywicki]

I don't have any strong feeling with it. I already expressed concerns in
same topic in Apache Karaf.

Making a whitelist and blacklist of words (which btw is considered
inappropriate by the tool) for technical documentation where use of
he/she/master/slave which is used only in context of a specific open
source project or communicated *hardware* is not needed.
If it doesn't serve technical purpose, and in my humble opinion it
doesn't, I would opt out. With people currently involved in project we
don't have time to take care of sonar issues. If we'd have time to work
with text then writing sufficient documentation is more important than
making it inclusive.

Best,
Łukasz

On 09.09.2021 21:08, Christofer Dutz wrote:
> Hi,
> 
> I'm forwarding this here cause I think we should discuss if we want to opt-in.
> I had a look at what's considered "not inclusive" and I don't think we would 
> have many issues in our codebase and if we do, they should be fixed easily.
> 
> As I think that unless "Hurz" is on that list, our codebase should probably 
> not be excluding anyone and I see this as an opportunity to show the world 
> that we care and we want to be an inclusive community
> 
> What do you think?
> 
> Chris
> 
> 
> -Ursprüngliche Nachricht-
> Von: Sharan Foga  
> Gesendet: Donnerstag, 9. September 2021 20:39
> An: d...@community.apache.org
> Betreff: Conscious Language Checker Tool Being Developed
> 
> Hi All
> 
> I'm posting this here as it is sort of related to my thread around tools that 
> could help with language.
> 
> A new tool is currently being developed under our  D project that is called 
> the Conscious Language Checker that can scan Apache projects repos, code and 
> highlight potential words that could be potentially inappropriate or may 
> cause offence. Like any ASF project the tool is under development and the 
> first version of it is getting a range of feedback. 
> 
> If you want to learn a bit more about the tool, help to develop it or simply 
> want to join the conversation - the discussion is happening over the 
> d...@diversity.apache.org and here is a link to the discussion thread 
> https://s.apache.org/r57ba
> 
> If you are interested in taking a look at the tool dashboard - here is the 
> link: https://clc.diversity.apache.org/ 
> 
> My understanding is that projects can opt in if they want their results to be 
> included so please feel free to join the conversation.
> 
> Thanks
> Sharan
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Re: [Reminder] Apache PLC4X community call September 8th 2021

[Łukasz Dywicki]

And here is the link:
https://us06web.zoom.us/j/91591629512?pwd=Z3A1WTdNbXRmMnZIZ2c3SVdYaHo3QT09

Turns out it is same link for all meetings. :)

Cheers,
Łukasz


On 07.09.2021 11:31, Łukasz Dywicki wrote:
> September is real.
> This mail is an reminder that tomorrow is second Wednesday of a month.
> Previous one was to early after summer season. ;-)
> On September 8th we will have our monthly community call. Call takes
> place over zoom at 19:00/7:00 PM (UTC+2).
> 
> We'll discuss nearest release plan for 0.9 and bunch of other things
> which usually come among the free fall discussions.
> Feel yourself invited!
> 
> A small note - next call, by convention, will take place on October 6th.
> It will be already in autumn. Call which you are announced is very last
> summer call in 2021 if you are on northern hemisphere.
> 
> Zoom link will follow as Chris is usual host for the meeting.
> 
> Kind regards,
> Łukasz
> 

[Reminder] Apache PLC4X community call September 8th 2021

[Łukasz Dywicki]

September is real.
This mail is an reminder that tomorrow is second Wednesday of a month.
Previous one was to early after summer season. ;-)
On September 8th we will have our monthly community call. Call takes
place over zoom at 19:00/7:00 PM (UTC+2).

We'll discuss nearest release plan for 0.9 and bunch of other things
which usually come among the free fall discussions.
Feel yourself invited!

A small note - next call, by convention, will take place on October 6th.
It will be already in autumn. Call which you are announced is very last
summer call in 2021 if you are on northern hemisphere.

Zoom link will follow as Chris is usual host for the meeting.

Kind regards,
Łukasz

Re: AW: [DISCUSS] Change the way we use "optional"

[Łukasz Dywicki]

I think I do follow your point. I don't mind getting it implemented in a
way which just works.

Maybe below example is not perfect, but shows two optional blocks nested
under each other.
[type DataBlock [uint 16 'size']
  [optional 'size > 0'
[implicit uint 32 'length' 'COUNT(data)' ]
[optional 'length' > 0'
  [array int 8 'data' count 'length' ]
]
  ]
]

If we end up with IF condition for each field then generated code will
look a bit worse, but we will survive. Not sure how "bad" generator
templates will get, but that's another story.

Best,
Łukasz


On 25.08.2021 14:24, Christofer Dutz wrote:
> Hi Lukasz,
> 
> don't understand me wrong ... I would adjust the parsers to do that ... it 
> would just be the way our generator-internal-model would keep track of it.
> 
> Problem is that for optional fields I need to generate the code differently 
> (pointers to simple types instead of direct variables)
> So the "optional" would simply ensure the code is generated respecting that.
> 
> Chris
> 
> 
> -Ursprüngliche Nachricht-
> Von: Łukasz Dywicki  
> Gesendet: Mittwoch, 25. August 2021 14:14
> An: dev@plc4x.apache.org
> Betreff: Re: [DISCUSS] Change the way we use "optional"
> 
> I see a valid point to get optional block since way pointed by Ben causes 
> creation of multiple wrappers.
> 
> Assuming that we have nested optional fields:
> [type OptionalBlock
>   [implicit uint 32 'length' 'COUNT(data)'   ]
>   [array int 8 'data' count 'length' ]
> ]
> [type DataBlock [uint 16 'size']
>   [optional OptionalBlock 'size > 0' ]
> ]
> 
> After changes it would be:
> [type DataBlock [uint 16 'size']
>   [optional 'size > 0'
> [implicit uint 32 'length' 'COUNT(data)' ]
> [array int 8 'data' count 'length'   ]
>   ]
> ]
> 
> I think that getting with optional flag under the hood will serve us near 
> term. However long term solution should introduce optional as a block into 
> our parser and generators. This will allow us to nest multiple optional 
> sections. Otherwise we will shift problem just one level down.
> 
> Since this is not a strong requirement for 0.9 we might plan this after we 
> ship nearest release.
> 
> Best,
> Łukasz
> 
> 
> On 25.08.2021 13:05, Christofer Dutz wrote:
>> Hi,
>>
>> as the discussion just came up on Slack ... taking it where it belongs 
>> ... on the list ;.)
>>
>> So the problem was, that it's difficult to have anything optional that is 
>> not a "simple" field.
>>
>> My Idea would be to change the way "optional" is used and to convert it into 
>> a wrapper element. It would just contain an expression and contain normal 
>> fields inside.
>>
>> So an
>>
>> [optional uint 8 "hurz" "some expression"]
>>
>> Would bebome:
>>
>> [optional "some expression"
>>[simple uint 8 "hurz"]
>> ]
>>
>> This way we could even wrap multiple elements inside the optional condition 
>> and all of our types.
>> In general it would simply map to an if expression.
>>
>> I doubt the changes would be very significant. We would need to add an 
>> "optional" flag to the internal field types and set that to false in the 
>> general case but to true inside an optional field.
>>
>> Chris
>>

Re: [DISCUSS] Change the way we use "optional"

[Łukasz Dywicki]

I see a valid point to get optional block since way pointed by Ben
causes creation of multiple wrappers.

Assuming that we have nested optional fields:
[type OptionalBlock
  [implicit uint 32 'length' 'COUNT(data)'   ]
  [array int 8 'data' count 'length' ]
]
[type DataBlock [uint 16 'size']
  [optional OptionalBlock 'size > 0' ]
]

After changes it would be:
[type DataBlock [uint 16 'size']
  [optional 'size > 0'
[implicit uint 32 'length' 'COUNT(data)' ]
[array int 8 'data' count 'length'   ]
  ]
]

I think that getting with optional flag under the hood will serve us
near term. However long term solution should introduce optional as a
block into our parser and generators. This will allow us to nest
multiple optional sections. Otherwise we will shift problem just one
level down.

Since this is not a strong requirement for 0.9 we might plan this after
we ship nearest release.

Best,
Łukasz


On 25.08.2021 13:05, Christofer Dutz wrote:
> Hi,
> 
> as the discussion just came up on Slack ... taking it where it belongs ... on 
> the list ;.)
> 
> So the problem was, that it's difficult to have anything optional that is not 
> a "simple" field.
> 
> My Idea would be to change the way "optional" is used and to convert it into 
> a wrapper element. It would just contain an expression and contain normal 
> fields inside.
> 
> So an
> 
> [optional uint 8 "hurz" "some expression"]
> 
> Would bebome:
> 
> [optional "some expression"
>[simple uint 8 "hurz"]
> ]
> 
> This way we could even wrap multiple elements inside the optional condition 
> and all of our types.
> In general it would simply map to an if expression.
> 
> I doubt the changes would be very significant. We would need to add an 
> "optional" flag to the internal field types and set that to false in the 
> general case but to true inside an optional field.
> 
> Chris
> 

Re: AW: Modbus RTU

[Łukasz Dywicki]

ristofer Dutz wrote:
>>>>>> Hi Stephen,
>>>>>>
>>>>>> it's not that we're dropping anything ... it's just that we
>>>>>> haven't
>>>>>> put any work into creating such a driver. Some day, if
>>>>>> someone
>>>>>> stumbles over PLC4X with the need to use ASCII, we might
>>>>>> implement it
>>>>>> for them (Mabe as a paid-gig or not).
>>>>>>
>>>>>> In the inital days of PLC4X I invested a huge amount of time
>>>>>> into
>>>>>> thinking what the industry could need ... I switched to the
>>>>>> way
>>>>>> more
>>>>>> healthy mode of implementing was is actually needed and when
>>>>>> it's
>>>>>> needed.
>>>>>>
>>>>>> But I agree ... Modbus TCP, Modbus RTU (over RS or TCP) are
>>>>>> definitely flavors we should be supporting.
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>> -Ursprüngliche Nachricht-
>>>>>> Von: Stephen Snow 
>>>>>> Gesendet: Montag, 16. August 2021 13:39
>>>>>> An: dev@plc4x.apache.org
>>>>>> Betreff: Re: Modbus RTU
>>>>>>
>>>>>> So I use modbus in all it's flavours, including modbusRTU and
>>>>>> Modbus
>>>>>> TCP. And the newer flavours Modicon is using now. Modbus RTU
>>>>>> is
>>>>>> definitely in heavy use on industrial equipment I encounter.
>>>>>> It
>>>>>> is
>>>>>> commonly a drive networking choice, and a HMI networking
>>>>>> choice.
>>>>>> So,
>>>>>> depending on what is using it ASCII is likely needed too. The
>>>>>> one
>>>>>> thing you don't want to do is drop ASCII.
>>>>>>
>>>>>> Regards,
>>>>>> Stephen
>>>>>>
>>>>>>
>>>>>> On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote:
>>>>>>> On 2021-08-15 22:40, Łukasz Dywicki wrote:
>>>>>>>> Then each driver flavor of modbus (rtu, ascii, tcp) would
>>>>>>>> simply
>>>>>>>> need to wrap and unwrap structures coming from an
>>>>>>>> transport.
>>>>>>>
>>>>>>> seeing the ascii variant since the 1980s or early 1990s.
>>>>>>> IIUIC,
>>>>>>> it
>>>>>>> was
>>>>>>> mostly used for hand terminals, and not to connect to
>>>>>>> computers.
>>>>>>> So I wouldn't spend time on that, unless nothing else is
>>>>>>> around.
>>>>>>>
>>>>>>> I haven't checked the mspec in details, but I suspect it is
>>>>>>> close
>>>>>>> to
>>>>>>> fair amount of equipment has extensions that are not in the
>>>>>>> specification (well, at least last time I read it about 20
>>>>>>> years
>>>>>>> ago),
>>>>>>> namely floating point numbers and 32/64-bit integers. It
>>>>>>> would
>>>>>>> be
>>>>>>> neat
>>>>>>> to support that...
>>>>>>>
>>>>>>> Unfortunately, I don't have cycles to help out with it.
>>>>>>>
>>>>>>> Cheers
>>>>>>> Niclas
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
> 
> 

Re: Modbus RTU

[Łukasz Dywicki]

I think that in some ways what you described defines a close form of
"canonical" modbus. We know that modbus uses PDU and A(P)DU with some
info about function code and data blocks. We could simply update
protocol logic to rely on these *without* relying on specific encoding.
Then each driver flavor of modbus (rtu, ascii, tcp) would simply need to
wrap and unwrap structures coming from an transport.
Please have a look on stack configurer changes (currently stuck in
can-stack-tunning feature branch):
https://github.com/apache/plc4x/blob/2530287ec3982bb685700e76e956a0141ebc45cd/plc4j/drivers/canopen/src/main/java/org/apache/plc4x/java/canopen/CANOpenPlcDriver.java#L126L139
Changes which Sebastian helped me with in May this year will allow you
to customize protocol instantiation. Effectively it opens a path to
chain or wrap protocol logic needed by driver.

I believe that it is essential to keep protocol logic unified and
encoding/decoding separated. If we will need to copy logic for each
modbus flavor then very soon we will have more than 3 drivers only for that.
Not that I am against of supporting all of them. I am just afraid that
we might get into trouble making them consistent.

Cheers,
Łukasz

On 15.08.2021 22:04, Ben Hutcheson wrote:
> Just looking at implementing Modbus RTU and have a couple of options around
> it's structure, that I wanted to get opinions on.
> 
> The protocol uses two main data structures, an ADU and a PDU. The PDU is
> the main part of modbus and has all the function codes and data included in
> it. This is the same for modbus tcp and rtu. The ADU wraps the PDU to
> provide additional data such as address and CRC fields.
> 
> RTU is very similar to modbus TCP with only the ADU format changing that
> wraps the PDU. As it is very similar it could be possible to reuse the
> existing mspec with the addition of an RTU ADU. And then use this ADU in
> the RTU protocol logic.
> 
> The protocol logic I think is going to be different enough to warrant an
> entirely new version as opposed to implementing switches in the current
> logic, which I think could get confusing very quickly. It also has the
> added benefit of allowing odd specs like Modbus RTU over TCP trivially.
> 
> The protocol identifier I'm looking at using is modbus-rtu. I dislike it as
> the original modbus tcp one is just modbus and not modbus-tcp. But figured
> it's the better option.
> 
> Ben
> 

Re: AW: ADS Subscriptions for >0.8

[Łukasz Dywicki]

Hey Richard,
If you want to confirm protocol to mspec mapping then use
ParserSerializerTestsuite. It ensures that parsing and serializing is
linear. All these tests confirm that we get exactly same binary output
from given binary input. This helps a lot to spot gaps in mappings or
incorrect endianness.
If you wish to verify protocol and behavior of driver then you need to
use DriverTestsuite. It allows to simulate a PLC4X client API call as
well as trigger bogus PLC answers. Transport used for test is a virtual
pipeline which makes it quite easy to inject invalid or wrong packets.
Driver test can be seen as sequence of steps which happen one by one. As
long as your driver does not do any background threads it will work.
A typical sequence is like this:
1) API request for field "foo"
2) driver emits frame X
3) plc responds with frame y
4) API result is "bar"
I don't think we have support for subscriptions in driver test suites. I
guess we need to add it. We definitely have support for read and write. ;)

Regarding the "" tag you asked. This part for serializetion test
comes from "data" section of TCP or UDP packet/frame. Each of them have
header with sender, receiver and so on. These headers are not relevant
from PLC4X protocol implementation as these are handled by operating
system network stack and put into various structs of Java standard library.
What we process is actually a "data" or "payload" section of an incoming
packet. Please note that in case of TCP which handles segmentation test
suites assume that data is fully assembled. There is no way to simulate
chunked TCP stream.

Best,
Łukasz

On 13.08.2021 18:04, Richard Meister wrote:
> Hi Łukasz,
> 
> thank you for these hints! I've just created a PR.
> 
> Maybe I'll add some test cases as well, but currently I'm not sure where to 
> put them, DriverTestsuite or ParserSerializerTestsuite (or both?).
> 
> 2c00c0a8171401015303c0a817c801015303020004000c00020005f0801a0100
> Are these raw elements constructed by hand or take from a recording/pcap file?
> 
> 
> Best regards,
> Richard
> 
> -Ursprüngliche Nachricht-
> Von: Łukasz Dywicki [mailto:l...@code-house.org] 
> Gesendet: Mittwoch, 4. August 2021 18:48
> An: dev@plc4x.apache.org
> Betreff: Re: ADS Subscriptions for >0.8
> 
> Hey Richard,
> Before you go and spend time on Request Transaction Manager (RTM) - please 
> note that it does impact sending of requests, also for subscriptions, but 
> does not block incoming packets. This is an coordination mechanism for plc4x 
> to control data link access.
> Since I haven't looked nor compared ADS driver logic between releases you did 
> mention I suppose that we simply missed a handling of subscriptions in this 
> or other way. This logic should be portable with little effort. My suggestion 
> towards you is to compare these parts of drivers to see how 0.8 or 0.9 
> evolved.
> 
> The only case when RTM comes into the play is when you do want to send 
> another request once you receive answer for previous one. In such cases you 
> need to do everything inside transaction runnable which accquired the 'lock'. 
> Also make sure that you release it both for success and failure scenarios.
> If you fail to release transaction then your subsequent requests will get 
> stuck. It is fairly easy to spot if you do smaller changes.
> 
> Kind regards,
> Łukasz
> 
> śr., 4 sie 2021 o 17:41 Richard Meister 
> napisał(a):
> 
>> Hi Christofer,
>>
>> thank you for the quick response and good to hear there is no specific 
>> technical reason. I will give it a go and come back with a PR and
>> (probably) more questions :)
>>
>>
>> Regards,
>> Richard
>>
>> -Ursprüngliche Nachricht-
>> Von: Christofer Dutz [mailto:christofer.d...@c-ware.de]
>> Gesendet: Mittwoch, 4. August 2021 17:05
>> An: dev@plc4x.apache.org
>> Betreff: AW: ADS Subscriptions for >0.8
>>
>> Hi Richard,
>>
>> first of all, welcome and happy you like our little project :-)
>>
>> There is no technical reason for us not supporting subscriptions. In 
>> general the only reason is that when I re-wrote the driver from 0.6 to 
>> 0.8 I switched from single-item requests to multi-item requests. There 
>> was some semi-documentation on this for read and write. However not 
>> for subscriptions. So this would require some reverse-engineering work 
>> and I simply didn't have the time for that.
>>
>> I think this would definitely be something we'll be providing in the 
>> future ... I just can't say when I'll have the time for it.
>>
>> If this however is something you and your company need

Re: AW: ModBus set slaveId...

[Łukasz Dywicki]

Is there other story about how many bells the man hit before he got old
and respected to ask for 1011 Livres? ;-)

Cheers!

On 12.08.2021 19:10, Niclas Hedhman wrote:
> On 2021-08-12 17:56, Christofer Dutz wrote:
>> Those tasks are always my favorites :-)
>>
>> Helping people without having to do anything ;-)
> 
> A long time ago, a church bell in a French village was out of tune and
> they sent for a bell master to come and fix it. And sure enough an old
> man came, they let him hear the awful bell sound. He borrowed a ladder,
> picked a big hammer out of his luggage and climbed the bell tower. Once
> up there, he whacked the bell once, then climbed down and told them to
> ring the bell again. It now had the perfect sound as it was intended.
> He handed them the bill of 1011 Livres, a small fortune even for this
> relatively prosperous village. "How come so much? Only took you 10
> minutes and no material.". The bell master explained, "1 Livre for wear
> on the hammer, 10 Livres for the long travel and 1000 Livres for knowing
> where to hit."
> 
> 
> Cheers
> Niclas

Re: ModBus observe connection state...

[Łukasz Dywicki]

Indeed the connection state tracking is not available in present version.
I began working on that as part of feature branch which should be merged
soon:
https://github.com/apache/plc4x/pull/241

There are few new things:
1) EventListener (connection, message)
2) EventPlcConnection

With these it will be possible to receive connection shutdown on client
side. With this it will be possible to detect disconnection through
wrapping netty apis.
This is intended to get merged into 0.9.

Best,
Łukasz

On 12.08.2021 08:21, Andreas Vogler wrote:
> Hi,
> 
> How can I check the state of a connection? Especially if it is lost.
> 
> I have a ModBus connection and when I turn off the ModBus server I do not get 
> any error. 
> 
> I have found the orTimeout option at the response object… 
> 
> But I want somehow detect if a connection is lost, so that I can do a 
> reconnect…
> 
> Hope someone can give me an advice how this is typically done with Plc4x.
> 
> Regard,
> Andreas
> 

Re: ADS Subscriptions for >0.8

[Łukasz Dywicki]

Hey Richard,
Before you go and spend time on Request Transaction Manager (RTM) - please
note that it does impact sending of requests, also for subscriptions, but
does not block incoming packets. This is an coordination mechanism for
plc4x to control data link access.
Since I haven't looked nor compared ADS driver logic between releases you
did mention I suppose that we simply missed a handling of subscriptions in
this or other way. This logic should be portable with little effort. My
suggestion towards you is to compare these parts of drivers to see how 0.8
or 0.9 evolved.

The only case when RTM comes into the play is when you do want to send
another request once you receive answer for previous one. In such cases you
need to do everything inside transaction runnable which accquired the
'lock'. Also make sure that you release it both for success and failure
scenarios.
If you fail to release transaction then your subsequent requests will get
stuck. It is fairly easy to spot if you do smaller changes.

Kind regards,
Łukasz

śr., 4 sie 2021 o 17:41 Richard Meister 
napisał(a):

> Hi Christofer,
>
> thank you for the quick response and good to hear there is no specific
> technical reason. I will give it a go and come back with a PR and
> (probably) more questions :)
>
>
> Regards,
> Richard
>
> -Ursprüngliche Nachricht-
> Von: Christofer Dutz [mailto:christofer.d...@c-ware.de]
> Gesendet: Mittwoch, 4. August 2021 17:05
> An: dev@plc4x.apache.org
> Betreff: AW: ADS Subscriptions for >0.8
>
> Hi Richard,
>
> first of all, welcome and happy you like our little project :-)
>
> There is no technical reason for us not supporting subscriptions. In
> general the only reason is that when I re-wrote the driver from 0.6 to 0.8
> I switched from single-item requests to multi-item requests. There was some
> semi-documentation on this for read and write. However not for
> subscriptions. So this would require some reverse-engineering work and I
> simply didn't have the time for that.
>
> I think this would definitely be something we'll be providing in the
> future ... I just can't say when I'll have the time for it.
>
> If this however is something you and your company need, feel free to work
> on this ... I'd be willing to be of assistance as long as the results go
> back into the open-source project.
>
> Or if you're willing to put a few bucks on the table this definitely can
> help shift some priorities ;-)
>
> Chris
>
>
> -Ursprüngliche Nachricht-
> Von: Richard Meister 
> Gesendet: Mittwoch, 4. August 2021 16:30
> An: dev@plc4x.apache.org
> Betreff: ADS Subscriptions for >0.8
>
> Hi everyone,
>
> first of all, thank you for creating and maintaining this project! PLC4X
> helped us to get started with ADS in Java quickly and painlessly.
>
> The matter of my writing is that we use subscriptions as the primary
> communication mode for ADS, so to the best of my knowledge we're bound to
> v0.6(.1). We've applied a patch to set the cycleTime in AdsTcpPlcConnection
> to zero, because otherwise we would miss changes that occur more frequently
> than once per 400ms.
> Probably there are some good reasons that subscriptions do not work with
> the generated driver. I have poked a bit into the code of v0.8 and presume
> it is a restriction of the RequestTransactionManager. But before taking a
> deep dive into the code I thought I'd hear your thoughts on this first.
> Maybe someone can point me into the right direction and enable me to
> contribute. I'm willing to spend time on this and I have access to a
> Beckhoff iPC with TwinCat 2 for testing.
>
>
> Cheers,
> Richard
>
>
>
>

[Reminder] Apache PLC4X community call August 4th 2021

[Łukasz Dywicki]

May the August be with you,
This message is a reminder that closest Wednesday 4th August 2021 is a
first Wednesday of the month. This means that we have our community call
hosted at zoom.
Given that, next event will be held in September this is last chance to get
summer drinks with the team!

Kind regards,
Łukasz

Re: OPCUA PR

[Łukasz Dywicki]

Hey Ben,
You made an titanic effort bringing OPC UA into project, thus many
thanks for bringing it to life. Not sure how our community will be able
to pay back your effort!

I will express my though on open source. From my personal perspective
breaking things is not a bad thing at all. This is an open source
project which lives and still move.
Anyone who uses the project without contributions "takes" its value for
free. Sometimes, however projects needs additional help, and that's time
when users can start "giving back". I do hope that changing this
particular driver implementation will actually trigger more
contributions from outside.
There are costs associated with development which you took up to great
extent. Now its time for users and project team to balance that.

As matter of fact, if you drop a line or two how you tested the driver
with another software/hardware, then we can provide a clear guide how to
replicate your dev environment and let others continue the work.

Once again, thank your very much for your effort. I am looking forward
to get you back soon!

Best,
Łukasz

On 21.07.2021 16:09, Ben Hutcheson wrote:
> Hi,
> 
> I will not be able to work on the native opcua branch for a while, but
> there really isn't much to do for it to be finished.
> 
> Would someone be available to work on it?
> 
> As far as I know the only thing outstanding is to split the messages being
> sent out into manageable chunks if they are too big (really only an issue
> if the server requests a small max message size, for reference the smallest
> value allowed is 8k, I think milo uses something like 256k) This should be
> done within SecureChannel->submit. Handling of message chunks has already
> been completed when receiving them.
> 
> The max size of the message is discovered from the
> OpenSecureChannelResponse message. The max chunk count and max receive/send
> buffer sizes are used to calculate the max message size and max number of
> chunks.
> 
> Apart from that, the branch should be in a position to be merged.
> 
> This branch has been setup so that username authentication can be used for
> connections, which would solve the problem for one of the other mailing
> list questions.
> 
> Kind Regards
> 
> Ben
> 

Re: AW: Further updates to CAN stuff in plc4j

[Łukasz Dywicki]

apter(),
  new CANOpenFrameDataHandler(trans.getTransportFrameBuilder())
);
  })
  .withDriverContext(cfg -> new CANOpenDriverContext())
  .withPacketSizeEstimator(cfg -> trans.getEstimator())
  .littleEndian()
  .build();

For now the CANDriverAdapter is very close to netty apis we have. Not in
terms of what it does, but in masking the sendToWire methods.
It was necessary to inject additional translation logic implemented by
driver frame handler. It is a bit unfortunate that there is no better
way, especially that ConversationContext and SendRequestContext have own
quirks which may cause additional maintenance cost in there.

With all this I guess we might be able to see if this is portable to
other drivers, especially ones which do rely on raw ethernet! :)

Best,
Łukasz


On 14.04.2021 02:36, Łukasz Dywicki wrote:
> I began to scratch surface of Driver/Protocol/Context and here is what I
> found.
> 
> Currently it is *impossible* to do any customization with
> ProtocolStackConfigurer or GeneratedDriverBase without really copying
> whole classes.
> Trouble I see is:
> 1) Protocol stack configurer rely on classes instead of actual instances.
> Is there any reason why packet estimator and byte discarder are passed
> there as classes and not actual instances? These are functions which
> *should* not have side effects hence we should not require an reflection
> to create instance of these.
> 2) Driver which is asked to create protocol stack has *no access* to
> actual configuration.
> 3) Transport is "lost in transition" while creating pipelines.
> It is not retained nor accessible to stack configurer making it
> impossible to ie. make transport dependent stack configuration. As much
> as this situation is not very common. yet we either force user to pass
> extra URL parameters or let drivers do their defaults based on transport.
> 
> Very simplified startup flow for driver is:
> 
> generated driver initialization ->
>   create configuration
>   find transport ->
> configure transport
> transport -> create channel factory
>   create connection ->
> create field handler
> create value handler
> create stack configurer
> 
> My proposal is to switch it to:
>   create configuration
>   find transport ->
> configure transport
> transport -> create channel factory
>   create connection ->
> create field handler
> create value handler
> create stack configurer*(configuration, transport)*
> 
> Another finding I have - estimators and discarders are created by
> reflection in hope to receive configuration from URI parameters.
> Such situation so far does not happen and I think its rather rare (yet
> we can face it some day), thus I would opt for having configuration
> calls with them, however I would move that part from stack configurer
> above - to the driver. In case if driver expects configuration options
> for its wire processors it must enable it explicitly.
> This will also leave a space to create base class for CAN drivers and
> utilize transport and configuration to create estimator and discarder
> dynamically.
> 
> Looking forward to hear your opinion about above changes.
> 
> Best,
> Łukasz
> 
> On 29.03.2021 06:43, Andreas Oswald wrote:
>> Hi Łukasz,, hi everybody,
>>
>> that sounds pretty interesting, do you have plans to to implement "higher 
>> level" protocols based on CAN e.g. UDS? Maybe we should exchange ideas as my 
>> daytime job ist about developing a software package that takes care of 
>> Software Versions and parameter sets for electrical vans, where we rely 
>> heavily on UDS. Unfortunately not all of our ECUs implement fine UDS.
>>
>> When Chris introduced me to the project I guess a bit more than two years 
>> ago, Slack was the medium to use.
>>
>> Maybe someone can give me a hint about how communication is dealt with.
>>
>> Good to be back 
>>
>> Have a great start for the new week.
>>
>> Take care
>>
>> Andreas
>>
>> Andreas Oswald
>> Marienstraße 12
>> 52223 Stolberg
>> Germany
>>
>> ++49 2402 905 3852
>> ++49 172   426 1598 (also Signal)
>> WhatsApp/Telegram on ++49 157/38459358
>>
>> 
>> Von: Łukasz Dywicki 
>> Gesendet: Montag, 29. März 2021 02:18
>> An: dev@plc4x.apache.org 
>> Betreff: Further updates to CAN stuff in plc4j
>>
>> Hey all,
>> I began to think how to cover basic interactions with CAN bus which
>> could serve a custom systems or ones which are closer to some narrow
>> cases. My intention here is to offer simplest possible way to become
>> CA

Re: [DISCUSS] Discover and Browse API for PLC4J?

[Łukasz Dywicki]

Hey Chris,
Indeed - discovery is about finding interfaces/devices while browsing is
already interacting with them. I believe that in most of cases once
discovery is done browsing uses same transport as PLC connection itself.
At least this would be logical consequence. If someone knows other case
then it is right time to speak! :-)

The AMS discovery answer returns you AMS net id of a node, so you know
IP of PLC and also its logical network identifier. As you pointed
usually it is just an .1.1. I actually use this convention when
making discovery caller ams. It is just my-ip + 1.1.
What we miss is a ams port (by default there is 851, but there are
others and it can vary). The user and password is needed only for route
setup, if you have route set up on PLC then this step is not necessary.
Anyhow, I think we need to have a look on OPC UA discovery (which is a
separate sub-spec) to see if we're set on discovery inputs. Given its
verbosity I do expect additional set of requirements coming from that end.

For KNX I see indeed a similarity between CANopen (and profinet) how
node discovery could work. All these are "bus systems" thus connection
is not a point to point. In their case we see multiple participants
which are listening to a single communication channel. As soon as we
acquire link we can discover and browse through it.

A short note. I am not sure if we could automate plain CAN discovery,
cause then we have 11 bit identifier which can be anything. Role of
these 11 bits is known only if we assume CANopen.
In worst case basic CAN could lead to us to discovery of up to 4095 CAN
nodes. ;-)

Anyhow, I believe what you have sketched is pretty clear.

Best,
Łukasz


On 02.07.2021 18:23, Christofer Dutz wrote:
> Hi Lukasz,
> 
> so from what I read I sort of think you also agree that "Discovery"
> should find devices and the result is connection information we can then
> pass to the DriverManager to get a connection. And Browse will result
> with fields (Or parsed address strings) for a given connection.
> 
> I think in the ADS Case ... we shouldn't do the setting up of ADS Routes
> as it involves sending a servers Admin password in clear text. However I
> think we are able to find an ADS device. As with ADS you also have to
> provide the source and targer ams net id, it will be challenging to
> guess these (Or does the discovery handle that?). However we could
> assume the default of "appending  ".1.1" to the local IP which seems to
> be quite established. If however the discovery allows the listing up of
> AMSNetIds a device running on a given IP has, this would be awesome.
> 
> I think KNX and CAN can be considered a bit similar regarding what's a
> device and what's a ressouce. For KNX we currently consider the KNXNetIP
> Gateway the device (and therefore the connection string only has the
> coordinates to connect to that) and then the KNX Devices on the KNXBus
> are considered Resources which are found by a Browse operation.
> When thinking of KNX I would consider the Device resources sort of like
> with S7 ... the KNX Device on the KNX Bus is the DataBlock and the
> resource on the device is the address relative to that DataBlock. So if
> I want to read a parameter of a KNX device, then I add the parmeter
> coordinates to the knx address which makes up the field address in PLC4X.
> 
> It looks like it should be possible to bring the CAN driver into
> supporting the same mechanisms here too.
> 
> Chris
> 
> On 02.07.21 17:53, Łukasz Dywicki wrote:
>> Hey Chris,
>> I do agree that browse and discovery is different and it might be either
>> expanded or narrowed.
>>
>> For example openHAB stuff I did based on CANopen driver does following:
>> - Discovery of CAN enabled interface
>> For linux it is quite straight cause you can use either a "net" part of
>> sysfs or even a dbus [1] in order to find interesting network nodes.
>> - Discvoery of CANopen nodes
>> Depending on strategy this could be a scan with predefined address range
>> or simply listen who talks to the bus. For CANopen scan is quite
>> straight, cause there is up to 127 nodes. You can submit a read out
>> request for well known register address, ie. manufacturer code.
>> Listening is also possible cause each node should (in theory) emit a
>> heartbeat.
>> - Discovery of CANopen fields readable or writable via driver.
>> This is scan of node registers within predefined address ranges or
>> ranges retrieved from initial node read out.
>> I don't have this part (nor didn't plan to work on it anytime soon).
>> This is probably a thing which is most interesting in case of data
>> acquisition.
>>
>> Process is following:
>> - [discovery] Physical interface [0..N

Re: [DISCUSS] Discover and Browse API for PLC4J?

[Łukasz Dywicki]

Hey Chris,
I do agree that browse and discovery is different and it might be either
expanded or narrowed.

For example openHAB stuff I did based on CANopen driver does following:
- Discovery of CAN enabled interface
For linux it is quite straight cause you can use either a "net" part of
sysfs or even a dbus [1] in order to find interesting network nodes.
- Discvoery of CANopen nodes
Depending on strategy this could be a scan with predefined address range
or simply listen who talks to the bus. For CANopen scan is quite
straight, cause there is up to 127 nodes. You can submit a read out
request for well known register address, ie. manufacturer code.
Listening is also possible cause each node should (in theory) emit a
heartbeat.
- Discovery of CANopen fields readable or writable via driver.
This is scan of node registers within predefined address ranges or
ranges retrieved from initial node read out.
I don't have this part (nor didn't plan to work on it anytime soon).
This is probably a thing which is most interesting in case of data
acquisition.

Process is following:
- [discovery] Physical interface [0..N]
- [discovery] Discovery connection string [1:1] (?)
- [discovery/browse] Finding accessible nodes [0..N]
- [browse] Fields for a specific node [0..N]

Discovery of Beckhoff stuff I did works in a following way:
- Find network interfaces
- Send broadcast over network interface
- For each answered node
  - Try setting up a ADS route (requires PLC username and password)
  - Connect
  - Retrieve symbols (I did not implement this)
Beckhoff uses a UDP for discovery and connection to PLC is over TCP thus
you can clearly see that there are two different transports used. I
believe KNX is same.
For Profinet-DCP what I managed to complete with Adrian is focused only
on two parts:
- Finding accessible profinet devices
Since they do answer with their own datas we can get their MAC which is
later on used to communicate with them. Initial mapping of DCP ident
response I did mapped that response to PlcStruct. Mainly because there
are multiple fields which can come, including device name, DHCP settings
or its ip address.

Given the nature of node discovery it should by default stick with
callbacks and not request/response modes. Browse is something we briefly
spooked before, but it also fails into same category. We never know if
discovery or browse is finite or not. For that reason API should rather
assume later than earlier and let driver decide.
For address range queries we indeed can have a progress indication,
while for PN-DCP I don't think we should make any assumptions. I am not
quire sure how big PN network can be, so I'll let others speak.

In my understanding, also based on above openHAB experiences, discovery
and browse APIs are kind of related, yet have different syntax.
For Beckhoff definitely we get some parts for transportUrl options such
as node AMS id which is advertised in identification response.
For AMS there is also an authentication, however I don't think we're
able to scrap this. In new versions I think there might be also a device
certificate signature.

Anyhow, these would be my 0.02€ of input.

Best,
Łukasz

On 02.07.2021 17:02, Otto Fowler wrote:
>  Some protocols the discovery process returns information about the device
> (DCP, ENIP) , that might be important as well.  How would this be handled /
> modeled ?
> 
> The idea here is that plc4x doesn’t store any of this right?  You’d have to
> handle the callback and store the information yourself?
> 
> From: Christofer Dutz 
> 
> Reply: dev@plc4x.apache.org  
> Date: June 30, 2021 at 13:53:32
> To: dev@plc4x.apache.org  
> Subject:  [DISCUSS] Discover and Browse API for PLC4J?
> 
> Hi all,
> 
> as you all know, I have threatened to bring API additions from plc4go
> br/>back to plc4j and now the time has come. But I want to invollve you all
> br/>in it as we all have to live with it ;-) <
> 
> So in general in go I did it the following way:
> 
> - I split the topic up into "Discovery" and "Browse"
> 
> "Browse" I'll focus on as soon ad "Discovery" is defined. In general
> br/>this should produce a stream of PlcBrowseEvents whichh provide a stream
> br/>of PlcFField entries that can be used to query information. So this is
> br/>inside an established connection to a device. It won't find devices
> br/>(However this term is slightly ambbiguous because in KNX for example we
> br/>consider a KNX devices GrouupAddress an address, even if in the
> physical br/>world it actually iis a device)
> 
> Discovery is the operation of finding out which devices we can connect
> br/>to. The result is a list of PlcDiscoveryEvents. These contaain:
> - protocolCode (like s7, modbus, ...)
> - transportCode (like tcp, udp, serial, ...)
> - transportUrl (which is the part after the "://" but before the "?"
> - option (which is a map of key-value pairs making up the part after the
> br/>""?"  the part which Lukazs hates so much ;-) )
> 
> In go I extended the 

Re: Help required on Beckhoff PLC connection to a JAVA OSGi Framework project

[Łukasz Dywicki]

Hey Palaniswamy,
Welcome on mailing lists.

For OSGi to get whole thing working there are few things necessary.
Problem which you face is related to visibility of resources between
isolated class-loaders. Normally with "flat classpath" you get in
regular web or standalone applications scanning of classpath can
enumerate all resources. That's not a case with OSGi.
Driver manager in current form can't work without further enhancements
which will expose META-INF/services entries. There were some high level
attempts to solve that using Aries Spifly, yet I never really got it
working.

A proper way for most of situations within OSGi is to rely on services.
This is reason why we have activators (called only under OSGi) which can
replace META-INF/services lookups and work dynamically. Just like whole
environment does.
You can use OSGi services registered by driver itself. It will let you
calling getConnection method directly. Syntax for URI is the same as for
driver manager.

You might need some further adjustments in order to get transport stuff
which does another META-INF lookup for Transport SPI.

Best,
Łukasz


On 09.06.2021 21:33, Palaniswamy, Lakshimi Narayanan (ETI) wrote:
> Hello Community,
> 
> I am currently working with an OSGi framework based Open-Source Energy 
> Management System OpenEMS (https://openems.io/). As a part of the development 
> we wanted to integrate a Beckhoff PLC, which offers a ADS bridge-Modbus TCP 
> Protocol for communication. Although I found a DLL offered by Beckhoff 
> (https://infosys.beckhoff.com/index.php?content=../content/1031/tcadscommon/html/note.htm=),
>  it did not fit perfectly for the case of OpenEMS due to its OSGi Framework. 
> Thankfully I found the PLC4x adaptor. It really solves half the problem for 
> me. I would also like to mention I am quiet new to OSGi as well as JAVA to 
> begin with and am trying to figure things out on the go.
> 
> Now to my question. I wanted to use the PLC4j/ADS drivers and functionalities 
> in my code. I started with the basic setup mentioned in the "JAVA Getting 
> Started" page of the PLC4x. When I used the following code: 
> PLCDriverManager().getConnection("ads:tcp://xxx.xx.x.xx:502") to establish 
> the connection. I get an error saying "Unable to find driver for protocol 
> 'ads'". It was weird because if had added all (I hope so) the dependencies 
> required as follows:
> 
> 
> org.apache.plc4x
> plc4j-api
> 0.8.0
> 
> 
> 
> 
> org.apache.plc4x
> 
> plc4j-driver-ads
> 
> 0.8.0
> 
> runtime
> 
> 
> 
> Later I found out that, for OSGi framework, the Drivers are required to be 
> activated 
> (https://github.com/apache/plc4x/blob/develop/plc4j/osgi/src/main/java/org/apache/plc4x/java/osgi/DriverActivator.java
>  ), so that it creates a bundle. But now I am really not sure how this is 
> done. Could someone please help me out with this. If there are any tutorials 
> or examples for such a case, please share it.
> 
> As I said before, we intend in integrating a Beckhoff PLC running TwinCAT 
> ADS, into a JAVA OSGi based framework, which would be communicating with each 
> other over Modbus TCP protocol.
> 
> Viele Grüße
> Laksh
> 
>