Re: Anyone here experience with Emerson DeltaV communication?

[Niclas Hedhman]

--- a.txt2018-06-12 11:47:24.0 +0800
+++ b.txt2018-06-12 11:47:37.0 +0800
@@ -11,7 +11,7 @@

 But for now … done enough hex-dump-reading for today …

-#ifdef PLC
+#ifndef PLC
 #define PLC = Plenty of Lovely Craftbeer
 #endif



On Sat, Jun 9, 2018 at 12:00 AM, Christofer Dutz 
wrote:

> Hi all,
>
> today I had a very interesting appointment with a large pharmaceutical
> company which are planning on giving PLC4X a try. If this works this would
> be a huge thing for our project as well as that company.
> After discussing multiple options of safely communicating PLC data from
> inside the production-network to a less safe network, we started
> investigating the protocols going over the wire.
>
> The controllers used are Emerson DeltaV MV Controllers and they
> communicate with a matching Emerson OS (Operator-System … not OperatING
> System) … for me this is sort of a Emerson SCADA System.
>
> What directly popped my eye was that all communication is done using UDP
> on port 18507 and every packet sent starts with the first two bytes “0xFA”
> and “0xCE” … “FACE” … I couldn’t find any mention of a protocol name and
> hereby no spec or whatsoever information. Right now I’m doing a manual
> pattern detection in my WireShark recording and will definitely start
> automating that to prove my assumptions.
>
> But I was hoping that someone here on the list might be able to provide
> some information and eventually give me the one or the other useful hint.
>
> But for now … done enough hex-dump-reading for today …
>
> #ifdef PLC
> #define PLC = Plenty of Lovely Craftbeer
> #endif
>
> Have a nice weekend :-)
>
> Chris
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Master ? Slave? Both?

[Niclas Hedhman]

I am getting the impression that only "Master" side of these protocols are
in scope. Or?

In any case, I have previously made a C library for ModBus (from spec), and
I could see if it is worth dusting off and contribute. Is it of interest,
or? It might not be complete, and I recall it follows a OO-style of C
programming that not everyone appreciate.


Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Master ? Slave? Both?

[Niclas Hedhman]

Alright... I also forgot that these protocols are now TCP/IP capable, and I
have no clue what that means. In the old serial comm world it was much
clearer.

Cheers
Niclas

On Sun, Dec 31, 2017 at 6:53 PM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:

> Hi Niclas,
>
> well I wouldn’t say that we should do just Master. I guess right now
> development has been driven by the use case. And the probably most
> important use case for me was reading from an S7. One use case down the S7
> road that I would like to implement soon is that a client using PLC4X can
> subscribe for Alarm messages and Parameter values of a S7 PLC and that then
> actively sends data to PLC4X. Would that be called “slave”? If it is, I
> guess both are highly important, just haven’t got to the point of
> implementing that.
>
> Chris
>
>
>
> Am 31.12.17, 05:02 schrieb "hedh...@gmail.com im Auftrag von Niclas
> Hedhman" <hedh...@gmail.com im Auftrag von nic...@hedhman.org>:
>
> I am getting the impression that only "Master" side of these protocols
> are
> in scope. Or?
>
> In any case, I have previously made a C library for ModBus (from
> spec), and
> I could see if it is worth dusting off and contribute. Is it of
> interest,
> or? It might not be complete, and I recall it follows a OO-style of C
> programming that not everyone appreciate.
>
>
> Cheers
>     --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Serialport comms?

[Niclas Hedhman]

Hi,
I was thinking about converting some of my protocol implementations to
plc4x, but I have only worked in the serialport space, (e.g Modbus/RTU
rather than Modbus/TCP).

There is a ancient Java specification (Java Comms API), which is not only
literally from last millennium, but rather poor as well.

So, what choices do we have?

* GNU has an implementation, which is rather bad Java code and the C/native
side needed a bit tweaking last time I worked with it.

* The best implementation I know is commercial, but perhaps we can entice a
code donation and/or a Apache Licensed API. I'll investigate that one...

* Our own implementation from scratch, which kind of belongs in Apache APR,
at least the C/native part.


Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Is Junit5 the way to go?

[Niclas Hedhman]

The difference between Junit4 and Junit5 are relatively minor from a user's
perspective. The real difference is when creating Runners for special need
systems, such as Spring

So, going with JUnit4 for now is not a bad thing...

But, it seems that there is some legacy that should be scrapped, because it
actually makes a difference.


Avoid the Assert.isEqual(), Assert.isTrue() and so on, and only use the
Hamcrest library for conditions, i.e. assertThat.
The benefit is that one can use (or make) much more complex tests, which
are otherwise ugly to write or report back what is expected.

assertThat( myInteger, equalTo( 15 ) );

assertThat( myCollection, hasItem( "Niclas" ));

assertThat( myCollection, hasItems( "Niclas", "Justin", "Chris" ));

Arbitrarily complex matchers can be made, and give a reasonable error
message when failing.


If I can find some time in the next couple of days, I will take a look and
propose changes...


On Feb 9, 2018 16:35, "Justin Mclean"  wrote:

> Hi,
>
> > thanks for finding that ... guess when porting all these thousands of
> statements, I must have missed one or two "replace: ' == ' with
> ').isEqualTo('” __
>
> Yep I can imaging my brain zoning out when doing that :-)
>
> > Well the main reason was probably, that I wanted to replace the
> "assertTrue(A==B)" with something like "assertEqual(A, B)" as this outputs
> the "expected" and the actual "value" and hereby provides a little more
> information than a simple "was false". So I had the option of converting it
> to JUint "Assert.assertEquals" or update it to AssertJ's
> "Assertions.assertThat().isEqualTo()" which I think is a little more
> readable
>
> You know that Junit4 also has a assertThat? It’s has a slightly different
> signature which what threw me when I first looked at the changes.
>
> Thanks,
> Justin

Re: Is Junit5 the way to go?

[Niclas Hedhman]

Personally, I find the AssertJ (and practically all other attempts at this)
less powerful and harder to work with, as the DSL is not necessarily
intuitive, well it isn't for me when writing it, although one can guess
what it means when reading it, but perhaps that is the case for Hamcrest
too for other people. Additionally, if you ONLY know JUnit4, then a subset
of Hamcrest is already included inside the JUnit jar file. In essence, both
AssertJ and Hamcrest was a "solution" to the older JUnit assertion
mechanism.

In AssertJ, there seems to be a "bias" towards creating your own Unit Test
Assertion classes, so that the tests reads more nicely. And in Hamcrest,
the "bias" is towards creating a ever-growing library of generic assertions
independent of the unit tests at hand. IMHO, the former can still be done
in Hamcrest, but I have not seen that, and I have also seldom seen anyone
creating their own AssertJ assertion classes.

Across the Java community, more people are comfortable with Hamcrest than
AssertJ, probably due to Junit's inclusion of some of it.

My recommendation is to use JUnit4 + Hamcrest library + creating PLC4X
specific Matchers (if needed).


I spent this morning changing the AssertJ to Hamcrest across all tests. You
want a PR?
https://github.com/niclash/incubator-plc4x/commit/2080c40c02249db5f5ec0cf0b37b0ea0524de922


Cheers
Niclas



On Sun, Feb 11, 2018 at 5:31 PM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:

> Hi Nicolas,
>
> While I was at it, I press everything to junit 4 and migrated all junit
> Assert statements with assertj assertions. Do you have any opinion to these
> two options? Hamcrest vs. AssertJ?
>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
>
>
> Von: Niclas Hedhman
> Gesendet: Sonntag, 11. Februar, 05:17
> Betreff: Re: Is Junit5 the way to go?
> An: dev@plc4x.apache.org
>
>
> The difference between Junit4 and Junit5 are relatively minor from a
> user's perspective. The real difference is when creating Runners for
> special need systems, such as Spring So, going with JUnit4 for now is not a
> bad thing... But, it seems that there is some legacy that should be
> scrapped, because it actually makes a difference. Avoid the
> Assert.isEqual(), Assert.isTrue() and so on, and only use the Hamcrest
> library for conditions, i.e. assertThat. The benefit is that one can use
> (or make) much more complex tests, which are otherwise ugly to write or
> report back what is expected. assertThat( myInteger, equalTo( 15 ) );
> assertThat( myCollection, hasItem( "Niclas" )); assertThat( myCollection,
> hasItems( "Niclas", "Justin", "Chris" )); Arbitrarily complex matchers can
> be made, and give a reasonable error message when failing. If I can find
> some time in the next couple of days, I will take a look and propose
> changes... On Feb 9, 2018 16:35, "Justin Mclean" wrote: > Hi, > > > thanks
> for finding that ... guess when porting all these thousands of >
> statements, I must have missed one or two "replace: ' == ' with >
> ').isEqualTo('” __ > > Yep I can imaging my brain zoning out when doing
> that :-) > > > Well the main reason was probably, that I wanted to replace
> the > "assertTrue(A==B)" with something like "assertEqual(A, B)" as this
> outputs > the "expected" and the actual "value" and hereby provides a
> little more > information than a simple "was false". So I had the option of
> converting it > to JUint "Assert.assertEquals" or update it to AssertJ's >
> "Assertions.assertThat().isEqualTo()" which I think is a little more >
> readable > > You know that Junit4 also has a assertThat? It’s has a
> slightly different > signature which what threw me when I first looked at
> the changes. > > Thanks, > Justin
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Batch reads with JPA like annotation magic?

[Niclas Hedhman]

native to provide the address directly and give
> up on the flexibility to change the PLC-type / Protocol)
> >
> > Providing would definitely be the less preferred option, but I guess
> we would have to provide a way that is extremely simple for new developers
> to get started. I wouldn’t want to overwhelm them with too much magic in
> the start.
> >
> > The connection could be extended to look a (configurable) property
> file. A property property () would then use this property map in the
> connection to get the real address string for the given property - hereby
> keeping the full portability.
> >
> > Maybe it would be better to have two separate property annotations:
> one for property-based and one for hard-coded address strings.
> >
> > The benefit would be that we then could simplify the integrations to
> frameworks like Edgent as we could create sources and sinks based on the
> POJO type.
> >
> > What do you think?
> >
> > Chris
>
>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Making your first release

[Niclas Hedhman]

I agree with Justin and Juliana and would suggest;  Spend some time to get
the release process automated and smooth, then start a 0.x release train,
with no compatibility guarantees.

On Sun, Aug 26, 2018 at 5:29 PM, Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hi Justin,
>
>
>
> I like your suggestion and also wanted to suggest a first release soon as
> we start to experiment with plc4j a lot in one project and I don’t like to
> reference snapshots with the lot of changes going on (or are planned).
>
> What do the others think of this?
>
>
>
> Julian
>
>
>
> Am 26.08.18, 02:22 schrieb "Justin Mclean" :
>
>
>
> Hi,
>
>
>
> While looking through the incubator reports it’s come to my attention
> that this podling hasn’t made a release yet and has been in the incubator
> for 250+ days.  "Release early and release often” should be the guideline
> to follow. What is holding up this project making it first release?
> Remember a first release doesn’t have to be perfect and each release just
> needs to be better than the last.
>
>
>
> Thanks,
>
> Justin
>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Creating a Kafka Stream connector for PLC4X?

[Niclas Hedhman]

I have some Kafka experience, but not used Kafka Streams. But I think the
most straight forward approach would still be to have a Kafka Producer on
the PLC4X side simply writing to one or more Kafka topics, which is
relatively simple.

You need to 'configure' during the instance creation;

Properties properties = new Properties();
properties.put( ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, cli.kafka );
properties.put( ProducerConfig.LINGER_MS_CONFIG, 1 );
properties.put( ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,
StringSerializer.class.getName() );
properties.put( ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,
StringSerializer.class.getName() );
KafkaProducer<String, String> producer = new KafkaProducer<>( properties );

And once you have the producer, you can push a message to the topic with or
without a key, like this;

producer.send( new ProducerRecord<>( "your-topic", value ) );



I am pretty sure Kafka Streams can take over from the topic queue.


Cheers
Niclas

On Mon, Mar 12, 2018 at 10:38 PM, Christofer Dutz <christofer.d...@c-ware.de
> wrote:

> Hi,
>
> last week I attended the Kafka meetup of a colleague of mine and in his
> talk he introduced Kafka Streams and to me it sounded like a „Clustered
> Edgent“.
>
> My second thought was: would it not be cool to implement such a Kafka
> Stream Connector?
>
> Anyone here got the knowhow to do that? Shouldn’t be that difficult.
>
> Chris
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Creating a Kafka Stream connector for PLC4X?

[Niclas Hedhman]

Sorry, don't know what that is or what it really is, compared to what I
wrote...

On Tue, Mar 13, 2018 at 8:50 PM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:

> Argh ... I wanted to propose a Kafka Connect and not a Kafka Steam adapter
> ( ...
>
> By the way my currently most used setup is actually using PLC4X for PLC
> communication and using Edgents Kafka Connector to publish to Kafka.
>
> A Kafka Connect adapter would allow to directly connect it to Kafka.
>
> Chris
>
>
> Am 13.03.18, 00:02 schrieb "hedh...@gmail.com im Auftrag von Niclas
> Hedhman" <hedh...@gmail.com im Auftrag von nic...@hedhman.org>:
>
> I have some Kafka experience, but not used Kafka Streams. But I think
> the
> most straight forward approach would still be to have a Kafka Producer
> on
> the PLC4X side simply writing to one or more Kafka topics, which is
> relatively simple.
>
> You need to 'configure' during the instance creation;
>
> Properties properties = new Properties();
> properties.put( ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, cli.kafka );
> properties.put( ProducerConfig.LINGER_MS_CONFIG, 1 );
> properties.put( ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,
> StringSerializer.class.getName() );
> properties.put( ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,
> StringSerializer.class.getName() );
> KafkaProducer<String, String> producer = new KafkaProducer<>(
> properties );
>
> And once you have the producer, you can push a message to the topic
> with or
> without a key, like this;
>
> producer.send( new ProducerRecord<>( "your-topic", value ) );
>
>
>
> I am pretty sure Kafka Streams can take over from the topic queue.
>
>
> Cheers
> Niclas
>
> On Mon, Mar 12, 2018 at 10:38 PM, Christofer Dutz <
> christofer.d...@c-ware.de
> > wrote:
>
> > Hi,
> >
> > last week I attended the Kafka meetup of a colleague of mine and in
> his
> > talk he introduced Kafka Streams and to me it sounded like a
> „Clustered
> > Edgent“.
> >
> > My second thought was: would it not be cool to implement such a Kafka
>     > Stream Connector?
> >
> > Anyone here got the knowhow to do that? Shouldn’t be that difficult.
> >
> > Chris
> >
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Creating a Kafka Stream connector for PLC4X?

[Niclas Hedhman]

Kafka Connect is the ability to run a "source" and/or "sink" of streaming
data on the Kafka instance itself. It defines the APIs so people can
include the component (and its configuration) from the command-line. Part
of the Kafka Connect component are Key and Value serialization, and in
Kafka Connect itself, one can apply additional transformations of those
messages.

For PLC4X,

I would imagine that the Source Connector would be configurable with a long
list of data points to be scanned, possibly with some conditions,
priorities and other algorithms to decide what/when to be scanned, at what
interval and which topic is the destination. Of course PLC4X configuration
of protocols would also be needed.

The Sink Connector would read from N topics, and the message would contain
what values to be written to where. It should be enough to do this
on-demand.

I have not figured out how the Source Connector will distributed the work
load in the cluster. One would assume that there is some mechanism in
place, otherwise the ETL (Extract Load Transform) use case would not work,
and ETL seems to be a major case for Kafka Connect.


My conclusion; I think this is a great idea, and that we should aim for
implementing. However, I think it is more important to have more protocols
in place first, so that the PLC4X abstraction is tuned for disparate types
of systems, before attempting to apply another abstraction onto PLC4X API.
And for that, I think we need to increase the number of hands (my own
included) to help out, which requires that the people with the vision and
understanding of the details, need to work more on documentation and less
on exotic integration. I think it is the most urgent issue in this project.


Cheers
Niclas


On Thu, Mar 22, 2018 at 5:58 PM, Niclas Hedhman <nic...@hedhman.org> wrote:

>
> Chris,
> I came across a presentation by coincidence that mentioned "Kafka
> Connect", so I will research this over the weekend and see what it is, and
> how it fits with PLC4X. The presenter only mentioned that a "Kafka Connect"
> component is enable by configuration (in Kafka was implied but not sure)
> rather than programming.
>
> More next week.
> Niclas
>
> On Wed, Mar 21, 2018 at 5:19 PM, Niclas Hedhman <nic...@hedhman.org>
> wrote:
>
>>
>> Alright... So to repeat (and I think you get this much)... Kafka is in
>> principle very simple; Put any byte array into a topic in one end, and
>> readers can get that byte array from that topic somewhere else. Just a
>> simple message queue, at an abstract level. And the Kafka client libraries
>> for doing this is dead easy to use, producer.send() and consumer.poll()
>> respectively.
>>
>> So, I suspect that you are talking about some higher level than base
>> Kafka, possibly masquerading the Kafka transport as some other transport
>> abstraction or a component implementing some protocol, such as MQTT [1],
>> that behind the end point feeds Kafka. But I could be completely off-track
>> and some really clever ideas are at play here, that I don't realize yet.
>> So, yes, please invite people to discuss further.
>>
>> Niclas
>>
>> [1] MQTT feeding Kafka is something I will implement myself in the not
>> too distant future
>>
>> On Wed, Mar 21, 2018 at 4:50 PM, Christofer Dutz <
>> christofer.d...@c-ware.de> wrote:
>>
>>> Hi Niclas,
>>>
>>> have to admit I don't know in detail either ... it was part of a talk a
>>> colleague of mine held at a Kafka meetup in our office. Also I'm not into
>>> Kafka half as deep as you ... from a user point of view it looked as if
>>> such a Kafka Connect adapter would be a good idea. I'm trying to convince
>>> that colleague to contribute ... perhaps he could register here and shed
>>> some light on the topic ... I'll continue the convincing (even if another
>>> codecentric participant wouldn't increase company diversity)
>>>
>>> Chris
>>>
>>>
>>> Am 13.03.18, 16:41 schrieb "hedh...@gmail.com im Auftrag von Niclas
>>> Hedhman" <hedh...@gmail.com im Auftrag von nic...@hedhman.org>:
>>>
>>> Sorry, don't know what that is or what it really is, compared to
>>> what I
>>> wrote...
>>>
>>> On Tue, Mar 13, 2018 at 8:50 PM, Christofer Dutz <
>>> christofer.d...@c-ware.de>
>>> wrote:
>>>
>>> > Argh ... I wanted to propose a Kafka Connect and not a Kafka Steam
>>> adapter
>>> > ( ...
>>> >
>>> > By the way my currently most used setup is actually using PLC4X
>>> for PLC
>>>   

Re: [DRAFT] March Podling Report PLC4X

[Niclas Hedhman]

ir own maturity?
>
> We have a mix of new participants and experienced Apache people involved.
> So far, the new participants have shown great willingness and success in
> adopting the Apache Way.
> However, we still need to continue:
> the on-boarding
> increasing the diversity of the team
> Also, will we need to decide and establish all the processes involved in
> releasing software at Apache
>
>
>
>
> Am 31.03.18, 05:25 schrieb "hedh...@gmail.com im Auftrag von Niclas
> Hedhman" <hedh...@gmail.com im Auftrag von nic...@hedhman.org>:
>
> IMHO, it is a bit long and details more than the Board needs to know.
>
> In general, there is a tendency to not want to see company names
> splurted
> around, and perhaps all the PLC4X-specific terms could be shortened
> into
> generic technical language, and shortened.
>
> Cheers
> Niclas
>
> On Sat, Mar 31, 2018 at 3:09 AM, Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > Ok … a little earlier than expected … please comment :-)
> >
> > Chris
> >
> > 
> > ---
> >
> > Apache PLC4X (incubating)
> >
> >
> > PLC4X is a set of libraries for communicating with industrial
> programmable
> > logic controllers (PLCs) using a variety of protocols but with a
> shared API.
> >
> >
> > Most important issues to address while moving towards graduation:
> >
> > Building the community: The PPMC and committer group has a large
> > percentage of codecentric employees, we have been recruiting people
> from
> > other companies, but will have to continue these efforts for
> establishing a
> > healthy Apache community.
> > Onboarding of new committers: With PLC4X several people on the team
> are
> > not very familiar with the Apache Way. We have started and will
> continue
> > our efforts on this onboarding.
> > Make our first release
> >
> > Any Issues the Incubator PMC or ASF Board might wish/need to be
> aware of:
> >
> > In contrast to previous reports some of the concerns regarding
> > availability and usability of specifications have been resolved.
> Especially
> > for using the Modbus and the OPC-UA specifications Christofer was
> able to
> > get official permissions from the corresponding foundations to use
> the
> > specifications. These permission Emails have been filed in the
> private list
> > for documentation.
> >
> > One of the external foundations (Profinet) doesn’t have a free
> membership.
> > In general, the CEO of the European branch of the Profinet
> Foundation has
> > signaled that it should be possible for the ASF to become a member
> and have
> > an outside company pay the membership fees, but we have to discuss
> the
> > details (With them as well as the ASF).
> >
> > How has the community developed since the last report?
> >
> > Christofer has invested most of his time in March spreading the word
> about
> > PLC4X.
> > A first POC has been created for the company “Kampf Schneid- und
> > Wickeltechnik GmbH & Co. KG” which is currently going into production
> > An article about Apache Edgent and Apache PLC4X has been published
> as a
> > cover-story in the German JavaSPEKTRUM magazines Industrial IoT
> special
> > edition (https://www.sigs-datacom.de/digital/javaspektrum/). One
> PLC4X
> > talk has been accepted to the Apache EU Roadshow 2018 in Berlin and
> one
> > will be at the Silpion Techcamp in Hamburg (
> https://techcamp.hamburg/) in
> > the first April week.
> >
> > The dev-list subscriptions has gone up by one from February, we are
> hoping
> > to increase the number in the next few weeks (However quite some
> emails
> > come in from un-registered users that have to pass moderation).
> >
> > We now have a Twitter account: https://twitter.com/ApachePlc4x as
> another
> > channel of communicating interesting PLC4X facts.
> >
> > How has the project developed since the last report?
> >
> > Sebastian worked hard on replacing the scripted Jenkins pipeline
> > definition to a declarative version.
> > After receiving the permission to use and implement the Modbus
> protocol,
> > the Driver skeletons

Re: [DRAFT] March Podling Report PLC4X

[Niclas Hedhman]

I don't think you need Mentor to do it. I have added it...

I see Justin being Mentor, so _should_ be easy to get a sign-off.

On Wed, Apr 4, 2018 at 1:23 PM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:

> Hi Niclas,
>
> I'll keep that in mind for the next report, could one of the mentors
> please add the report for me (I think this has to be a mentor)
>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
> 
> From: hedh...@gmail.com <hedh...@gmail.com> on behalf of Niclas Hedhman <
> nic...@hedhman.org>
> Sent: Wednesday, April 4, 2018 2:09:07 AM
> To: dev@plc4x.apache.org
> Subject: Re: [DRAFT] March Podling Report PLC4X
>
> I think it is still a lot more detail than needed, but I don't think you
> need to spend more time on making it smaller this time around. Maybe the
> Incubator is more fuzzy than the Board, since "How has the project
> developed since the last report?" invites a lot more technical detail than
> what the Board care about, which is "community health", "are people getting
> along", "are releases made", "any new committers and PMC members", "any
> trademark issues with 3rd parties", "publicity and conferences" and stuff
> like that.
>
> If you look at TLP reports, e.g.
> https://www.apache.org/foundation/records/minutes/
> 2018/board_minutes_2018_02_21.txt,
> you should notice that mostly non-technical stuff gets to the board.
>
>
> Cheers
> NIclas
>
> On Tue, Apr 3, 2018 at 3:22 PM, Christofer Dutz <christofer.d...@c-ware.de
> >
> wrote:
>
> > Ok ... so here a little less verbose version ... this ok?
> >
> > Chris
> >
> > 
> > ---
> >
> > Apache PLC4X (incubating)
> >
> >
> > PLC4X is a set of libraries for communicating with industrial
> programmable
> > logic controllers (PLCs) using a variety of protocols but with a shared
> API.
> >
> >
> > Most important issues to address while moving towards graduation:
> >
> > Building the community: The PPMC and committer group has a large
> > percentage of codecentric employees, we have been recruiting people from
> > other companies, but will have to continue these efforts for
> establishing a
> > healthy Apache community.
> > Onboarding of new committers: With PLC4X several people on the team are
> > not very familiar with the Apache Way. We have started and will continue
> > our efforts on this onboarding.
> > Make our first release
> >
> > Any Issues the Incubator PMC or ASF Board might wish/need to be aware of:
> >
> > In contrast to previous reports some of the concerns regarding
> > availability and usability of specifications have been resolved.
> Especially
> > for using the Modbus and the OPC-UA specifications Christofer was able to
> > get official permissions from the corresponding foundations to use the
> > specifications. These permission Emails have been filed in the private
> list
> > for documentation.
> >
> > One of the external foundations (Profinet) doesn’t have a free
> membership.
> > In general, the CEO of the European branch of the Profinet Foundation has
> > signaled that it should be possible for the ASF to become a member and
> have
> > an outside company pay the membership fees, but we have to discuss the
> > details (With them as well as the ASF).
> >
> > How has the community developed since the last report?
> >
> > Christofer has invested most of his time in March spreading the word
> about
> > PLC4X.
> > A first POC has been created for a company which is currently going into
> > production
> > An article about Apache Edgent and Apache PLC4X has been published as a
> > cover-story in the German JavaSPEKTRUM magazines Industrial IoT special
> > edition (https://www.sigs-datacom.de/digital/javaspektrum/). One PLC4X
> > talk has been accepted to the Apache EU Roadshow 2018 in Berlin and one
> > will be at the Silpion Techcamp in Hamburg (https://techcamp.hamburg/)
> in
> > the first April week.
> >
> > The dev-list subscriptions has gone up by one from February, we are
> hoping
> > to increase the number in the next few weeks (However quite some emails
> > come in from un-registered users that have to pass moderation).
> >
> > We now have a Twitter account: https://twitter.com/ApachePlc4x as
> another
> > channel of communicating interesting PLC4X facts.
> >
> >

Re: Creating a Kafka Stream connector for PLC4X?

[Niclas Hedhman]

Chris,
I came across a presentation by coincidence that mentioned "Kafka Connect",
so I will research this over the weekend and see what it is, and how it
fits with PLC4X. The presenter only mentioned that a "Kafka Connect"
component is enable by configuration (in Kafka was implied but not sure)
rather than programming.

More next week.
Niclas

On Wed, Mar 21, 2018 at 5:19 PM, Niclas Hedhman <nic...@hedhman.org> wrote:

>
> Alright... So to repeat (and I think you get this much)... Kafka is in
> principle very simple; Put any byte array into a topic in one end, and
> readers can get that byte array from that topic somewhere else. Just a
> simple message queue, at an abstract level. And the Kafka client libraries
> for doing this is dead easy to use, producer.send() and consumer.poll()
> respectively.
>
> So, I suspect that you are talking about some higher level than base
> Kafka, possibly masquerading the Kafka transport as some other transport
> abstraction or a component implementing some protocol, such as MQTT [1],
> that behind the end point feeds Kafka. But I could be completely off-track
> and some really clever ideas are at play here, that I don't realize yet.
> So, yes, please invite people to discuss further.
>
> Niclas
>
> [1] MQTT feeding Kafka is something I will implement myself in the not too
> distant future
>
> On Wed, Mar 21, 2018 at 4:50 PM, Christofer Dutz <
> christofer.d...@c-ware.de> wrote:
>
>> Hi Niclas,
>>
>> have to admit I don't know in detail either ... it was part of a talk a
>> colleague of mine held at a Kafka meetup in our office. Also I'm not into
>> Kafka half as deep as you ... from a user point of view it looked as if
>> such a Kafka Connect adapter would be a good idea. I'm trying to convince
>> that colleague to contribute ... perhaps he could register here and shed
>> some light on the topic ... I'll continue the convincing (even if another
>> codecentric participant wouldn't increase company diversity)
>>
>> Chris
>>
>>
>> Am 13.03.18, 16:41 schrieb "hedh...@gmail.com im Auftrag von Niclas
>> Hedhman" <hedh...@gmail.com im Auftrag von nic...@hedhman.org>:
>>
>> Sorry, don't know what that is or what it really is, compared to what
>> I
>> wrote...
>>
>> On Tue, Mar 13, 2018 at 8:50 PM, Christofer Dutz <
>> christofer.d...@c-ware.de>
>> wrote:
>>
>> > Argh ... I wanted to propose a Kafka Connect and not a Kafka Steam
>> adapter
>> > ( ...
>> >
>> > By the way my currently most used setup is actually using PLC4X for
>> PLC
>> > communication and using Edgents Kafka Connector to publish to Kafka.
>> >
>> > A Kafka Connect adapter would allow to directly connect it to Kafka.
>> >
>> > Chris
>> >
>> >
>> > Am 13.03.18, 00:02 schrieb "hedh...@gmail.com im Auftrag von Niclas
>> > Hedhman" <hedh...@gmail.com im Auftrag von nic...@hedhman.org>:
>> >
>> > I have some Kafka experience, but not used Kafka Streams. But I
>> think
>> > the
>> > most straight forward approach would still be to have a Kafka
>> Producer
>> > on
>> > the PLC4X side simply writing to one or more Kafka topics,
>> which is
>> > relatively simple.
>> >
>> > You need to 'configure' during the instance creation;
>> >
>> > Properties properties = new Properties();
>> > properties.put( ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,
>> cli.kafka );
>> > properties.put( ProducerConfig.LINGER_MS_CONFIG, 1 );
>> > properties.put( ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,
>> > StringSerializer.class.getName() );
>> > properties.put( ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,
>> > StringSerializer.class.getName() );
>> > KafkaProducer<String, String> producer = new KafkaProducer<>(
>> > properties );
>> >
>> > And once you have the producer, you can push a message to the
>> topic
>> > with or
>> > without a key, like this;
>> >
>> > producer.send( new ProducerRecord<>( "your-topic", value ) );
>> >
>> >
>> >
>> > I am pretty sure Kafka Streams can take over from the topic
>

Re: Creating a Kafka Stream connector for PLC4X?

[Niclas Hedhman]

Alright... So to repeat (and I think you get this much)... Kafka is in
principle very simple; Put any byte array into a topic in one end, and
readers can get that byte array from that topic somewhere else. Just a
simple message queue, at an abstract level. And the Kafka client libraries
for doing this is dead easy to use, producer.send() and consumer.poll()
respectively.

So, I suspect that you are talking about some higher level than base Kafka,
possibly masquerading the Kafka transport as some other transport
abstraction or a component implementing some protocol, such as MQTT [1],
that behind the end point feeds Kafka. But I could be completely off-track
and some really clever ideas are at play here, that I don't realize yet.
So, yes, please invite people to discuss further.

Niclas

[1] MQTT feeding Kafka is something I will implement myself in the not too
distant future

On Wed, Mar 21, 2018 at 4:50 PM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:

> Hi Niclas,
>
> have to admit I don't know in detail either ... it was part of a talk a
> colleague of mine held at a Kafka meetup in our office. Also I'm not into
> Kafka half as deep as you ... from a user point of view it looked as if
> such a Kafka Connect adapter would be a good idea. I'm trying to convince
> that colleague to contribute ... perhaps he could register here and shed
> some light on the topic ... I'll continue the convincing (even if another
> codecentric participant wouldn't increase company diversity)
>
> Chris
>
>
> Am 13.03.18, 16:41 schrieb "hedh...@gmail.com im Auftrag von Niclas
> Hedhman" <hedh...@gmail.com im Auftrag von nic...@hedhman.org>:
>
> Sorry, don't know what that is or what it really is, compared to what I
> wrote...
>
> On Tue, Mar 13, 2018 at 8:50 PM, Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > Argh ... I wanted to propose a Kafka Connect and not a Kafka Steam
> adapter
> > ( ...
> >
> > By the way my currently most used setup is actually using PLC4X for
> PLC
> > communication and using Edgents Kafka Connector to publish to Kafka.
> >
> > A Kafka Connect adapter would allow to directly connect it to Kafka.
> >
> > Chris
> >
> >
> > Am 13.03.18, 00:02 schrieb "hedh...@gmail.com im Auftrag von Niclas
> > Hedhman" <hedh...@gmail.com im Auftrag von nic...@hedhman.org>:
> >
> > I have some Kafka experience, but not used Kafka Streams. But I
> think
> > the
> > most straight forward approach would still be to have a Kafka
> Producer
> > on
> > the PLC4X side simply writing to one or more Kafka topics, which
> is
> > relatively simple.
> >
> > You need to 'configure' during the instance creation;
> >
> > Properties properties = new Properties();
> > properties.put( ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,
> cli.kafka );
> > properties.put( ProducerConfig.LINGER_MS_CONFIG, 1 );
> > properties.put( ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,
> > StringSerializer.class.getName() );
> > properties.put( ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,
> > StringSerializer.class.getName() );
> > KafkaProducer<String, String> producer = new KafkaProducer<>(
> > properties );
> >
> > And once you have the producer, you can push a message to the
> topic
> > with or
> > without a key, like this;
> >
> > producer.send( new ProducerRecord<>( "your-topic", value ) );
> >
> >
> >
> > I am pretty sure Kafka Streams can take over from the topic
> queue.
> >
> >
> > Cheers
> > Niclas
> >
> > On Mon, Mar 12, 2018 at 10:38 PM, Christofer Dutz <
> > christofer.d...@c-ware.de
> > > wrote:
> >
> > > Hi,
> > >
> > > last week I attended the Kafka meetup of a colleague of mine
> and in
> > his
> > > talk he introduced Kafka Streams and to me it sounded like a
> > „Clustered
> > > Edgent“.
> > >
> > > My second thought was: would it not be cool to implement such
> a Kafka
> > > Stream Connector?
> > >
> > > Anyone here got the knowhow to do that? Shouldn’t be that
> difficult.
> > >
> > > Chris
> > >
> >
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org - New Energy for Java
> >
> >
> >
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Batch reads with JPA like annotation magic?

[Niclas Hedhman]

Polygene is highly opinionated, for better and worse. Minimally, Polygene
requires to start a runtime, and that everything needed is declared
explicitly upfront at boot time. The minimal start code is something like;


public static void main( String[] args )
throws Exception
{
app = new SingletonAssembler( module -> {
module.transients( Boiler.class, Ahu.class, Fan.class )
  .withMixins( Plc4xBackingPropertyMixin.class );

module.services( Plc4xPollService.class )
  .withMixins( Plc4xModbusDriver.class );
:
:
} );
}


If one wants to implement additional behavior in the Boiler class, then you
create Mixin classes. Let's say we want to capture the temperature once an
hour.

@Mixins(HistoryMixin.class)
interface Boiler
{
@Plc4x( url="s7://..", period=6 )
Property temperature();

List temperatureHistory();
}

public abstract class HistoryMixin
implements Boiler, Scheduled
{
int maxHours = 24;

LinkedBlockingDeque history = new LinkedBlockingDeque<>();

@Override
public void tick()
{
Double value = temperature().get();
history.addLast(value);
while( history.size() > maxHours )
{
history.removeFirst();
}
}

@Override
public List temperatureHistory()
{
return new ArrayList<>( history );
}
}


Above, let's say that "Scheduled" is a service to allow something to get a
tick() upon some period/interval. What I want to draw attention to is that
the HistoryMixin is implementing only the method(s) it need to, and that
the Boiler interface can declare such permanent functionality as an
annotation, instead of as a start-up declaration in the assembly. The fact
that the Mixin is abstract is handled by the runtime and it will compose
all these individual (so called) fragments into a single object (we call it
a Composite) when you instantiate it from the builder.

It is a whole new different way of writing software. Some people love it,
and others have a hard time understanding how it can possibly work. Just
scratching the surface, and please read
https://hedhman.wordpress.com/2017/05/10/introducing-apache-polygene/ for a
larger introduction to the subject.


If you don't want to write the entire project in Polygene "style", you need
to either use the Spring library bridge (possibly need upgrade that one a
bit), where each Service in Polygene will show up as a Spring bean, or
leverage various points of external hooks for Polygene, such
importedServices.


Don't want to bore you too much.


My actual main point was that your suggestion/idea can quickly become quite
a large undertaking and detract from the primary focus that (I think) PLC4X
should have. And bringing up Polygene was more to show that what you
suggest can be done very easily already in Polygene, and all that work
wouldn't be needed.


Cheers
Niclas


On Tue, Mar 6, 2018 at 4:35 AM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:

> Hi Niclas,
>
> after recovering from that nasty Flu, that is plaguing Germany at the
> moment, I am working on catching up on what I missed.
> I tried to follow, but some things I felt to worn out to work my head
> around.
>
> Could you elaborate a little on Ploygene? How would this allow extending
> our requests with additional magic? Does this work in a simple way: No need
> to configure plugins, code generation or learn some complex API? I would
> like to keep PLC4X as simple as possible, but as extendable as possible.
>
> So I'm always open for new ideas (
>
> Chris
>
>
>
> Am 20.02.18, 03:32 schrieb "hedh...@gmail.com im Auftrag von Niclas
> Hedhman" <hedh...@gmail.com im Auftrag von nic...@hedhman.org>:
>
> Being the Overlord of Magic that can be done in Java, I have some
> comments
> to make on this idea.
>
> 1. In principle what you suggest can already be done quite easily in
> Apache
> Polygene, by creating a "generic mixin" that overrides the generic
> PropertyMixin. Polygene is probably way more powerful than anything you
> could dream up here. Although Polygene has a strong JSON serialization
> and
> persistence "story", both fully pluggable, it does not use the Glasgow
> spec, a.k.a JavaBeans, a.k.a "getter/setter naming convention", which
> has
> been plaguing the Java community for 2 decades now.
> If I created a Plc4xBackingPropertyMixin, which I think would only
> take a
> few hours, maybe a couple of days, depending on how advance we want
> it, you
> would end up with;
>
>
>
>
> *public interface Boiler{*
>
> *@Plc4x( url="s7://..", period=5000, priority=low )*
>
>
> *Property running();*
&

Re: [WARNING] Please don't commit anything to `master` effective immediately

[Niclas Hedhman]

At Polygene we referred to this article;
http://nvie.com/posts/a-successful-git-branching-model/ and borrowed the
nice graphics to our page. The one on
http://plc4x.apache.org/developers/contributing.html is impossible for me
to see, probably because of colors and not enough contrast, but also too
small.


Cheers
Niclas

On Sun, Nov 18, 2018 at 4:20 PM Christofer Dutz 
wrote:

> Ok …
>
> So it seems the branch and version updates worked nicely.
> I just pushed some documentation update and this should be available in
> the website soon.
> I added some documentation to the Contributing page (started filling this
> with content: http://plc4x.apache.org/developers/contributing.html)
> And I added some documentation to the release documentation:
> http://plc4x.apache.org/developers/release.html
> But as I mentioned … could be a few minutes till the website is updated.
>
> Chris
>
> Von: Otto Fowler 
> Datum: Mittwoch, 14. November 2018 um 15:55
> An: "dev@plc4x.apache.org" , Christofer Dutz <
> christofer.d...@c-ware.de>
> Betreff: Re: [WARNING] Please don't commit anything to `master` effective
> immediately
>
> Have you written up something in confluence and in the root of the source
> dir that documents the branching strategy?
>
>
>
> On November 14, 2018 at 07:59:11, Christofer Dutz (
> christofer.d...@c-ware.de<mailto:christofer.d...@c-ware.de>) wrote:
> Hi all,
>
> I just thought I‘d post this as a reminder. I am currently in the process
> of creating the new `develop` branch and currently adjusting the build
> scripts do what they did for master for develop now.
>
> From now on, the only commits done to master should be the release manager
> merging the latest release version back to master after a successful
> release.
>
> Commits to master will cause a lot of problems from now on.
>
> Chris
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Exciting news for Apache comimtters

[Niclas Hedhman]

To clarify; The offer from Jetbrains refers to the "paid for" editions and
to be used for non-commercial, open source development ONLY. For other
uses, please use the "community editions" (where available) or subscribe to
the tool chain (which nowadays is a lot cheaper than it used to be).

To apply, go to https://www.jetbrains.com/community/opensource/ and to the
bottom of the page (Supporting the Apache Software Foundation)

Cheers
Niclas

On Fri, May 31, 2019 at 3:09 PM Christofer Dutz 
wrote:

> Hi all,
>
> As we are now supporting more and more languages, the question of IDEs for
> these Languages come up.
> I don’t know if you followed the latest announcements, but Jetbrains seem
> to have extended their offer to the ASF.
> In the past Apache Committers could request a free IntelliJ license from
> them. This seems to have been extended
> To the full toolbox. So now you could also use CLion for C++ and the
> Python IDE free of charge.
>
> If you’re interested, give me a ping and I’ll try to find out what you
> have to do to get that offer.
>
> Chris
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [DriverGen] Major refactoring and great improvements

[Niclas Hedhman]

re now Language-(output)-modules which also are
> discovered similar to how we discover drivers in the classpath
>   *   The input modules generally provide only the spec
>   *   The output modules contain everything needed to produce
> output for a given language
>   *   In order to allow experimentation of the output variants the
> output modules contain everything needed to generate the output
>   *   My implementation of a language-template-java uses
> freemarker to generate output, but others could simply use other techniques
>
> So far I have a pojo template that will generate the POJO classes
> for the types in the spec.
> Right now I’m working on the little tool that will tell the output
> which Java type it should use for which spec type …
> but as soon as that’s done I’m looking forward to implementing the
> IO components.
>
> All of this is happening in the “feature/code-gen” branch … and
> all my code-generation related code is in sandbox/code-generation
>
> So far the update …
>
> Chris
>
>
>
>
>

-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

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

[Niclas Hedhman]

Welcome, Björn, to Plc4x and (IIUIC) the Apache Software Foundation itself.

Niclas

On Mon, May 13, 2019 at 11:48 PM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hi all,
>
> I am pleased to announce that Björn Höper has accepted an invitation to
> join the PLC4X PMC.
> Although Björn is not so long with the Project yet, he has shown a lot of
> energy and willingness to bring the project forward.
> And he also quickly became a very well-integrated part of our community.
>
> Please join me in congratulating Björn, I’m very happy to have you on
> board!
>
> Julian (on behalf of the PLC4X PMC)
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [generation] Another approach to generated drivers

[Niclas Hedhman]

Outsider looking in; Many language runtimes allows embedding of other
languages' runtimes within. So why not pick a languages that is reasonably
easy to integrate into other languages, and then write the drivers in a
fully fledged programming language, rather than the DFDL abstraction or
creating a new DSL with a whole slew of consequences later on.

Languages that might be suitable; JavaScript, Lua, Forth, microPython or
even C...

Niclas

On Mon, Apr 29, 2019 at 2:20 PM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hi all,
>
> just wanted to sum up some talks and discussions we had off-list about the
> whole topic of driver generation / providing drivers in other languages.
> Currently, there are the following two approaches going on:
>
> Driver Generation based on DFDL by Chris:
> Chris already shared his branch and is working on the generation of
> drivers based on the specification of the messages and a state machine.
> This should then generate Code based on Freemarker Templates.
>
> Proxy Drivers by me, Chris and also others:
> We have a thrift based server / client spec.
> A simple Java Server is implemented as Interop Server and we work on
> providing client in other languages.
> This is a separate feature (as Proxy) but in a mode, where the Client
> itself starts the server in the background, this is an intermediate
> solution to already provide other language bindings (although at a cost).
> All work is done in the PLC4X-111 branch and I hope that we will be able
> to Merge that soon (Chris spend a lot of effort to include all the new
> stuff in our build).
>
> And there is a new thing coming currently which is mostly Driven by
> Matthias and myself regarding the driver code generation.
> We went over Chris example code (and the xmls) and our heads nearly
> exploded as it is so abstract.
> And as Matthias does a lot with model based code generation we had a long
> discussion about using a model based approach (probably with a DSL).
> So we currently try to investigate that a bit but also with a focus on
> research. In fact, we have the potential that we can engage some students
> from his institute to participate at the work.
> In fact, we even started a private Repo where we prepare a Paper to
> discuss the matter.
> As this would be our first “PLC4X Paper” everybody is invited to join us
> and should simply ping me (with github credentials), to get repo access.
> If we make it through we will will of course list everybody who
> contributed as author.
>
> To make it clear, this work, the DSL based driver generation tries to
> achieve the same as Chris approach based on DFDL just through another way.
> And right now I’m unable to say which one is better, could be better and
> where are the drawbacks and advantages. So we want to investigate that to
> have a basis for a discussion and decision. In fact, both approaches should
> be equally powerful, so one could be able to translate one to the other and
> vice versa, in theory.
> I consider it highly important to have a good and easy way to develop and
> maintain drivers as this is the crucial thing for the future of PLC4X.
>
> So please feel free to comment or discuss, if you feel like : )
>
> Julian
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [DISCUSS] Rename CRUNCH to something different

[Niclas Hedhman]

peanut gallery; I would recommend a descriptive name, in format of "PLC4X
Abc", rather than a stand-alone name. Somewhere in the future, you may have
a dozen of these and one wouldn't know where to start looking.

Cheers
Niclas

On Mon, Sep 9, 2019 at 4:51 AM Julian Feinauer 
wrote:

> Hi all,
>
> I just discussed (off-list) with Justin the next steps needed.
> They are
>
> * fill out software grant (pm)
> * Start IP clearance vote on incubator list (JF)
> * Gather ICLA from all contributors of CRUNCH
>
> Parallel I’d like to start a discuss on how we should call it as PLC4X
> subproject.
>
> Any ideas or suggestions?
>
> Julian
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Usage of Netty - JSerialcom-Bridge

[Niclas Hedhman]

The so called Category A licenses are allowed to be included as a
dependency AND/OR in source form of Apache projects, but we must respect
the language of those licenses. MIT is a relatively aligned license, which
in essence differs from ALv2 in the patent clause (IIRC, however IANAL).

There is also a social aspect to expropriating external codebases; If the
authors explicitly wish for the codebase to be placed into PLC4X, then
AFAIU an ICLA is nice, but not required. If the original authors don't want
the fork, ASF has historically followed that even if it legally could fork
it. IF all the authors are onboard for the codebase to come to ASF, then
try to do a "Software Grant" and take it through the Incubator's process of
codebase donations, and TRY to get the authors to change the license to
ALv2.

>From experience, if they have a few hours of time available, most are happy
to do it. If they are strapped on time, someone can have a quick talk with
them, and do the actual work on their behalf. That is also often
appreciated.

// Niclas

On Wed, Aug 7, 2019 at 11:16 PM Christofer Dutz 
wrote:

> Hi Julian,
>
> It seems the files am have apache headers, but the pom says mit license.
> Perhaps Justin can help us with what's allowed and what's not.
>
> It would be cool to have it in a location we can update and release it on
> our own. Cause even if the maintainer is accepting PRs, we don't know how
> often he releases.
>
> We could put it alongside the raw socket stuff.
>
> It's only one contributor, so he could donate everything without too much
> effort.
>
> Chris
>
> Holen Sie sich Outlook für Android<https://aka.ms/ghei36>
>
> 
> From: Julian Feinauer 
> Sent: Wednesday, August 7, 2019 3:13:33 PM
> To: dev@plc4x.apache.org 
> Subject: Usage of Netty - JSerialcom-Bridge
>
> Hi all,
>
> as we use in our DF1 Code (and also fort he Modbus Code, I think) the
> library: https://github.com/Ziver/Netty-Transport-jSerialComm which is
> under netty license.
> But it quite outdated and only “maintained” by one guy.
> I contacted him asking if he accepts PRs and also suggested, that we
> probably move / replicate the code in our code in a tools module (or
> integrate it in the Serial-Netty Stuff somewhere).
>
> What do you think?
> The best way, if he agrees, would be to have him sign an ICLA and we could
> simply take the code as is and refactor it perhaps a bit and adapt it to
> newer versions.
>
> Otherwise, I think it will be hard to use this lib and we would need to
> come up with an alternative.
>
> Julian
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Simpifying the profiles?

[Niclas Hedhman]

Has multiple repositories been considered? A project may request as many as
they want/need...

On Tue, Oct 15, 2019 at 4:07 PM Christofer Dutz 
wrote:

> Hi all,
>
> as I have heard complaints that the current way we handle profiles is too
> complicated, I would like to discuss alternatives with you all.
>
> Currently if you just run “./mvnw install” it will only build the
> protocols. This is probably not what the user wants.
>
> Right now we didn’t want to overwhelm someone just wanting to build Java,
> which will probably be the most common case to configure all the
> prerequisites for C++ and C#.
> So we introduced the “with-xyz” profiles. Now you only need to provide the
> tooling needed for the parts you want to build, which reduces the entry
> barrier (in my opinion)
> On the other hand we didn’t want people working on C++ and C# to have to
> run the Java test-suite before committing.
>
> But it seems that having to enable profiles already raises the barrier too
> high and people get confused instead of relieved. This was not planned and
> therefore we need to react.
>
> Yesterday I did a little brainstorming to what options I could think of …
> perhaps you have others or you have feedback to them. Your opinion would be
> highly appreciated:
>
>
>   1.  If no “with-xyz” profile is activated, a message is output which
> tells the user it should enable a profile (This should be very simple to
> implement)
>   2.  We make the “with-java” profile “enabled by default” (if no profile
> is enabled, this one is automatically enabled, making the naïve developer
> just trying “mvn package” scceed)
>   3.  We remove all profiles and ask people to go into “plc4j” to build
> the java part, into “sandbox” if they want to build the sandbox (We could
> add the suggestion to use “-am” to the build which will “also build” any
> outside modules needed by the current selection)
>
> Here my thoughts to the approaches:
>
>   1.  This shouldn’t have any negative side-effects (I personally would
> prefer this … we could even try make it “interactive” where the user can
> select the options he wants enabled and it generates a “command line” the
> user can use to build what he wants)
>   2.  The problem with enabled by default profiles is that they get
> disabled if a profile is explicitly selected. So if a user builds “mvn
> package” it would build java. But if he runs “mvn -Pwith-cpp package” it
> would only build C++ and no longer java … if you want java and C++ you
> would need to do “mvn -Pwith-java,with-cpp package” (Not that intuitive, I
> think … but an option)
>   3.  This will cause the “mvn package” type of persons to be flooded with
> a list of things to install and the build will take pretty long. As they
> will probably always have some prerequisite not installed and the build
> will not start with an explanation on why, we could use this opportunity to
> also point out that you don’t have to install all prerequisites if you only
> want to build part of the project. In this case too we would have to split
> the prerequisite check to the individual submodules or people will be left
> without guidance when building only “plc4cpp” for example … so we would
> have the big check in the root and multiple partial checks in the
> sub-directories.
>
>
> I personally would prefer the version 1), but let’s discuss this.
>
> Perhaps you have other ideas … I would be happy to hear and discuss them.
>
> Chris
>
>
>
>

-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [REFACTORING] Self-Describing Driver Parameters

[Niclas Hedhman]

If I am not mistaken, the annotations in Camel are used in runtime as well,
and the additional description is a "small extra", compared to no
annotations with at the start.

That said; annotations were added with multiple purposes, and one explicit
such purpose was for documentation purposes, I think it is a positive idea,
but it could be a major undertaking in comparison.

Cheers
Niclas

On Wed, Oct 23, 2019, 21:06 Julian Feinauer 
wrote:

> Hi,
>
> as we plan to do a refactoring for the next release (0.6) I wanted to
> bring up an “older” Issue PLC4X-138.
> My suggestion is to do it somehow similar to what Apache Camel or Apache
> Maven do.
> Basically, they use Annotations in their Configuration POJOs to generate
> Documentation about all available configuration options, default values,
> etc.
>
> For Example for Camel, see
> https://github.com/Talend/apache-camel/blob/master/camel-core/src/main/java/org/apache/camel/component/timer/TimerEndpoint.java
>
> A short Snippet:
> ```
> @UriEndpoint(firstVersion = "1.0.0", scheme = "timer", title = "Timer",
> syntax = "timer:timerName", consumerOnly = true, consumerClass =
> TimerConsumer.class, label = "core,scheduling")
>
> public class TimerEndpoint extends DefaultEndpoint implements
> MultipleConsumersSupport {
>
> @UriPath @Metadata(required = "true")
>
> private String timerName;
>
> @UriParam(defaultValue = "1000", description = "If greater than 0,
> generate periodic events every period milliseconds."
>
> + " You can also specify time values using units, such as 60s (60
> seconds), 5m30s (5 minutes and 30 seconds), and 1h (1 hour).")
>
> private long period = 1000;
>
> @UriParam(defaultValue = "1000", description = "Miliseconds before first
> event is triggered."
>
> + " You can also specify time values using units, such as 60s (60
> seconds), 5m30s (5 minutes and 30 seconds), and 1h (1 hour).")
>
> private long delay = 1000;
>
> @UriParam(defaultValue = "0")
>
> private long repeatCount;
>
> @UriParam
>
> private boolean fixedRate;
>
> @UriParam(defaultValue = "true", label = "advanced")
>
> private boolean daemon = true;
>
>
> ```
>
> So this would give us the possibility to generate custom UIs for all
> drivers and nice visualization (e.g. on the Homepage).
> See e.g. the (generated) Camel Homepage (for above Timer):
> https://camel.apache.org/components/latest/timer-component.html
>
> What are your thoughts?
>
> Julian
>

Re: PLC4X and OSGi

[Niclas Hedhman]

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

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

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

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

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

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


Hope that Helps
Niclas


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

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

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

Re: [DISCUSS] Guideline for "professional support" Mentioning on Homepage

[Niclas Hedhman]

My two cents; you could recommend that companies that has commercial
support to use a unique name on their offering/landing page that gets
picked up by search engines and let the general public know what that word
is...

When I personally am looking for this for project Foo, then "foo -site:
apache.org" is the starting point. And that could be smoother.


Cheers

On Mon, Jan 27, 2020, 16:28 Julian Feinauer 
wrote:

> Hes, but as I understand it you are already doing that, so this should
> yield result soon : )
>
> Am 27.01.20, 09:24 schrieb "Christofer Dutz" :
>
> Yeah ...
>
> not sure this is not too much ... we should in general have this
> checked if such a page would be in line with the ASF bylaws.
>
> Chris
>
> Am 27.01.20, 08:21 schrieb "Julian Feinauer" <
> j.feina...@pragmaticminds.de>:
>
> Hi,
>
> I think we should list the companies with a short outline like,
> e.g. postgres does it here:
> https://www.postgresql.org/support/professional_support/europe/
>
> For codecentric one could write (I see no problem):
> PLC4X was initially started as an internal project at codecentric
> and open soure to the ASF. Christofer Dutz, the initiatior of PLC4X helps
> in his daytime job clients with the implementation of Drivers and blab la
> blab la
>
> And for us we could / would write something similar:
> The beautiful, wise, intelligent and charismatic Julian and his
> blalbalblablalbal
>
> I think you get the point? : )
>
> Julian
>
> Am 27.01.20, 08:17 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
>
> Hi Julian,
>
> I think having links to commercial support offerings is a
> pretty important thing for us to have.
> If we have to allow anyone be listed there (even if they don't
> contribute to the project) well that will be "the toad we have to swallow"
> (Don't know how to translate this German saying to English).
>
> Right now I see the industries worries of not being able to
> get commercial support as being one of the most problematic things ... that
> was why I put the "commercial support" thing on our landing page.
>
> Would it be possible to mark companies who employ committers
> of the project (but not which ones) with a "*" and an explanation?
>
> Chris
>
>
>
> Am 27.01.20, 08:10 schrieb "Julian Feinauer" <
> j.feina...@pragmaticminds.de>:
>
> Hey,
>
> @Christofer Dutz you can also a general discuss about
> whether or not we should do that.
> I am mostly concerned with clear rules, if we do it.
> But, in the end, its not granted, lets discuss it and if
> we cant get an agreement decide it.
>
> Julian
>
> Am 27.01.20, 06:55 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
>
> Hi Justin,
>
> So in general it would be OK to have a list of links
> to companies plc4x support pages?
>
> I don't care about seeing the ties between persons and
> companies.
>
> Just not happy to have any company listed.
>
> Chris
> 
> Von: Justin Mclean 
> Gesendet: Montag, 27. Januar 2020 01:45
> An: dev@plc4x.apache.org 
> Betreff: Re: [DISCUSS] Guideline for "professional
> support" Mentioning on Homepage
>
> Hi,
>
> > as Lukas just opened up a discussion about
> mentioning commercial support on the (new) PLC4X Homepage.
> > One Example where this is done is Apache Druid (
> https://druid.apache.org/community/ see Getting Help).
>
> I dislike the Druid example as it shows who the
> committers are working for, that should not matter. Individuals contribute
> to Apache projects not companies. Having links to those companies (next to
> the committer name) when they may or may not be ASF sponsors is even worse.
>
> Re commercial supped listing them is OK as long as all
> that ask are listed and it not being seen as promoting or suggesting one
> over another. It must be vendor neutral.
>
> Thanks,
> Justin
>
>
>
>
>
>
>
>
>
>
>

Re: [DISCUSS] Guideline for "professional support" Mentioning on Homepage

[Niclas Hedhman]

1. On a page /commercial-support you explain the general principle that the
ASF is a vendor neutral place and favors are frowned upon.

2. On that page, recommend the user to instead use their favorite search
engine to look up (e.g) "plc4x_commercial_support" to find companies that
provide such.

3. People here would know, and can imply, that their own landing pages for
commercial support should contain that word for customers to find them.


HTH
Niclas



On Mon, Jan 27, 2020 at 6:21 PM Christofer Dutz 
wrote:

> Hi Niclas,
>
> have to admit that I didn't quite understand your suggestion.
>
> Chris
>
>
>
> Am 27.01.20, 10:01 schrieb "Niclas Hedhman" :
>
> My two cents; you could recommend that companies that has commercial
> support to use a unique name on their offering/landing page that gets
> picked up by search engines and let the general public know what that
> word
> is...
>
> When I personally am looking for this for project Foo, then "foo -site:
> apache.org" is the starting point. And that could be smoother.
>
>
> Cheers
>
> On Mon, Jan 27, 2020, 16:28 Julian Feinauer <
> j.feina...@pragmaticminds.de>
> wrote:
>
> > Hes, but as I understand it you are already doing that, so this
> should
> > yield result soon : )
> >
> > Am 27.01.20, 09:24 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
> >
> > Yeah ...
> >
> > not sure this is not too much ... we should in general have this
> > checked if such a page would be in line with the ASF bylaws.
> >
> > Chris
> >
> > Am 27.01.20, 08:21 schrieb "Julian Feinauer" <
> > j.feina...@pragmaticminds.de>:
> >
> > Hi,
> >
> > I think we should list the companies with a short outline
> like,
> > e.g. postgres does it here:
> > https://www.postgresql.org/support/professional_support/europe/
> >
> > For codecentric one could write (I see no problem):
> > PLC4X was initially started as an internal project at
> codecentric
> > and open soure to the ASF. Christofer Dutz, the initiatior of PLC4X
> helps
> > in his daytime job clients with the implementation of Drivers and
> blab la
> > blab la
> >
> > And for us we could / would write something similar:
> > The beautiful, wise, intelligent and charismatic Julian and
> his
> > blalbalblablalbal
> >
> > I think you get the point? : )
> >
> > Julian
> >
> > Am 27.01.20, 08:17 schrieb "Christofer Dutz" <
> > christofer.d...@c-ware.de>:
> >
> > Hi Julian,
> >
> > I think having links to commercial support offerings is a
> > pretty important thing for us to have.
> > If we have to allow anyone be listed there (even if they
> don't
> > contribute to the project) well that will be "the toad we have to
> swallow"
> > (Don't know how to translate this German saying to English).
> >
> > Right now I see the industries worries of not being able
> to
> > get commercial support as being one of the most problematic things
> ... that
> > was why I put the "commercial support" thing on our landing page.
> >
> > Would it be possible to mark companies who employ
> committers
> > of the project (but not which ones) with a "*" and an explanation?
> >
> > Chris
> >
> >
> >
> > Am 27.01.20, 08:10 schrieb "Julian Feinauer" <
> > j.feina...@pragmaticminds.de>:
> >
> > Hey,
> >
> > @Christofer Dutz you can also a general discuss about
> > whether or not we should do that.
> > I am mostly concerned with clear rules, if we do it.
> > But, in the end, its not granted, lets discuss it
> and if
> > we cant get an agreement decide it.
> >
> > Julian
> >
> > Am 27.01.20, 06:55 schrieb "Christofer Dutz" <
> > christofer.d...@c-ware.de>:
> >
> > Hi Justin,
> >
> > S

Re: SPI Module - OSGi Bundle

[Niclas Hedhman]

actually, I just wanted to test the new
> TagData of the integration. This is the bundling in the pom, these imports
> had to be there before too
> > > >
> > > >  
> > > > org.apache.felix
> > > > maven-bundle-plugin
> > > > 4.2.1
> > > > true
> > > > 
> > > > 
> > > >
>  ${project.artifactId}
> > > >
>  ${project.version}
> > > > 
> > > >*;version=${project.version}
> > > > 
> > > > 
> > > > org.apache.plc4x.java.spi.transport,
> > > > org.apache.plc4x.java.s7.readwrite,
> > > > *
> > > > 
> > > > 
> > > > 
> > > > 
> > > >
> > > >
> > > > Etienne
> > > >
> > > > On 2020/04/03 08:17:45, Christian Schneider 
> wrote:
> > > >> The code in plc4x directly uses the class (not a String of the
> name). This
> > > >> is good. Normally such a class reference should work fine.
> > > >>
> > > >> Can you show your code as a complete example?
> > > >>
> > > >> Christian
> > > >>
> > > >>
> > > >> Am Fr., 3. Apr. 2020 um 09:58 Uhr schrieb Julian Feinauer <
> > > >> j.feina...@pragmaticminds.de>:
> > > >>
> > > >>> I am off with my knowledge.
> > > >>> You could ask the Karaf friends (#karaf in Slack). They are all
> OSGi
> > > >>> experts and very friendly and helpful.
> > > >>> Or perhaps Christian has an idea here?
> > > >>>
> > > >>> Best
> > > >>> Julian
> > > >>>
> > > >>> Am 03.04.20, 09:50 schrieb "Etienne Robinet"  >:
> > > >>>
> > > >>> Hi again,
> > > >>> I've been struggling with this issue for 2 days now... I still
> don't
> > > >>> get it why it can not find classes. here is the current problem:
> > > >>> https://i.imgur.com/LtZMdsu.png
> > > >>>
> > > >>> We can see that the classes are available and exported, I
> don't know
> > > >>> why the Camel Context can't find it. I even tried to add an
> Activator to my
> > > >>> bundle, and load these classes there and it works! But not in the
> > > >>> blueprint. If anyone had any idea on where the problem is...
> > > >>>
> > > >>> Etienne
> > > >>>
> > > >>> On 2020/04/01 01:31:15, Niclas Hedhman 
> wrote:
> > > >>> > It happens that OSGi classloading result in the wrong NCDFE
> and that
> > > >>> one of
> > > >>> > the classes "used" (i.e. return type, parameter, throws,
> extends,
> > > >>> > implements) in the reported class is not visible by the
> classloader.
> > > >>> And
> > > >>> > occasionally, it is a "diamond problem", i.e. that the
> Constraints
> > > >>> (IIRC,
> > > >>> > see chapter 3.8 in OSGi spec) can't be satisfied.
> > > >>> >
> > > >>> > Sorry that I don't have time to dig into the actual
> situation here,
> > > >>> but I
> > > >>> > thought I could share some of my past (dark) history ;-)
> > > >>> >
> > > >>> > Cheers
> > > >>> > Niclas
> > > >>> >
> > > >>> > On Wed, Apr 1, 2020 at 12:43 AM Christofer Dutz <
> > > >>> christofer.d...@c-ware.de>
> > > >>> > wrote:
> > > >>> >
> > > >>> > > Hi all,
> > > >>> > >
> > > >>> > > But If I search for uses of that class, it's only in the
> > > >>> > > org.apache.plc4x.java.spi.connection.NettyChannelFactory
> which is
> > > >>> in the
> > > >>> > 

Re: Big and littleendian fields in one mspec

[Niclas Hedhman]

For us who were around and shaping the protocols in the 1980s, and people
before us (and before standards like RS-232), a lot of the "specifications"
came out of "observation of implementation we managed to get to work",
rather than "implement this spec". A lot was due to extreme memory
constraints (in my case, multi-tasking operating system, serial protocol
187kbps, interpreted programming language with floating point ops and user
applications in 2kB RAM and 8kB EPROM) and a general lack of information,
like what other people were doing, sharing experiences and so on.

And there were many "innovative" ways to squeeze just a little bit extra
out of the hardware, resulting in "hard to understand" consequences. Bit
packing was a typical one, multiple functions packed into a single byte.
Look at page 14 in https://www.nxp.com/docs/en/data-sheet/80C31_80C32.pdf
and read up on "UART Enahanced Mode", and we used this, i.e. 9 bits, no
parity and clever use of address and mask to create a slave-to-slave direct
protocol, where the master's role was to signal which slave "owned" the
cable. Yeah, in that 8kB ROM limitation (I think protocol was about 1kB
ROM) and something like 150 bytes RAM for comm protocol.

Could you implement a compatible device to this with PLC4X and modern
hardware (i.e. no 8031/32 co-processor)? Possibly but bit-banging is needed
to support the 9bit data (+start and stop bits) and an awful lot of CPU
cycles on something that was automatic on one of the slowest long-lived
microcontroller ever.


My point was only to highlight that some of the strange things you see in
protocols today, have its roots in pre-standardization days. Today no one
would go down that route, because the hardware cost nothing now (8031  +
8kB EPROM + 2kB static RAM + battery backup => ~$50 in 1983's currency) and
longevity of software is more important.

Cheers
Niclas


On Sun, Apr 12, 2020 at 10:10 PM Christofer Dutz 
wrote:

> Hi Lukasz,
>
> I think it really gets tricky when using BE and having some byte-odd-sizes
> ... I remember in the Firmata protocol there were some bitmasks and then 10
> bit uint as BE ... not it really got tricky as the specs were written from
> a point of view: You read 16 bits BE and then the first6 bits mean XYZ
> instead of describing how the bits actually travel over the wire.
>
> Chris
>
>
>
> Am 11.04.20, 01:21 schrieb "Łukasz Dywicki" :
>
> I've made some progress with topic by modyfing mspec and allowing
> 'little endian' flag on fields. This moved me further to next issue -
> which is whole type encoded little endian.
>
> In ADS driver such type is State, which has 2 bytes and uses 8 bits for
> various flags.
> There are two cases which require different approach - reading and
> writing. So for reading we need to swap N bytes based on type length.
> For writing we need to alocate buffer for N bytes and swap them before
> writing.
>
> I am stuck now with freemaker templates and bit-io.
>
> Cheers,
> Łukasz
>
>
>
> On 10.04.2020 17:57, Łukasz Dywicki wrote:
> > I am doing some tests of ADS serialization.
> >
> > I've run into some troubles with payload which is generated with new
> > driver. I'm not sure if that's my fault or generated code.
> >
> > I did a verification of what Wireshark shows and how ads structures
> are
> > parsed. There is a gap I think. For example ams port number 1000
> > (0x1027) is read as 4135.
> >
> > Obviously I used wrong structures while implementing protocol logic
> in
> > first place, but now I am uncertain of how fields are encoded. How we
> > mark field as little endian when rest of payload is big endian? Do we
> > have `uint_le`?
> >
> > As far I remember route creation logic I was tracking last week used
> > combination of LE and BE.
> >
> > Best regards,
> > Łukasz
> >
>
>
>

Re: SPI Module - OSGi Bundle

[Niclas Hedhman]

t; org.apache.felix
> > > maven-bundle-plugin
> > > 4.2.1
> > > true
> > > 
> > > 
> > >
> >  ${project.artifactId}
> > >
> >  ${project.version}
> > > 
> > >*;version=${project.version}
> > > 
> > > 
> > > org.apache.plc4x.java.spi.transport,
> > > org.apache.plc4x.java.s7.readwrite,
> > > *
> > > 
> > > 
> > > 
> > > 
> > >
> > >
> > > Etienne
> > >
> > > On 2020/04/03 08:17:45, Christian Schneider 
> > wrote:
> > >> The code in plc4x directly uses the class (not a String of the name).
> > This
> > >> is good. Normally such a class reference should work fine.
> > >>
> > >> Can you show your code as a complete example?
> > >>
> > >> Christian
> > >>
> > >>
> > >> Am Fr., 3. Apr. 2020 um 09:58 Uhr schrieb Julian Feinauer <
> > >> j.feina...@pragmaticminds.de>:
> > >>
> > >>> I am off with my knowledge.
> > >>> You could ask the Karaf friends (#karaf in Slack). They are all OSGi
> > >>> experts and very friendly and helpful.
> > >>> Or perhaps Christian has an idea here?
> > >>>
> > >>> Best
> > >>> Julian
> > >>>
> > >>> Am 03.04.20, 09:50 schrieb "Etienne Robinet" :
> > >>>
> > >>> Hi again,
> > >>> I've been struggling with this issue for 2 days now... I still
> > don't
> > >>> get it why it can not find classes. here is the current problem:
> > >>> https://i.imgur.com/LtZMdsu.png
> > >>>
> > >>> We can see that the classes are available and exported, I don't
> > know
> > >>> why the Camel Context can't find it. I even tried to add an Activator
> > to my
> > >>> bundle, and load these classes there and it works! But not in the
> > >>> blueprint. If anyone had any idea on where the problem is...
> > >>>
> > >>> Etienne
> > >>>
> > >>> On 2020/04/01 01:31:15, Niclas Hedhman 
> wrote:
> > >>> > It happens that OSGi classloading result in the wrong NCDFE and
> > that
> > >>> one of
> > >>> > the classes "used" (i.e. return type, parameter, throws,
> extends,
> > >>> > implements) in the reported class is not visible by the
> > classloader.
> > >>> And
> > >>> > occasionally, it is a "diamond problem", i.e. that the
> > Constraints
> > >>> (IIRC,
> > >>> > see chapter 3.8 in OSGi spec) can't be satisfied.
> > >>> >
> > >>> > Sorry that I don't have time to dig into the actual situation
> > here,
> > >>> but I
> > >>> > thought I could share some of my past (dark) history ;-)
> > >>> >
> > >>> > Cheers
> > >>> > Niclas
> > >>> >
> > >>> > On Wed, Apr 1, 2020 at 12:43 AM Christofer Dutz <
> > >>> christofer.d...@c-ware.de>
> > >>> > wrote:
> > >>> >
> > >>> > > Hi all,
> > >>> > >
> > >>> > > But If I search for uses of that class, it's only in the
> > >>> > > org.apache.plc4x.java.spi.connection.NettyChannelFactory
> which
> > is
> > >>> in the
> > >>> > > SPI module.
> > >>> > >
> > >>> > > So I am not sure where this is accessed directly from the
> > outside.
> > >>> I know
> > >>> > > every driver would use the NettyChannelFactory, but that
> > shouldn't
> > >>> be an
> > >>> > > OSGi type problem as the SPI classes should be able to access
> > >>> their own
> > >>> > > classes.
> > >>> > >
> > >

Re: SPI Module - OSGi Bundle

[Niclas Hedhman]

It happens that OSGi classloading result in the wrong NCDFE and that one of
the classes "used" (i.e. return type, parameter, throws, extends,
implements) in the reported class is not visible by the classloader. And
occasionally, it is a "diamond problem", i.e. that the Constraints (IIRC,
see chapter 3.8 in OSGi spec) can't be satisfied.

Sorry that I don't have time to dig into the actual situation here, but I
thought I could share some of my past (dark) history ;-)

Cheers
Niclas

On Wed, Apr 1, 2020 at 12:43 AM Christofer Dutz 
wrote:

> Hi all,
>
> But If I search for uses of that class, it's only in the
> org.apache.plc4x.java.spi.connection.NettyChannelFactory which is in the
> SPI module.
>
> So I am not sure where this is accessed directly from the outside. I know
> every driver would use the NettyChannelFactory, but that shouldn't be an
> OSGi type problem as the SPI classes should be able to access their own
> classes.
>
> Chris
>
>
>
> Am 31.03.20, 16:07 schrieb "Etienne Robinet" <43...@etu.he2b.be>:
>
> Hi,
> From the log the class is called outside the SPI by the transport
>
> Etienne
>
> > Le 31 mars 2020 à 15:24, Julian Feinauer <
> j.feina...@pragmaticminds.de> a écrit :
> >
> > Hi,
> >
> > yes, if ist only needed internally its fine.But why does someone
> then get a Class Not Found Exception?
> > This is usually a hint to some class loader issue in OSGi which is
> related to exports/ imports.
> >
> > J
> >
> > Am 31.03.20, 15:23 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
> >
> >As this package is only referenced from within SPI, couldn't we
> just exclude it from the package exports?
> >
> >Chris
> >
> >Am 31.03.20, 15:17 schrieb "Julian Feinauer" <
> j.feina...@pragmaticminds.de>:
> >
> >Hi,
> >
> >the issue is that if we export it, then we break Nettys OSGi
> integration as we get a split package situation (two bundles exporting the
> same package, which is forbidden in OSGi).
> >
> >So I see no easy solution (but had to do the same once as
> Netty is pretty... private).
> >
> >J
> >
> >Am 31.03.20, 15:15 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
> >
> >Hi all,
> >
> >I just discussed this issue with Etienne and I thought it
> was important for all, so I asked him to bring it here.
> >
> >In my effort to get the EmbeddedChannel working as a full
> "transport" module, I had to override the Netty Bootstrap mechanism.
> >Unfortunately in order to do so, I need to call "init"
> from the derived class. Unfortunately this is package private in Netty so I
> had
> >To add it to the same package.
> >
> >Would it help to just not export these packages to OSGi?
> >
> >But I'm also open for alternatives (Please none involving
> mega-evil reflection hackery).
> >
> >
> >Chris
> >
> >Am 31.03.20, 15:10 schrieb "Etienne Robinet" <
> erobi...@apache.org>:
> >
> >Hi all,
> >I've been working on the Camel Component and decided
> to test it inside Karaf, but I noticed that I've got this error now:
> >https://i.imgur.com/kUZPwZ5.png
> >
> >Seems like this class is not exported by the bundle
> so it can not be found. Anyone has an idea on how we could solve this?
> >
> >Etienne
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>

Re: SPI Module - OSGi Bundle

[Niclas Hedhman]

   org.apache.felix
> > >>>>>maven-bundle-plugin
> > >>>>>4.2.1
> > >>>>>true
> > >>>>>
> > >>>>>
> > >>>>>
> > ${project.artifactId}
> > >>>>>
> > ${project.version}
> > >>>>>
> > >>>>>   *;version=${project.version}
> > >>>>>
> > >>>>>
> > >>>>>org.apache.plc4x.java.spi.transport,
> > >>>>>org.apache.plc4x.java.s7.readwrite,
> > >>>>>*
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Etienne
> > >>>>>
> > >>>>> On 2020/04/03 08:17:45, Christian Schneider <
> > ch...@die-schneider.net> wrote:
> > >>>>>> The code in plc4x directly uses the class (not a String of the
> > name). This
> > >>>>>> is good. Normally such a class reference should work fine.
> > >>>>>>
> > >>>>>> Can you show your code as a complete example?
> > >>>>>>
> > >>>>>> Christian
> > >>>>>>
> > >>>>>>
> > >>>>>> Am Fr., 3. Apr. 2020 um 09:58 Uhr schrieb Julian Feinauer <
> > >>>>>> j.feina...@pragmaticminds.de>:
> > >>>>>>
> > >>>>>>> I am off with my knowledge.
> > >>>>>>> You could ask the Karaf friends (#karaf in Slack). They are
> > all OSGi
> > >>>>>>> experts and very friendly and helpful.
> > >>>>>>> Or perhaps Christian has an idea here?
> > >>>>>>>
> > >>>>>>> Best
> > >>>>>>> Julian
> > >>>>>>>
> > >>>>>>> Am 03.04.20, 09:50 schrieb "Etienne Robinet" <
> > erobi...@apache.org>:
> > >>>>>>>
> > >>>>>>>Hi again,
> > >>>>>>>I've been struggling with this issue for 2 days now... I
> > still don't
> > >>>>>>> get it why it can not find classes. here is the current
> > problem:
> > >>>>>>>https://i.imgur.com/LtZMdsu.png
> > >>>>>>>
> > >>>>>>>We can see that the classes are available and exported, I
> > don't know
> > >>>>>>> why the Camel Context can't find it. I even tried to add an
> > Activator to my
> > >>>>>>> bundle, and load these classes there and it works! But not in
> > the
> > >>>>>>> blueprint. If anyone had any idea on where the problem is...
> > >>>>>>>
> > >>>>>>>Etienne
> > >>>>>>>
> > >>>>>>>On 2020/04/01 01:31:15, Niclas Hedhman <
> nic...@hedhman.org>
> > wrote:
> > >>>>>>>> It happens that OSGi classloading result in the wrong NCDFE
> > and that
> > >>>>>>> one of
> > >>>>>>>> the classes "used" (i.e. return type, parameter, throws,
> > extends,
> > >>>>>>>> implements) in the reported class is not visible by the
> > classloader.
> > >>>>>>> And
> > >>>>>>>> occasionally, it is a "diamond problem", i.e. that the
> > Constraints
> > >>>>>>> (IIRC,
> > >>>>>>>> see chapter 3.8 in OSGi spec) can't be satisfied.
> > >>>>>>>>
> > >>>>>>>> Sorry that I don't have time to d

Re: [Introduction] Christofer Dutz

[Niclas Hedhman]

On Tue, May 5, 2020 at 7:23 PM Christofer Dutz 
wrote:

> Being an IT guy living near Frankfurt (Germany) there is almost no chance
> to not work for Banks and Insurance companies. So I guess I’ve been working
> for about 12 different Banks and Insurance companies in the last 15 years.
> I always like to compare working for a bank like asking Picasso to paint a
> portrait, but to have him wear a mental-institution restraining jacket and
> have him paint with a brush in his mouth.


I love the analogy! I was at a huge investment bank for 4 years, and
managed to "break free" of the straight-jacket, and only got "caught" when
the project was ready to launch and I was 1/8th of the budget and 1/4th of
the time allocated. My boss' boss' boss took notice, and screamed "shut
that down", about a week before going live. Can't have something like that
lowering his budget allocation. Got transferred internally to the Java
support team, mainly to be responsible for bringing open source into the
firm.


> It was that time that Industry 4.0 was everywhere … all the problems are
> easily addressable with open-source and a lot of the skills I have from the
> banking would have been a perfect match. So I had a look at what’s missing
> in this big picture and pretty quickly noticed the data-access problem is
> the biggest barrier and no solution being available or in sight.
>

Absolutely. What is now called IIoT is nothing new as a principle. The
first buildings I connected to the Internet happened in 1998. And way back
in 1986, I created one of the first PLC-to-PLC dial-up (both directions)
systems at Exomatic (now part of Regin AB). I didn't think much about it at
the time, it was a natural thing, except the modems were a pain, both due
to the incompatible AT commands, non-optimized default settings, and the
fact that they often stopped responding. BUT, I think that part of our
technology made a huge difference to gain customers.

Another huge passion of mine is melodic electronic music, so usually I
> travel around the Europe visiting different electronic music festivals.
>

Do you play/compose as well? One of my personal thing is Eurorack Modular
Synthesizers, but mainly construction. My son take care of the playing.


> I live in a town called Ober-Ramstadt together with my girlfriend Tanja,
> where we just moved into a house I inherited from my grandpa and which we
> renovated in 2 years of hard work … and still the work doesn’t end … so
> some-times I fall off the face of the earth for a few days cause I’m
> probably digging trenches for the foundation for some wall, or my
> rain-water system, or … or … or …. Guess the digging never stops.
>

He he he... My parents bought an ex-old-folks home in 1970, when it was
nearly impossible to borrow money, for $5000. Constant renovation continued
to ~1995, then slowed down to a project per year until ~2005, when my dad
got too old (80) for heavy duty work. So, I understand the challenge you
have in front of you ;-) ...


> Ok … so I hope this gives you a little impression on who I am and what
> drives me … it would make me happy to see some of you folks also introduce
> yourself. And I would even more love to have a beer with you (Or, as I’m a
> hessian … a big glass of apple wine) 
>

Really cool to hear. I'll pop by if I am in the neighborhood. I was
commuting to Wiesbaden in 2008 for a customer. 2 weeks at home, 4-6 weeks
in Wiesbaden, for about a year. It might happen again ;-)

Btw, my "home" is Malaysia and if anyone from this community happens to
pass through Kuala Lumpur, shout and we'll have a good meal and a beer.


// Niclas

Re: SPI Module - OSGi Bundle

[Niclas Hedhman]

ce for osgi
> specific logic. That is a standard dilema to address in how we want to
> treat osgi and non-osgi users. :-)
>
> Cheers!
> Łukasz
>
> On 05.05.2020 12:34, Julian Feinauer wrote:
> > Hi Etienne and Niclas,
> >
> > indeed we could orient (again) on how JDBC does that in OSGi.
> > They really focus on "late binding" so that you resolve the driver
> directly when you need it.
> > In theory, there is no such thing as a DriverManager in OSGi but only a
> PlcDriver with the capability ("plc4x-protocol": "s7") or something.
> >
> > I did it witht he driver maanger mostly fort he ease as first approach.
> >
> > Julian
> >
> > Am 05.05.20, 12:30 schrieb "Niclas Hedhman" :
> >
> > Also, just in case, a custom activator is ever required, it can be
> > overridden easily without breaking the over all design
> >
> > On Tue, May 5, 2020 at 6:27 PM Niclas Hedhman 
> wrote:
> >
> > > Yes, that's what I mean, because that is what you have inside the
> loop, so
> > > it should work.
> > >
> > > On Tue, May 5, 2020 at 11:50 AM Robinet, Etienne <
> 43...@etu.he2b.be>
> > > wrote:
> > >
> > >> Hi Niclas,
> > >> thanks for the feedback. So you mean to make the Activator in
> API/SPI
> > >> generic so every Driver would call it and declare the service
> itself?
> > >>
> > >> Le mar. 5 mai 2020 à 05:25, Niclas Hedhman 
> a écrit :
> > >>
> > >> > What you are doing is not particularly OSGi-y... The expected
> way to do
> > >> > this is to have each bundle register their PlcDriver or
> Transport to the
> > >> > OSGi service registry.
> > >> >
> > >> > That said, what you have done is otherwise fine, as you
> basically
> > >> trying to
> > >> > centralize the BundleActivators away from respective
> Driver/Transport.
> > >> And
> > >> > I assume you do so to limit code in the drivers/transports.
> > >> >
> > >> > Another way would be to make two generic BundleActivator in
> this bundle
> > >> and
> > >> > have each driver/transport just declare them in the manifest.
> That
> > >> would be
> > >> > a bit more conventional.
> > >> >
> > >> > // Niclas
> > >> >
> > >> > On Tue, May 5, 2020 at 11:06 AM Robinet, Etienne <
> 43...@etu.he2b.be>
> > >> > wrote:
> > >> >
> > >> > > Hi all,
> > >> > > With the change of Christofer this problem got solved.
> Nonetheless, I
> > >> > kept
> > >> > > the work I did (inspired by the work of Lukasz) to make an
> Activator
> > >> for
> > >> > > API (Driver Services) and SPI (Transport Services). I also
> tested it,
> > >> but
> > >> > > as I am pretty new to this, if anyone could just give me a
> feedback on
> > >> > the
> > >> > > code:
> > >> > >
> > >> > > API Activator:
> > >> > >
> > >> > >
> > >> >
> > >>
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java
> > >> > > SPI Activator:
> > >> > >
> > >> > >
> > >> >
> > >>
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/spi/src/main/java/org/apache/plc4x/java/osgi/SpiActivator.java
> > >> > >
> > >> > > If everything is alright, I could merge this today.
> > >> > >
> > >> > > Etienne
> > >> > >
> > >> > > Le mar. 7 avr. 2020 à 17:52, Christofer Dutz <
> > >> christofer.d...@c-ware.de>
> > >> > a
> > >> > > écrit :
> > >> > >
> > >> > > > Hi folks,
> > >> > > >
> > >> > > > I just pushed a change that might get rid of this error.
> > >> > > >
> > >> > > > I added the Plc4xBootstrap in an at

Re: SPI Module - OSGi Bundle

[Niclas Hedhman]

Also, just in case, a custom activator is ever required, it can be
overridden easily without breaking the over all design

On Tue, May 5, 2020 at 6:27 PM Niclas Hedhman  wrote:

> Yes, that's what I mean, because that is what you have inside the loop, so
> it should work.
>
> On Tue, May 5, 2020 at 11:50 AM Robinet, Etienne <43...@etu.he2b.be>
> wrote:
>
>> Hi Niclas,
>> thanks for the feedback. So you mean to make the Activator in API/SPI
>> generic so every Driver would call it and declare the service itself?
>>
>> Le mar. 5 mai 2020 à 05:25, Niclas Hedhman  a écrit :
>>
>> > What you are doing is not particularly OSGi-y... The expected way to do
>> > this is to have each bundle register their PlcDriver or Transport to the
>> > OSGi service registry.
>> >
>> > That said, what you have done is otherwise fine, as you basically
>> trying to
>> > centralize the BundleActivators away from respective Driver/Transport.
>> And
>> > I assume you do so to limit code in the drivers/transports.
>> >
>> > Another way would be to make two generic BundleActivator in this bundle
>> and
>> > have each driver/transport just declare them in the manifest. That
>> would be
>> > a bit more conventional.
>> >
>> > // Niclas
>> >
>> > On Tue, May 5, 2020 at 11:06 AM Robinet, Etienne <43...@etu.he2b.be>
>> > wrote:
>> >
>> > > Hi all,
>> > > With the change of Christofer this problem got solved. Nonetheless, I
>> > kept
>> > > the work I did (inspired by the work of Lukasz) to make an Activator
>> for
>> > > API (Driver Services) and SPI (Transport Services). I also tested it,
>> but
>> > > as I am pretty new to this, if anyone could just give me a feedback on
>> > the
>> > > code:
>> > >
>> > > API Activator:
>> > >
>> > >
>> >
>> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java
>> > > SPI Activator:
>> > >
>> > >
>> >
>> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/spi/src/main/java/org/apache/plc4x/java/osgi/SpiActivator.java
>> > >
>> > > If everything is alright, I could merge this today.
>> > >
>> > > Etienne
>> > >
>> > > Le mar. 7 avr. 2020 à 17:52, Christofer Dutz <
>> christofer.d...@c-ware.de>
>> > a
>> > > écrit :
>> > >
>> > > > Hi folks,
>> > > >
>> > > > I just pushed a change that might get rid of this error.
>> > > >
>> > > > I added the Plc4xBootstrap in an attempt to get the TestTransport
>> > > working.
>> > > > For some reasons the netty folks created the EmbeddedChannel
>> > differently
>> > > > than the rest.
>> > > > However as the TestTransport is the only one needing this change, I
>> > moved
>> > > > these classes to the test-transport module
>> > > > and extended NettyChannelFactory with a createBootstrap method
>> which is
>> > > > simply overridden in TestTransport.
>> > > >
>> > > > So please give everything a try if it now works as planned.
>> > > >
>> > > > Chris
>> > > >
>> > > >
>> > > >
>> > > > Am 07.04.20, 17:36 schrieb "Etienne Robinet" <43...@etu.he2b.be>:
>> > > >
>> > > > Hi all,
>> > > > I’ve checked the Manifest. If I put the Embed-Dependency to the
>> > > > plc4j-spi artifact  it does not find the Transport Service. And if I
>> > dont
>> > > > it does not find the Plc4xBootstrap.
>> > > >
>> > > > Etienne ROBINET
>> > > >
>> > > > > Le 7 avr. 2020 à 16:48, Łukasz Dywicki 
>> a
>> > > > écrit :
>> > > > >
>> > > > > I was updating my local checkout yesterday. Can't promise if I
>> > will
>> > > > be
>> > > > > able to help, but will give a try with 0.7 snapshot.
>> > > > >
>> > > > > Best,
>> > > > > Łukasz
>> > > > >
>> > > > >
>> > > > >> On 07.04.2020 15:39, Etienne Robinet wrote:
>> > &

Re: SPI Module - OSGi Bundle

[Niclas Hedhman]

Yes, that's what I mean, because that is what you have inside the loop, so
it should work.

On Tue, May 5, 2020 at 11:50 AM Robinet, Etienne <43...@etu.he2b.be> wrote:

> Hi Niclas,
> thanks for the feedback. So you mean to make the Activator in API/SPI
> generic so every Driver would call it and declare the service itself?
>
> Le mar. 5 mai 2020 à 05:25, Niclas Hedhman  a écrit :
>
> > What you are doing is not particularly OSGi-y... The expected way to do
> > this is to have each bundle register their PlcDriver or Transport to the
> > OSGi service registry.
> >
> > That said, what you have done is otherwise fine, as you basically trying
> to
> > centralize the BundleActivators away from respective Driver/Transport.
> And
> > I assume you do so to limit code in the drivers/transports.
> >
> > Another way would be to make two generic BundleActivator in this bundle
> and
> > have each driver/transport just declare them in the manifest. That would
> be
> > a bit more conventional.
> >
> > // Niclas
> >
> > On Tue, May 5, 2020 at 11:06 AM Robinet, Etienne <43...@etu.he2b.be>
> > wrote:
> >
> > > Hi all,
> > > With the change of Christofer this problem got solved. Nonetheless, I
> > kept
> > > the work I did (inspired by the work of Lukasz) to make an Activator
> for
> > > API (Driver Services) and SPI (Transport Services). I also tested it,
> but
> > > as I am pretty new to this, if anyone could just give me a feedback on
> > the
> > > code:
> > >
> > > API Activator:
> > >
> > >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java
> > > SPI Activator:
> > >
> > >
> >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/spi/src/main/java/org/apache/plc4x/java/osgi/SpiActivator.java
> > >
> > > If everything is alright, I could merge this today.
> > >
> > > Etienne
> > >
> > > Le mar. 7 avr. 2020 à 17:52, Christofer Dutz <
> christofer.d...@c-ware.de>
> > a
> > > écrit :
> > >
> > > > Hi folks,
> > > >
> > > > I just pushed a change that might get rid of this error.
> > > >
> > > > I added the Plc4xBootstrap in an attempt to get the TestTransport
> > > working.
> > > > For some reasons the netty folks created the EmbeddedChannel
> > differently
> > > > than the rest.
> > > > However as the TestTransport is the only one needing this change, I
> > moved
> > > > these classes to the test-transport module
> > > > and extended NettyChannelFactory with a createBootstrap method which
> is
> > > > simply overridden in TestTransport.
> > > >
> > > > So please give everything a try if it now works as planned.
> > > >
> > > > Chris
> > > >
> > > >
> > > >
> > > > Am 07.04.20, 17:36 schrieb "Etienne Robinet" <43...@etu.he2b.be>:
> > > >
> > > > Hi all,
> > > > I’ve checked the Manifest. If I put the Embed-Dependency to the
> > > > plc4j-spi artifact  it does not find the Transport Service. And if I
> > dont
> > > > it does not find the Plc4xBootstrap.
> > > >
> > > > Etienne ROBINET
> > > >
> > > > > Le 7 avr. 2020 à 16:48, Łukasz Dywicki  a
> > > > écrit :
> > > > >
> > > > > I was updating my local checkout yesterday. Can't promise if I
> > will
> > > > be
> > > > > able to help, but will give a try with 0.7 snapshot.
> > > > >
> > > > > Best,
> > > > > Łukasz
> > > > >
> > > > >
> > > > >> On 07.04.2020 15:39, Etienne Robinet wrote:
> > > > >> Hi again,
> > > > >> I've been looking at this issue all day, and I am back to the
> > > > initial error:
> > > > >> https://i.imgur.com/LLfan8H.png
> > > > >>
> > > > >> The difference is I used and Activator for API and SPI to
> > register
> > > > the driver and transports Service, which are then loaded by the
> custom
> > > > blueprint. The error now is caused again because this class is not
> > > exported
> > > > (I think?) by the SPI, but is used by

Re: SPI Module - OSGi Bundle

[Niclas Hedhman]

My suggestion was;
1. Don't do the BundleTracker classes, and instead change to a bundle
activator for each.
2. Add the "Bundle-Activator: org.apache.plc4x.java.osgi.DriverActivator"
to the driver META/MANIFEST.MF
3. Do the equivalent for the Transports.

public class DriverActivator implements BundleActivator {

private ServiceRegistration reg;

@Override
public void start( BundleContext context ) throws Exception {
Hashtable props = new Hashtable<>();
props.put( OsgiDriverManager.PROTOCOL_CODE, driver.getProtocolCode() );
props.put( OsgiDriverManager.PROTOCOL_NAME, driver.getProtocolName() );
reg = context.registerService( PlcDriver.class, driver, props );
}

@Override
public void stop( BundleContext context ) {
context.unregisterService( reg );
}
}









On Wed, May 6, 2020 at 2:33 PM Etienne Robinet  wrote:

> Hi all,
> So concretely what changes should be done so that a Driver/Transport
> declares itself his service? Beside the changes in the manifest?
> Etienne
> On 2020/05/06 01:26:42, Niclas Hedhman  wrote:
> > Łukasz,
> >
> > the reason I say it is not very OSGi-y, is that the principle of OSGi is
> > that the bundle handles its own service registrations. In the case of
> JDBC
> > (I initiated that spec, and I am the founder of OPS4J as well as Pax
> > subproject, 2005), it needed to address the problem that JDBC drivers
> > existed and changing their build and/or manifests was decided to be "not
> > viable". The approach there is a work-around for legacy code, which I and
> > Stuart McCulloch basically invented. IIRC, this happened in 2007.
> >
> > I didn't suggest that bundles require Declarative Services. I suggested
> > that the "inside of the loop" in Etienne's code is put into an Activator,
> > the code residing in the API and SPI bundles respectively, and that each
> > driver/transport has a "Bundle-Activator: ." in the manifest
> > referencing respective activator. It is not more intrusive than the
> > Export-Package, Import-Package that will be required anyway.
> >
> > Advantages; It is more in the spirit of OSGi. But importantly, the
> > driver/transport is now an active bundle, rather than a library bundle,
> and
> > in theory the start/stop of a bundle could (there might be other reasons
> > why not) turn it on/off in runtime. If special needs pop up, maybe to
> > deploy for the OpenHAB project, it is possible to override the
> > driver/transport with hacking the API/SPI bundles.
> >
> > And I can't see any disadvantages other than "need to rework a bit of
> code".
> >
> > But I don't have skin in the game. Not in OSGi, not here, so take my
> > recommendations into consideration or throw them away. I just got the
> > impression that you didn't really get what I suggested.
> >
> >
> > // Niclas
> >
> >
> >
> > On Wed, May 6, 2020 at 4:57 AM Łukasz Dywicki 
> wrote:
> >
> > > Hey Etienne, that's awesome piece of work. I can test it! :-)
> > >
> > > I believe that's what Etienne code does it in a valid OSGi way. And I
> do
> > > believe not because he mentioned me by name, but due to below
> > > argumentation.
> > >
> > > Proposed code uses extender pattern to grab specific META-INF/services
> > > entries and register them in OSGi service registry. If you will take a
> > > look on following line:
> > >
> > >
> https://github.com/apache/plc4x/blob/feature/osgi/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/ApiActivator.java#L63
> > > you will find that bundle is an jar which changes state to ACTIVE.
> > > Additionally that bundle classloader is used to find services and that
> > > bundle context is used to register services. In the end service which
> > > appears looks like one registered by driver/transport module.
> > >
> > > The main point for above implementation is basic - getting the standard
> > > PLC4X driver JAR working in OSGi without forcing it to knowing too much
> > > about OSGi. Driver needs to ship manifest with import/export statements
> > > and that's it. Additionally driver does not have to have a XML
> > > descriptor which registers service. Quite many third parties might be
> > > supplying drivers without any or with limited knowledge of OSGi.
> > > Do drivers have to be a service? Well, it they can still be a valid
> OSGi
> > > service, registered using any other way! OSGi aware driver manager uses
> > > OSGi services instead of static list own classloader to fi

Re: SPI Module - OSGi Bundle

[Niclas Hedhman]

Both approaches are independent of OSGi framework implementations, which is
part of the beauty of OSGi.

Lukasz puts more value on some dogmatic principle ("only interfaces in
API"), whereas I have forwarded how an OSGi bundle producer is expected to
provide it, and how an OSGi bundle consumer would expect to see it and the
added benefit that default behavior can be overridden. Lukasz uses my own
work-around (for JDBC drivers) to show me that is the way things are done.
It is not, it was a necessary hack for that time to get around the legacy
JDBC drivers out in the open, all of them without OSGi manifests.

As I said, I have no skin in the game. Only providing independent advice,
as a former OSGi expert and a keen interest in PLC4X.

// Niclas


On Thu, May 7, 2020 at 9:13 PM Christofer Dutz 
wrote:

> Hi folks,
>
> so if there is an option that doesn't tie our API and Drivers to a
> specific OSGi framework, I would prefer that.
>
> Chris
>
> Am 07.05.20, 12:35 schrieb "Julian Feinauer" <
> j.feina...@pragmaticminds.de>:
>
> I would say that there are arguments for both cases (as ist often with
> OSGi, IMHO).
> So I see them not as right or wrong but as to different styles or
> approaches that I woudl leave up to you to decide.
>
> IMHO
> Julian
>
> Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43...@etu.he2b.be>:
>
> Hi guys,
> As I am really not an expert, which approach should we use?
>
> Etienne
>
> Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki 
> a écrit :
>
> > Hey Niclas,
> > While this code seems straight I don't think it is needed, and
> valid in
> > our case.
> > Main benefit of extender and extender based patterns is
> centralized
> > processing of drivers.
> > I am keen to keep only interfaces in the API packages and
> bundles and
> > move active parts of code (such base classes) to another place.
> It is
> > necessary to avoid creation of implementation dependency. And
> that's
> > what is in fact, promoted by shared activator class.
> >
> > Best,
> > Łukasz
> >
> >
> > On 06.05.2020 13:47, Niclas Hedhman wrote:
> > > My suggestion was;
> > > 1. Don't do the BundleTracker classes, and instead change to a
> bundle
> > > activator for each.
> > > 2. Add the "Bundle-Activator:
> org.apache.plc4x.java.osgi.DriverActivator"
> > > to the driver META/MANIFEST.MF
> > > 3. Do the equivalent for the Transports.
> > >
> > > public class DriverActivator implements BundleActivator {
> > >
> > > private ServiceRegistration reg;
> > >
> > > @Override
> > > public void start( BundleContext context ) throws
> Exception {
> > > Hashtable props = new Hashtable<>();
> > > props.put( OsgiDriverManager.PROTOCOL_CODE,
> > driver.getProtocolCode() );
> > > props.put( OsgiDriverManager.PROTOCOL_NAME,
> > driver.getProtocolName() );
> > > reg = context.registerService( PlcDriver.class,
> driver, props );
> > > }
> > >
> > > @Override
> > > public void stop( BundleContext context ) {
> > > context.unregisterService( reg );
> > > }
> > > }
>     > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, May 6, 2020 at 2:33 PM Etienne Robinet <
> erobi...@apache.org>
> > wrote:
> > >
> > >> Hi all,
> > >> So concretely what changes should be done so that a
> Driver/Transport
> > >> declares itself his service? Beside the changes in the
> manifest?
> > >> Etienne
> > >> On 2020/05/06 01:26:42, Niclas Hedhman 
> wrote:
> > >>> Łukasz,
> > >>>
> > >>> the reason I say it is not very OSGi-y, is that the
> principle of OSGi
> > is
> > >>> that the bundle handles its own service registrations. In
> the case of
> > >> JDBC
> > >&g

Re: SPI Module - OSGi Bundle

[Niclas Hedhman]

As mentioned elsewhere, the generic activators could go in a separate
bundle for OSGi use only. That applies to both this approach and Lukasz'
one.

// Niclas

On Fri, May 8, 2020 at 2:08 PM Christofer Dutz 
wrote:

> Hi Niclas,
>
> If your suggested path doesn't limit the framework decisions a user has,
> then I have no objections.
>
> Indiens I am not that deep into osgi to have a well founded opinion.
>
> The api will probably never be a pure api module as it contains the driver
> manager, which I wouldn't want to put into a separate module.
>
> Chris
> ________
> Von: Niclas Hedhman 
> Gesendet: Freitag, 8. Mai 2020 05:12
> An: dev@plc4x.apache.org 
> Betreff: Re: SPI Module - OSGi Bundle
>
> Both approaches are independent of OSGi framework implementations, which is
> part of the beauty of OSGi.
>
> Lukasz puts more value on some dogmatic principle ("only interfaces in
> API"), whereas I have forwarded how an OSGi bundle producer is expected to
> provide it, and how an OSGi bundle consumer would expect to see it and the
> added benefit that default behavior can be overridden. Lukasz uses my own
> work-around (for JDBC drivers) to show me that is the way things are done.
> It is not, it was a necessary hack for that time to get around the legacy
> JDBC drivers out in the open, all of them without OSGi manifests.
>
> As I said, I have no skin in the game. Only providing independent advice,
> as a former OSGi expert and a keen interest in PLC4X.
>
> // Niclas
>
>
> On Thu, May 7, 2020 at 9:13 PM Christofer Dutz 
> wrote:
>
> > Hi folks,
> >
> > so if there is an option that doesn't tie our API and Drivers to a
> > specific OSGi framework, I would prefer that.
> >
> > Chris
> >
> > Am 07.05.20, 12:35 schrieb "Julian Feinauer" <
> > j.feina...@pragmaticminds.de>:
> >
> > I would say that there are arguments for both cases (as ist often
> with
> > OSGi, IMHO).
> > So I see them not as right or wrong but as to different styles or
> > approaches that I woudl leave up to you to decide.
> >
> > IMHO
> > Julian
> >
> > Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43...@etu.he2b.be>:
> >
> > Hi guys,
> > As I am really not an expert, which approach should we use?
> >
> > Etienne
> >
> > Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki 
> > a écrit :
> >
> > > Hey Niclas,
> > > While this code seems straight I don't think it is needed, and
> > valid in
> > > our case.
> > > Main benefit of extender and extender based patterns is
> > centralized
> > > processing of drivers.
> > > I am keen to keep only interfaces in the API packages and
> > bundles and
> > > move active parts of code (such base classes) to another place.
> > It is
> > > necessary to avoid creation of implementation dependency. And
> > that's
> > > what is in fact, promoted by shared activator class.
> > >
> > > Best,
> > > Łukasz
> > >
> > >
> > > On 06.05.2020 13:47, Niclas Hedhman wrote:
> > > > My suggestion was;
> > > > 1. Don't do the BundleTracker classes, and instead change to
> a
> > bundle
> > > > activator for each.
> > > > 2. Add the "Bundle-Activator:
> > org.apache.plc4x.java.osgi.DriverActivator"
> > > > to the driver META/MANIFEST.MF
> > > > 3. Do the equivalent for the Transports.
> > > >
> > > > public class DriverActivator implements BundleActivator {
> > > >
> > > > private ServiceRegistration reg;
> > > >
> > > > @Override
> > > > public void start( BundleContext context ) throws
> > Exception {
> > > > Hashtable props = new Hashtable<>();
> > > > props.put( OsgiDriverManager.PROTOCOL_CODE,
> > > driver.getProtocolCode() );
> > > > props.put( OsgiDriverManager.PROTOCOL_NAME,
> > > driver.getProtocolName() );
> > > > reg = context.registerService( PlcDriver.class,
> > driver, props );
> > > > }
> > > >
> > > > @Override
> >  

Re: SPI Module - OSGi Bundle

[Niclas Hedhman]

Yes, that is what I suggest

On Fri, May 8, 2020, 16:19 Robinet, Etienne <43...@etu.he2b.be> wrote:

> Hello,
> so if I understand correctly, I should create a new module for the OSGi
> bundle, containing generic Activators that would be mentioned in the
> Driver/Transport MANIFEST?
> Etienne
>
> Le ven. 8 mai 2020 à 09:55, Niclas Hedhman  a écrit :
>
> > As mentioned elsewhere, the generic activators could go in a separate
> > bundle for OSGi use only. That applies to both this approach and Lukasz'
> > one.
> >
> > // Niclas
> >
> > On Fri, May 8, 2020 at 2:08 PM Christofer Dutz <
> christofer.d...@c-ware.de>
> > wrote:
> >
> > > Hi Niclas,
> > >
> > > If your suggested path doesn't limit the framework decisions a user
> has,
> > > then I have no objections.
> > >
> > > Indiens I am not that deep into osgi to have a well founded opinion.
> > >
> > > The api will probably never be a pure api module as it contains the
> > driver
> > > manager, which I wouldn't want to put into a separate module.
> > >
> > > Chris
> > > 
> > > Von: Niclas Hedhman 
> > > Gesendet: Freitag, 8. Mai 2020 05:12
> > > An: dev@plc4x.apache.org 
> > > Betreff: Re: SPI Module - OSGi Bundle
> > >
> > > Both approaches are independent of OSGi framework implementations,
> which
> > is
> > > part of the beauty of OSGi.
> > >
> > > Lukasz puts more value on some dogmatic principle ("only interfaces in
> > > API"), whereas I have forwarded how an OSGi bundle producer is expected
> > to
> > > provide it, and how an OSGi bundle consumer would expect to see it and
> > the
> > > added benefit that default behavior can be overridden. Lukasz uses my
> own
> > > work-around (for JDBC drivers) to show me that is the way things are
> > done.
> > > It is not, it was a necessary hack for that time to get around the
> legacy
> > > JDBC drivers out in the open, all of them without OSGi manifests.
> > >
> > > As I said, I have no skin in the game. Only providing independent
> advice,
> > > as a former OSGi expert and a keen interest in PLC4X.
> > >
> > > // Niclas
> > >
> > >
> > > On Thu, May 7, 2020 at 9:13 PM Christofer Dutz <
> > christofer.d...@c-ware.de>
> > > wrote:
> > >
> > > > Hi folks,
> > > >
> > > > so if there is an option that doesn't tie our API and Drivers to a
> > > > specific OSGi framework, I would prefer that.
> > > >
> > > > Chris
> > > >
> > > > Am 07.05.20, 12:35 schrieb "Julian Feinauer" <
> > > > j.feina...@pragmaticminds.de>:
> > > >
> > > > I would say that there are arguments for both cases (as ist often
> > > with
> > > > OSGi, IMHO).
> > > > So I see them not as right or wrong but as to different styles or
> > > > approaches that I woudl leave up to you to decide.
> > > >
> > > > IMHO
> > > > Julian
> > > >
> > > > Am 07.05.20, 10:07 schrieb "Robinet, Etienne" <43...@etu.he2b.be
> >:
> > > >
> > > > Hi guys,
> > > > As I am really not an expert, which approach should we use?
> > > >
> > > > Etienne
> > > >
> > > > Le mer. 6 mai 2020 à 15:57, Łukasz Dywicki <
> > l...@code-house.org>
> > > > a écrit :
> > > >
> > > > > Hey Niclas,
> > > > > While this code seems straight I don't think it is needed,
> > and
> > > > valid in
> > > > > our case.
> > > > > Main benefit of extender and extender based patterns is
> > > > centralized
> > > > > processing of drivers.
> > > > > I am keen to keep only interfaces in the API packages and
> > > > bundles and
> > > > > move active parts of code (such base classes) to another
> > place.
> > > > It is
> > > > > necessary to avoid creation of implementation dependency.
> And
> > > > that's
> > > > > what is in fact, promoted by shared activator class.
> > > > >
> > > > > Best,
> > > > 

Cost of Exceptions [was: chrisdutz commented on a change in pull request #192: Refactor Field Handler Classes]

[Niclas Hedhman]

On Tue, Oct 6, 2020 at 9:33 AM GitBox  wrote:

>One thing I've learnt recently, is that exceptions are extremely
> expensive, as creating the stack trace is expensive. is this code that is
> likely to produce any of "InstantiationException | IllegalAccessException |
> InvocationTargetException | NoSuchMethodException" in normal execution? If
> yes, we should probably change this and other parts where we use similar
> patterns to check first instead of silently catching exceptions.
>

Chris is right; Exceptions are incredibly expensive and I have seen
instances where a few PLCs are put offline, and the supervisory system goes
into a snail pace, either due to excessive exceptions, aggressive retries
(without back-off), or both and sometimes with other "oh, didn't think of
that" ooopsies.

In general, all faults in "real world" should not throw exceptions, and
should be viewed as "normality". And unfortunately, Java programmers (even
those in this field) tend to not think in "error scenarios" and only in
"sunny day paths".

Personally, I got over the "exception craze" about 20 years ago, and try to
be exception-free. A few tricks to get there;

1. Event driven systems doesn't need "return values", hence a lot less
exceptions. Error conditions are different events and subscribers can
specialize in the handling. Making a system event driven instead of  the
request/response type, takes a fair amount of unlearning and mind bending,
but worth it.

2. Try to figure out ahead of time if exceptions may be thrown by code I
don't control.

3. Don't create nor rethrow exceptions. If in dev/test mode, log an error
report containing all possible states that could affect the outcome and
then System.exit() as to indicate that there is a serious problem that
should not be ignored. In production, the error report is sent to
"operations" (containing info to forward to developers if needed) and tries
to recover.


// Niclas

Re: Serial port Connection

[Niclas Hedhman]

Ok, let's dissect this...

1. There are many devices connected to a serial ModBus port.

2. ModBus (and every other serial protocol I have dealt with) are not
"connection" oriented, but packets, most of the time very small. The
"connection" metaphor in PLC4X for non-TCP comms is actually quite poor.[1]

3. All serial protocols (that I worked with) have at least the destination
present in the protocol packet itself. When some of these serial protocols
were "wrapped" for modern TCP/IP communications, an ambiguity surfaced. And
in case of ModBus, the device address was simply defaulted to 1 (although I
think some gateways can handle many, and perhaps some TCP devices will map
out more than one ModbUs device, but I have no experience in that)


So, as things are right now, and if I didn't misunderstood something
(totally possible), is that one is required to "open->->close" the
PLC4X connection for each device that I want to scan/read, as I think the
device address (1 byte in case of ModBus) is part of the connection string.
The biggest system I have ever been involved with was just under 1000 PLCs
(granted, not modbus) with 30,000 data points readable in total. It feels
"s wrong" to have "open->send->receive->close" operation for all of
those, AND that the timing on that particular system was that for optimal
performance, exactly 1 byte of delay (related to half-duplex modem
direction switching) between receiving the last byte of previous packet
before the first byte of the new packet. Without the "Serial Port"
abstraction, with a queue of requests to send, such timing is not trivial.

What I think has "gone wrong" here is that the "serial port" is an
interface, pretty much like "eth0" and should be handled "further down" but
since the operating system has no support for it, it should have been in
PLC4X's architecture. I also think that the "connection" metaphor is poor,
and a "packet" metaphor would have been much better throughout PLC4X
regardless whether it is TCP/IP, UDP or serial. The actual TCP connection
when needed should be handled under the hood, rather invisibly to the user.
As I said before, I understand that this is not something that can be
changed, just like that... Only expressing how I think it should have been
done.

I will try to work with what we have, and dig into the details on the
serial port side, as that's where I have plenty of experience and I get the
impression that it isn't the strength of the community. I am sure you will
hear a lot from me going forward, as I have decided to put PLC4X into my
commercial product, replacing the existing j2mod.


Niclas

[1] It is quite funny that the serial port is natively a stream, and we map
packets onto it. TCP/IP is natively packets, which is then made into a
stream, which we then map packets onto the stream. Ideally, UDP is fit for
purpose for PLC protocols, but for some unknown reason few are.




On Mon, Jun 29, 2020 at 4:00 PM Christofer Dutz 
wrote:

> Hi all,
>
> sorry for joining in the party late ... but hopefully not too late.
>
> Regarding making the serial port part of the connection string ... I have
> to admit that right now I couldn't imagine how to not have it in there and
> not over-complicate things for the users. Yes, if you create a connection
> this will have exclusive handle to the port, but this is actually an
> important thing to have. In contrast to network devices that can handle
> multiple connections in parallel ... a serial port is ... well ... serial.
> Havin asynchronous access to one serial port from multiple areas in an
> application sound like a bad Idea.
>
> However you could always use the connection pool ... in this case the pool
> would have one connection open and could share this (serially) with
> multiple parts of an application. Here a part would request the connection,
> do its work and then give the connection back to the pool where another
> part of the application could use it. This way I think we have the ideal
> tradeoff between sharing a connection and not having to be concerned about
> breaking the serial operation of the serial-port communication.
>
> And yes: We could use some documentation on the connection pool ... and
> the scraper ;-/
>
> Perhaps I'll whip up a little documentation on the connection-pool as I
> just recently had to find out how to use it myself ;-)
>
> Chris
>
>
> Am 25.06.20, 11:41 schrieb "Julian Feinauer" <
> j.feina...@pragmaticminds.de>:
>
> Hey,
>
> yes, its in the module scraper or plc-scraper.
> Its easily configurable by yaml, json or programmatically.
>
> Julian
>
> Am 25.06.20, 10:30 schrieb "Niclas Hedhman" :
>
> Thanks
>

Re: Serial port Connection

[Niclas Hedhman]

On Tue, Jun 30, 2020 at 2:31 PM Christofer Dutz 
wrote:

> But can we assume that only one protocol is handled over one serial
> interface? So not multiple Modbus devices sharing with multiple S5 devices
> ...
>

So, I have never seen anyone trying multiple protocols on the same port, so
that is a safe assumption. Even if I think there are devices that can
auto-sense Modbus and Bacnet, I doubt anyone will ever want to do both.



> Because in this case I guess we could refactor things a bit.
>

And I totally agree that as little changes as possible should be attempted,
so I won't suggest a rewrite, don't worry ;-)

Perhaps to have an optional device-address on the connection level which
> will act as a default and to extend or provide a second set of addresses,
> that have the device-address within. So you could either use the
> device-address together with the smaller field addresses (Mainly for TCP
> connections) and these would inherit the default device-address or you
> could use the bigger ones where you provide the device-address for every
> field.
>

Not sure what you mean here. ModBus/RTU has a one byte Address and a
Checksum, and those are dropped in Modbus/TCP and that relies on the
delivery/checksum of TCP/IP.


> I wouldn’t want to change the naming however ... you could consider in an
> extended serial modbus scenario (If we changed the serial part the way you
> proposed), that the connection is from the software to the port ...Which
> would be true. And most of the other drivers in PLC4X actually do more have
> a Connection-oriented communication form. I guess this is due to the fact
> that we concentrated on the SCADA-Level protocols first and now are
> gradually stepping deeper into the fieldbus area.
> I think only the EIP protocol is also somewhat connection-less, but S7,
> OPC UA, AMS/ADS, ... definitely are.
>

Interesting. I have very little experience "higher up" and perhaps there
are enough reasons to make abstractions different for stateless (or packet)
protocol vs those that are stateful. The compromise now is that stateless
pretends to be stateful, and a cycle of "open->close" takes place, very
much similar to HTTP/1.0 being stateless over the stateful TCP. I am not
100% confident what is the best way forward, so I'll come back to that
later. I think in the short term, I can survive because my current need is
very small (reading 5-10 values from each of 3-5 devices) and it is
hourly-relevant data.
In the process, I will try to formulate ideas for changes...

I know that serial comms are slowly dying out, but the amount of stuff
already out there and lifespans of decades, it will take a while before it
is all gone.

// Niclas

Re: [jira] [Created] (PLC4X-214) [Modbus] Holding register addresses have an offset of 1 (Not reading the correct address)

[Niclas Hedhman]

What is ModbusPAL?

The 1-offset in Modbus has caused a lot of confusion over the years.

On Tue, Jul 14, 2020 at 11:03 PM Christofer Dutz 
wrote:

> Sorry for the noise ...
>
> this was a false positive ... the driver was doing things correctly.
> It seems the ModbusPAL was just off by one ;-)
>
> Chris
>
>
>
> Am 14.07.20, 15:51 schrieb "Christofer Dutz (Jira)" :
>
> Christofer Dutz created PLC4X-214:
> -
>
>  Summary: [Modbus] Holding register addresses have an
> offset of 1 (Not reading the correct address)
>  Key: PLC4X-214
>  URL: https://issues.apache.org/jira/browse/PLC4X-214
>  Project: Apache PLC4X
>   Issue Type: Bug
>   Components: Driver-Modbus
> Affects Versions: 0.7.0
> Reporter: Christofer Dutz
> Assignee: Christofer Dutz
>  Fix For: 0.8.0
>
>
> If I set holding the following holding registers to:
>
> 1000: 41
> 1001: 42
> 1002: 43
>
> And then read: holding-register:1001 ... I get the value 43 returned.
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.3.4#803005)
>
>

Re: [jira] [Created] (PLC4X-214) [Modbus] Holding register addresses have an offset of 1 (Not reading the correct address)

[Niclas Hedhman]

The issue with 1-offset is that the "Register Number" found in
documentation is at an "Address" one position less. So Reg 41 has Address
40. Som libraries expect Register Numbers and some expect Register Address.
And every so often, one mixes that up.

On Wed, Jul 15, 2020 at 2:53 PM Christofer Dutz 
wrote:

> 
>
> While looking for more Infos I found out I once wrote a tutorial page for
> PLC4X __
>
> https://plc4x.apache.org/users/plc4j/virtual-modbus.html
>
> I so totally hate searching the web and getting my answers answered by
> myself.
>
> Chris
>
> Am 15.07.20, 08:31 schrieb "Christofer Dutz" :
>
> Hi Niclas,
>
> when preparing a workshop for the Building IoT we were looking for
> something where you could simulate a Modbus Slave.
> Most of these were Windows only solutions, so ModbusPAL was one of the
> very few solutions that were pure-java.
>
> Don't quite understand what the thing with the offset is however ...
> should be easy to fix ... I mean if I say address 42 in PLC4X, Wireshark
> says 42, but in Modbus Pal I think it has to be 43 ... don't quite get it.
>
> Chris
>
>
>
> Am 15.07.20, 03:54 schrieb "Niclas Hedhman" :
>
> What is ModbusPAL?
>
> The 1-offset in Modbus has caused a lot of confusion over the
> years.
>
> On Tue, Jul 14, 2020 at 11:03 PM Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > Sorry for the noise ...
> >
> > this was a false positive ... the driver was doing things
> correctly.
> > It seems the ModbusPAL was just off by one ;-)
> >
> > Chris
> >
> >
> >
> > Am 14.07.20, 15:51 schrieb "Christofer Dutz (Jira)" <
> j...@apache.org>:
> >
> > Christofer Dutz created PLC4X-214:
> > -
> >
> >  Summary: [Modbus] Holding register addresses
> have an
> > offset of 1 (Not reading the correct address)
> >  Key: PLC4X-214
> >  URL:
> https://issues.apache.org/jira/browse/PLC4X-214
> >  Project: Apache PLC4X
> >   Issue Type: Bug
> >   Components: Driver-Modbus
> > Affects Versions: 0.7.0
> > Reporter: Christofer Dutz
> > Assignee: Christofer Dutz
> >  Fix For: 0.8.0
> >
> >
> > If I set holding the following holding registers to:
> >
> > 1000: 41
> > 1001: 42
> > 1002: 43
> >
> > And then read: holding-register:1001 ... I get the value 43
> returned.
> >
> >
> >
> > --
> > This message was sent by Atlassian Jira
> > (v8.3.4#803005)
> >
> >
>
>
>

Re: [jira] [Created] (PLC4X-214) [Modbus] Holding register addresses have an offset of 1 (Not reading the correct address)

[Niclas Hedhman]

Personall, I prefer that Register Numbers are used in APIs and that the
address is only seen if you analyze the over-the-wire format, but maybe
that is just me. A big reason for this is that any interface presented to
an operator would need to use RegNumbers, as most (possibly all)
documentation of equipment has RegNumbers and some are lacking the
addresses. It is also common that the register type is part of the Register
Number, such as 10012, where the first 1 indicates "coil" (IIRC). and
holding registers are in 4. Ideally(!), this is also handled by the
register/address parser.

Niclas

On Wed, Jul 15, 2020 at 5:43 PM Christofer Dutz 
wrote:

> Hmm .. so are we doing it correctly?
>
> I mean Wireshark isn't the ideal reference here as I have several valid
> packets in the KNX space, where WireShark just says "corrupt package".
>
> So if you enter an "holding-register:42" address it tries to read the
> register number 43 in ModbusPAL.
>
> I guess as we are reading an "address" we are correct and probably as
> ModusPAL says register number, that might be correct too?
>
> Chris
>
>
> Am 15.07.20, 10:54 schrieb "Niclas Hedhman" :
>
> The issue with 1-offset is that the "Register Number" found in
> documentation is at an "Address" one position less. So Reg 41 has
> Address
> 40. Som libraries expect Register Numbers and some expect Register
> Address.
> And every so often, one mixes that up.
>
> On Wed, Jul 15, 2020 at 2:53 PM Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > 
> >
> > While looking for more Infos I found out I once wrote a tutorial
> page for
> > PLC4X __
> >
> > https://plc4x.apache.org/users/plc4j/virtual-modbus.html
> >
> > I so totally hate searching the web and getting my answers answered
> by
> > myself.
> >
> > Chris
> >
> > Am 15.07.20, 08:31 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
> >
> > Hi Niclas,
> >
> > when preparing a workshop for the Building IoT we were looking
> for
> > something where you could simulate a Modbus Slave.
> > Most of these were Windows only solutions, so ModbusPAL was one
> of the
> > very few solutions that were pure-java.
> >
> > Don't quite understand what the thing with the offset is however
> ...
> > should be easy to fix ... I mean if I say address 42 in PLC4X,
> Wireshark
> > says 42, but in Modbus Pal I think it has to be 43 ... don't quite
> get it.
> >
> > Chris
> >
> >
> >
> > Am 15.07.20, 03:54 schrieb "Niclas Hedhman"  >:
> >
> > What is ModbusPAL?
> >
> > The 1-offset in Modbus has caused a lot of confusion over the
> > years.
> >
> > On Tue, Jul 14, 2020 at 11:03 PM Christofer Dutz <
> > christofer.d...@c-ware.de>
> > wrote:
> >
> > > Sorry for the noise ...
> > >
> > > this was a false positive ... the driver was doing things
> > correctly.
> > > It seems the ModbusPAL was just off by one ;-)
> > >
> > > Chris
> > >
> > >
> > >
> > > Am 14.07.20, 15:51 schrieb "Christofer Dutz (Jira)" <
> > j...@apache.org>:
> > >
> > > Christofer Dutz created PLC4X-214:
> > > -
> > >
> > >  Summary: [Modbus] Holding register
> addresses
> > have an
> > > offset of 1 (Not reading the correct address)
> > >  Key: PLC4X-214
> > >  URL:
> > https://issues.apache.org/jira/browse/PLC4X-214
> > >  Project: Apache PLC4X
> > >   Issue Type: Bug
> > >   Components: Driver-Modbus
> > > Affects Versions: 0.7.0
> > > Reporter: Christofer Dutz
> > > Assignee: Christofer Dutz
> > >  Fix For: 0.8.0
> > >
> > >
> > > If I set holding the following holding registers to:
> > >
> > > 1000: 41
> > > 1001: 42
> > > 1002: 43
> > >
> > > And then read: holding-register:1001 ... I get the
> value 43
> > returned.
> > >
> > >
> > >
> > > --
> > > This message was sent by Atlassian Jira
> > > (v8.3.4#803005)
> > >
> > >
> >
> >
> >
>
>

Re: [jira] [Created] (PLC4X-214) [Modbus] Holding register addresses have an offset of 1 (Not reading the correct address)

[Niclas Hedhman]

It is a common format in equipment documentation. I am currently working
with an electric meter. See screenshot from its manual;
https://ipfs.subutai.io/ipfs/QmPsra6ExrkSX9GCYWgHa6CTfJbBnddLVXJ3NmJjmAYrAk

At protocol level, there are no such "high numbers", just that the industry
got used to write "4" instead "holding register". It is a "people thing",
not a technical one.

HTH
Niclas

On Wed, Jul 15, 2020 at 6:11 PM Christofer Dutz 
wrote:

> Hmmm ...
>
> Regarding: 10012 being a coil and 4 a register.
>
> Well the coils and registers are completely different things ... They are
> accessed via completely different requests.
> That might be some sort of convenience convention, but I wouldn't call
> that a standard (I've actually never seen it before)
> Would you then just subtract 4 from every register or would you just
> configure registers starting with numbers 4?
>
> What do the others think? The address format does reference registers ...
> should we be doing the translation?
>
> I guess that the general use-case would be that someone has a look at his
> Modbus config and says that he wants "Register X"
> and not "The Register Y references" (which seems to be one less) ... I
> might even swing my vote in favor to using register numbers instead of
> addresses.
>
> But then I ask myself: How can I address register 0 in ModbusPal ... that
> would require an address that's impossible to send.
>
> Chris
>
>
> Am 15.07.20, 11:51 schrieb "Niclas Hedhman" :
>
> Personall, I prefer that Register Numbers are used in APIs and that the
> address is only seen if you analyze the over-the-wire format, but maybe
> that is just me. A big reason for this is that any interface presented
> to
> an operator would need to use RegNumbers, as most (possibly all)
> documentation of equipment has RegNumbers and some are lacking the
> addresses. It is also common that the register type is part of the
> Register
> Number, such as 10012, where the first 1 indicates "coil" (IIRC). and
> holding registers are in 4. Ideally(!), this is also handled by the
> register/address parser.
>
> Niclas
>
> On Wed, Jul 15, 2020 at 5:43 PM Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > Hmm .. so are we doing it correctly?
> >
> > I mean Wireshark isn't the ideal reference here as I have several
> valid
> > packets in the KNX space, where WireShark just says "corrupt
> package".
> >
> > So if you enter an "holding-register:42" address it tries to read the
> > register number 43 in ModbusPAL.
> >
> > I guess as we are reading an "address" we are correct and probably as
> > ModusPAL says register number, that might be correct too?
> >
> > Chris
> >
> >
> > Am 15.07.20, 10:54 schrieb "Niclas Hedhman" :
> >
> > The issue with 1-offset is that the "Register Number" found in
> > documentation is at an "Address" one position less. So Reg 41 has
> > Address
> > 40. Som libraries expect Register Numbers and some expect
> Register
> > Address.
> > And every so often, one mixes that up.
> >
> > On Wed, Jul 15, 2020 at 2:53 PM Christofer Dutz <
> > christofer.d...@c-ware.de>
> > wrote:
> >
> > > 
> > >
> > > While looking for more Infos I found out I once wrote a
> tutorial
> > page for
> > > PLC4X __
> > >
> > > https://plc4x.apache.org/users/plc4j/virtual-modbus.html
> > >
> > > I so totally hate searching the web and getting my answers
> answered
> > by
> > > myself.
> > >
> > > Chris
> > >
> > > Am 15.07.20, 08:31 schrieb "Christofer Dutz" <
> > christofer.d...@c-ware.de>:
> > >
> > > Hi Niclas,
> > >
> > > when preparing a workshop for the Building IoT we were
> looking
> > for
> > > something where you could simulate a Modbus Slave.
> > > Most of these were Windows only solutions, so ModbusPAL
> was one
> > of the
> > > very few solutions that were pure-java.
> > >
> > > Don't quite understand what the th

Re: [jira] [Created] (PLC4X-214) [Modbus] Holding register addresses have an offset of 1 (Not reading the correct address)

[Niclas Hedhman]

Let me try again; There is no 3 addresses in the products. It is a
notation written with text, by people. the first written digit convey the
type. That's it.

Long time ago, back when the Modbus came to life it was simply a memory
area that one could read and possibly write. And then documentation
specified what was in each bit/byte/word. And with such approach, it is
probably possible to implement Modbus in less than 100 bytes of very
expensive (E)PROM back then. Not until later was there address validity
checks and what not.

FTR; It is completely beyond me how Modbus became as popular as it has, and
that this happened decades after it was introduced on the market. When I
was part of a startup and we were developing a serial protocol in
1984/1985, we knew of Modbus and thought it was a really poor protocol
(couldn't even do floating point numbers). I don't like it, but just about
every electric thing can be purchased with Modbus option...

Cheers
Niclas

On Wed, Jul 15, 2020 at 9:39 PM Christofer Dutz 
wrote:

> Hi Niclas,
>
> Protocol-wise the numbers could be up to 65535 as they use an unsigned 16
> bit integer as an address.
>
> I guess what would be interesting, would be what address is going over the
> wire for "30001" for example.
> Also as a register is always a 16 bit value, the increments by two sort of
> puzzle me.
>
> I think Modbus is an extremely simple protocol but we need to get a
> feeling for it's usages.
>
> It does seem as if the industry tends to wrap some aspects in software
> bubble-wrap ... we gotta find out what's below.
>
> Chris
>
>
> Am 15.07.20, 15:23 schrieb "Niclas Hedhman" :
>
> It is a common format in equipment documentation. I am currently
> working
> with an electric meter. See screenshot from its manual;
>
> https://ipfs.subutai.io/ipfs/QmPsra6ExrkSX9GCYWgHa6CTfJbBnddLVXJ3NmJjmAYrAk
>
> At protocol level, there are no such "high numbers", just that the
> industry
> got used to write "4" instead "holding register". It is a "people
> thing",
> not a technical one.
>
> HTH
> Niclas
>
> On Wed, Jul 15, 2020 at 6:11 PM Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > Hmmm ...
> >
> > Regarding: 10012 being a coil and 4 a register.
> >
> > Well the coils and registers are completely different things ...
> They are
> > accessed via completely different requests.
> > That might be some sort of convenience convention, but I wouldn't
> call
> > that a standard (I've actually never seen it before)
> > Would you then just subtract 4 from every register or would you
> just
> > configure registers starting with numbers 4?
> >
> > What do the others think? The address format does reference
> registers ...
> > should we be doing the translation?
> >
> > I guess that the general use-case would be that someone has a look
> at his
> > Modbus config and says that he wants "Register X"
> > and not "The Register Y references" (which seems to be one less) ...
> I
>     > might even swing my vote in favor to using register numbers instead
> of
> > addresses.
> >
> > But then I ask myself: How can I address register 0 in ModbusPal ...
> that
> > would require an address that's impossible to send.
> >
> > Chris
> >
> >
> > Am 15.07.20, 11:51 schrieb "Niclas Hedhman" :
> >
> > Personall, I prefer that Register Numbers are used in APIs and
> that the
> > address is only seen if you analyze the over-the-wire format,
> but maybe
> > that is just me. A big reason for this is that any interface
> presented
> > to
> > an operator would need to use RegNumbers, as most (possibly all)
> > documentation of equipment has RegNumbers and some are lacking
> the
> > addresses. It is also common that the register type is part of
> the
> > Register
> > Number, such as 10012, where the first 1 indicates "coil"
> (IIRC). and
> > holding registers are in 4. Ideally(!), this is also handled
> by the
> > register/address parser.
> >
> > Niclas
> >
> > On Wed, Jul 15, 2020 at 5:43 PM Christofer Dutz <
> > christofer.d...@c-ware.de>
> > wrote:
> >
> > > Hmm .. so are we doing it correctly?
> > >
> > > I mean Wireshark isn't t

Serial port Connection

[Niclas Hedhman]

Hi,
IIUIC, the connection string for Serial Modbus would be something like;

 modbus:serial:/dev/ttyS0?unit-identifier=7

assuming I want to communicate with device with address 7.

That would mean that I have one connection per device I talk to over a
single serial port. Is that correct? (Personally, I would not made the
device part of the connection abstraction, but realize that it is a bit
late for that)

Are there any issues here, regarding which connection has access to the
port, or do I need to open and close the connection on each set of messages?

Couldn't find info about this in the documentation.


The serial port page is missing information on the configuration (data,
parity, stop,...). The source code doesn't have the @ConfigurationParameter
annotations, so will they still work or do I need to add that
programmatically somehow?


Cheers
Niclas

Re: Serial port Connection

[Niclas Hedhman]

Thanks

Another question; is there any "loop" system that just continuously reads
until I tell it to stop?

On Thu, Jun 25, 2020, 15:16 Julian Feinauer 
wrote:

> Hi Nic,
>
> I have to dig in a bit later to give you good answers but AFAIR the
> connection can be left open and configuration should be as you wrote it.
> I also did some tests with it but that was some months ago...
>
> Hope to have some more information later.
>
> Julian
>
> Am 25.06.20, 05:58 schrieb "Niclas Hedhman" :
>
> Hi,
> IIUIC, the connection string for Serial Modbus would be something like;
>
>  modbus:serial:/dev/ttyS0?unit-identifier=7
>
> assuming I want to communicate with device with address 7.
>
> That would mean that I have one connection per device I talk to over a
> single serial port. Is that correct? (Personally, I would not made the
> device part of the connection abstraction, but realize that it is a bit
> late for that)
>
> Are there any issues here, regarding which connection has access to the
> port, or do I need to open and close the connection on each set of
> messages?
>
> Couldn't find info about this in the documentation.
>
>
> The serial port page is missing information on the configuration (data,
> parity, stop,...). The source code doesn't have the
> @ConfigurationParameter
> annotations, so will they still work or do I need to add that
> programmatically somehow?
>
>
> Cheers
> Niclas
>
>

Re: [jira] [Created] (PLC4X-214) [Modbus] Holding register addresses have an offset of 1 (Not reading the correct address)

[Niclas Hedhman]

To make things worse, there is equipment on the market with both 32-bit
numbers as well IEEE floats.

And many clients are incapable of doing something meaningful with those...


And then there is equipment that uses one register to indicate the
magnitude of one or more other registers, say 1="divide by 1", 2="divide by
10"...



Niclas

On Thu, Jul 16, 2020, 14:28 Christofer Dutz 
wrote:

> Hi Ben and Otto,
>
> First off all, thank you Ben for that very detailed explanation. It does
> seem as if we should extend the parser to support the different numeric
> variants. I don't see any problems in supporting both the hex-like one as
> well as the pure numeric one.
>
> I think we have 6 separate memory areas. Do you have a mapping, That I
> could use? I mean which first digit represents which memory area?
>
> @otto Modbus doesn't allow floats. Just bits (coils) and shorts
> (registers)... Haven't seen a somewhat standard way to encode anything else.
>
> Chris
> 
> Von: Otto Fowler 
> Gesendet: Donnerstag, 16. Juli 2020 06:41
> An: dev@plc4x.apache.org 
> Betreff: Re: [jira] [Created] (PLC4X-214) [Modbus] Holding register
> addresses have an offset of 1 (Not reading the correct address)
>
> Don’t forget embedded protocols are possible,
> different devices format floats differently
> some devices don’t want persistent connections
> etc etc
>
> On July 15, 2020 at 20:48:39, Ben Hutcheson (ben.hut...@gmail.com) wrote:
>
> Hi,
>
> Answering some of the questions:-
> *I guess what would be interesting, would be what address is going over the
> wire for "30001" for example.*
> The address that gets sent over the wire is the address starting from 0 i.e
> 31 would be address 0. I didn't know that.
>
> *Also as a register is always a 16 bit value, the increments by two sort of
> puzzle me.*
> The Modbus registers are numbered 31 thru to 365536 (or whatever the
> highest is for the device), they are 16 bit registers they don't increment
> by 2. If you were mapping 32-bit data types to the registers then of course
> you would increment by two but I don't know of any other situation or
> device that increments the addresses by 2.
>
>
> *Long time ago, back when the Modbus came to life it was simply a
> memory area*
> I do vaguely remember working on a device that didn't differentiate between
> the memory areas and would just use the address when reading and writing,
> the leading digit would just specify data type. 01 would be a bit in
> 41.
>
>
> *so would you suggest we leave things the way they are or should we change
> something?*
> I would, it is the most commonly used. I think I have also seen the format
> 0x1, 4x1 being used but is less common.
>
> *I guess we might think about adding different address parser flavors in
> the future. So we could use the current one per default, but we could add a
> Schneider Field parser that helps convert %MW1 to our
> holding-register:401 ... or whatever the scematics are.*
> You would want to be careful doing this because a lot of the times the
> mapping between Modbus Registers and the internal addresses is
> configurable. Newer Schnieder PLCs I think have an option to start the
> numbering at %MW0 , Rockwell Micrologix PLCs have a configurable mapping
> table so you can select the data table the Modbus addresses get mapped to.
>
> Some other things that might not have come up,
> There is also an extended memory (Leading digit 6) area on some devices.
> Schneider Quantum controllers I know use this.
>
> There are a lot of devices that support Modbus, but the quality of some of
> the implementations can be very poor. I wouldn't be relying on some of the
> non-essential fields (Transaction Ids, Lengths) as they can sometimes not
> be populated.
>
> I also wouldn't assume that every device supports all the function codes.
> Some devices (Honeywell C200/C300) allow you to select which function codes
> you want to use for each device to try and work around this.
>
> For Modbus TCP, some servers won't allow more than a certain number of
> connections at any one time. Sometimes this number is 1. It can be very
> annoying to troubleshoot.
>
> Kind Regards
>
> Ben
>
>
>
>
>
> On Wed, Jul 15, 2020 at 9:53 AM Niclas Hedhman  wrote:
>
> > Let me try again; There is no 3 addresses in the products. It is a
> > notation written with text, by people. the first written digit convey the
> > type. That's it.
> >
> > Long time ago, back when the Modbus came to life it was simply a
> memory
> > area that one could read and possibly write. And then documentation
> > specifie

Re: [jira] [Created] (PLC4X-214) [Modbus] Holding register addresses have an offset of 1 (Not reading the correct address)

[Niclas Hedhman]

For floats, I have only seen IEEE format. But can't rule out other.

On Thu, Jul 16, 2020, 14:57 Christofer Dutz 
wrote:

> Guess it should be possible for plc4x to interpret INT as two shorts long
> as four... In that case it could probably also handle half precision floats
> (16 bit), full floats and double, if the encoding is somewhat standard
> (which I assume it's not)
>
> Chris
> ________
> Von: Niclas Hedhman 
> Gesendet: Donnerstag, 16. Juli 2020 08:33
> An: dev@plc4x.apache.org 
> Betreff: Re: [jira] [Created] (PLC4X-214) [Modbus] Holding register
> addresses have an offset of 1 (Not reading the correct address)
>
> To make things worse, there is equipment on the market with both 32-bit
> numbers as well IEEE floats.
>
> And many clients are incapable of doing something meaningful with those...
>
>
> And then there is equipment that uses one register to indicate the
> magnitude of one or more other registers, say 1="divide by 1", 2="divide by
> 10"...
>
>
>
> Niclas
>
> On Thu, Jul 16, 2020, 14:28 Christofer Dutz 
> wrote:
>
> > Hi Ben and Otto,
> >
> > First off all, thank you Ben for that very detailed explanation. It does
> > seem as if we should extend the parser to support the different numeric
> > variants. I don't see any problems in supporting both the hex-like one as
> > well as the pure numeric one.
> >
> > I think we have 6 separate memory areas. Do you have a mapping, That I
> > could use? I mean which first digit represents which memory area?
> >
> > @otto Modbus doesn't allow floats. Just bits (coils) and shorts
> > (registers)... Haven't seen a somewhat standard way to encode anything
> else.
> >
> > Chris
> > 
> > Von: Otto Fowler 
> > Gesendet: Donnerstag, 16. Juli 2020 06:41
> > An: dev@plc4x.apache.org 
> > Betreff: Re: [jira] [Created] (PLC4X-214) [Modbus] Holding register
> > addresses have an offset of 1 (Not reading the correct address)
> >
> > Don’t forget embedded protocols are possible,
> > different devices format floats differently
> > some devices don’t want persistent connections
> > etc etc
> >
> > On July 15, 2020 at 20:48:39, Ben Hutcheson (ben.hut...@gmail.com)
> wrote:
> >
> > Hi,
> >
> > Answering some of the questions:-
> > *I guess what would be interesting, would be what address is going over
> the
> > wire for "30001" for example.*
> > The address that gets sent over the wire is the address starting from 0
> i.e
> > 31 would be address 0. I didn't know that.
> >
> > *Also as a register is always a 16 bit value, the increments by two sort
> of
> > puzzle me.*
> > The Modbus registers are numbered 31 thru to 365536 (or whatever the
> > highest is for the device), they are 16 bit registers they don't
> increment
> > by 2. If you were mapping 32-bit data types to the registers then of
> course
> > you would increment by two but I don't know of any other situation or
> > device that increments the addresses by 2.
> >
> >
> > *Long time ago, back when the Modbus came to life it was simply a
> > memory area*
> > I do vaguely remember working on a device that didn't differentiate
> between
> > the memory areas and would just use the address when reading and writing,
> > the leading digit would just specify data type. 01 would be a bit in
> > 41.
> >
> >
> > *so would you suggest we leave things the way they are or should we
> change
> > something?*
> > I would, it is the most commonly used. I think I have also seen the
> format
> > 0x1, 4x1 being used but is less common.
> >
> > *I guess we might think about adding different address parser flavors in
> > the future. So we could use the current one per default, but we could
> add a
> > Schneider Field parser that helps convert %MW1 to our
> > holding-register:401 ... or whatever the scematics are.*
> > You would want to be careful doing this because a lot of the times the
> > mapping between Modbus Registers and the internal addresses is
> > configurable. Newer Schnieder PLCs I think have an option to start the
> > numbering at %MW0 , Rockwell Micrologix PLCs have a configurable mapping
> > table so you can select the data table the Modbus addresses get mapped
> to.
> >
> > Some other things that might not have come up,
> > There is also an extended memory (Leading digit 6) area on some devices.
> > Schneider Quantum controllers I know use this.
> >

Re: AW: [DRAFT] Borad Report

[Niclas Hedhman]

Perhaps I can give insight to how (at least) this Board member view reports;

1. Whether or not there is life in the project,
   a. that stuff happens on dev@ mailing list
   b. releases are progressing "normally" (can vary from quarterly to every
other year)

2. Ensure that there is no friction between individuals in the community.

3. Hear about initiatives that other communities can learn from (at
community level, not technical one). Could be meetups, reach-outs, some new
way to pull people in, or make them more active, and so on. Experiences
from programs like Google Summer of Code, participation in industry
organizations and the like, are also good to know.

4. Listing on-going work on particular components will be skipped by most
directors for most projects. Board never criticizes such information, as it
is an additional indicator that there is life in the project, and it can be
good for the project itself to get a "commit log", as the reports are a
permanent record of the ASF.

Cheers
Niclas



On Wed, Dec 2, 2020 at 2:05 PM Otto Fowler  wrote:

>  I would say “a lot of initiatives been worked on” instead of “done"
>
> From: Christofer Dutz 
> 
> Reply: dev@plc4x.apache.org  
> Date: December 2, 2020 at 06:09:09
> To: dev@plc4x.apache.org  
> Subject:  AW: [DRAFT] Borad Report
>
> Hey chris …
>
> And you missed the work on the CAN driver.
>
> ….
>
> Von: Christofer Dutz 
> Datum: Mittwoch, 2. Dezember 2020 um 11:12
> An: dev@plc4x.apache.org 
> Betreff: AW: [DRAFT] Borad Report
> Hey Chris …
>
> you missed mentioning our Community Calls (Which actually should be one
> today too)
>
> ;-)
>
> Von: Christofer Dutz 
> Datum: Mittwoch, 2. Dezember 2020 um 11:08
> An: dev@plc4x.apache.org 
> Betreff: [DRAFT] Borad Report
> Hi all,
>
> I just whipped up our board report … If I missed anything important, please
> mention this (Ideally just post what you would like added/changed/removed
> instead of changing it inline (I don’t want to miss anything).
>
> I hope I didn’t miss any features and initiatives … if I did, this wasn’t
> intentional. And if you had talks that weren’t mentioned, please tell me,
> so I can add them.
>
> By the way … was a pleasure writing this report as we are a really great
> team :-)
>
> Chris
>
>
>
>
> ## Description:
> The mission of the Apache PLC4X project is creating a set of libraries for
> communicating with industrial programmable logic controllers (PLCs) using a
> variety of protocols but with a shared API.
>
> ## Issues:
>
> There are no issues requiring board attention.
>
> ## Membership Data:
> Apache PLC4X was founded 2019-04-17 (2 years ago)
> There are currently 18 committers and 12 PMC members in this project.
> The Committer-to-PMC ratio is 3:2.
>
> Community changes, past quarter:
> - Ben Hutcheson was added to the PMC on 2020-11-08
> - Otto Fowler was added to the PMC on 2020-10-23
> - Stefano Bossi was added as committer on 2020-09-07
> - Ben Hutcheson was added as committer on 2020-09-26
>
> ## Project Activity:
>
> The project has invested a lot of time and effort into streamlining the
> Java
> version of our drivers, especially regarding shared datatypes. Also a lot
> was
> invested in testing and fixing issues reported by the community.
>
> While we did see quite some reduced community activity in the last
> reporting
> quarter, this time we can report a lot of initiatives have been done by the
> community:
>
> - PLC4Py
> - PLC4Go
> - OPC-UA Server
> - Refreshed Kafka Connect adapter
> - Updated Connection Pool
>
> A large group of the community is working on porting PLC4X to the language
> Python. We have added a first successful port of the KNX and Modbus drivers
> to
> Go and work has just begun porting things to C# and .Net.
>
> Promotion-Wise we have also tried to take advantage of what virtual meetups
> allow us and have participated in a number of virtual conferences and
> webinars. Some of us have reached out to some of the biggest IoT meetups
> and
> asked them if there was interest in a PLC4X talk.
>
> - ApacheCon@Home 2020 (4 Talks about or partly about PLC4X)
> - LIBRECON
> - HiveMQ Webinar
> - ...
>
> For December he have planned the following
>
> - "100 Orte virtuell erleben! beim FZI"
> - Eclipse IoT Meetup
> - Eclipse IoT Working Group presentation
> - ...
>
> Right now we're working hard on finishing some last work and are hoping to
> initiate the release of version 0.8.0 within the next week or so.
>
> ## Community Health:
>
> Right now we are very happy with the state of the community.
>
> - dev@plc4x.apache.org had a 17% decrease in traffic in the past quarter
> (424 emails compared to 505)
> - iss...@plc4x.apache.org had a 49% decrease in traffic in the past
> quarter
> (115 emails compared to 222)
> - 13 issues opened in JIRA, past quarter (-67% decrease)
> - 9 issues closed in JIRA, past quarter (-66% decrease)
> - 466 commits in the past quarter (63% increase)
> - 9 code contributors in the past quarter (-30% decrease)
> - 23 PRs 

Re: [DISCUSS] How about changing the way we act on "backward compatability"?

[Niclas Hedhman]

Everyone knows that 0.x == "unstable interfaces" and those willing to use
0.x (like me) do expect "hassle" when moving on to 1.0 and beyond. The 0.x
to 1.x transition is extra unique as there are typically a lot less users
than a 1.x to 2.x incompatibility jump. So, my recommendation is; Tackle
all areas where incompatibility can improve the overall codebase.
Postponing it only hurts more later.

Niclas

On Fri, Nov 20, 2020 at 3:47 PM Christofer Dutz 
wrote:

> Hi Otto,
>
> I would not like to start Semver exactly now ... and it doesn't help if we
> start bumping major versions with every release.
>
> In the end this wouldn't really change anything. If we bump the major
> version number it's still incompatible with the old one and we don't know
> if anyone even cared about the incompatibility. And if we bump the major
> version all the time people could be annoyed of us breaking things all the
> time ;-)
>
> Chris
>
>
>
>
>
> Am 20.11.20, 15:32 schrieb "Otto Fowler" :
>
>  or, we can follow versioning rules and have the ‘new kafka sink’
> trigger a
> proper release that allows breaking backwards compatibility
>
> From: Christofer Dutz 
> 
> Reply: dev@plc4x.apache.org  <
> dev@plc4x.apache.org>
> Date: November 20, 2020 at 06:08:51
> To: dev@plc4x.apache.org  
> Subject:  [DISCUSS] How about changing the way we act on "backward
> compatability"?
>
> Hi all,
>
> in a discussion with Ben on the Kafka Connect adapter. He was trying to
> stay compatible with the past in order to not break anything with
> existing
> installations. As of know I don’t know of a single usage of it
> anywhere.
>
> The thing is: we developed a lot of stuff and as of now we don’t really
> know who is actually using what. And in the past I have seen multiple
> times
> that stuff I was thought to be used, actually couldn’t have and I was
> wasting my energy in keeping things compatible while it would have been
> better to change them.
>
> So how about we call out loud on all channels that we promise to pay
> attention to parts we know are being used. And the only way we can know
> about this, is if the companies actually tell us.
>
> I’d even call it out as “We are working hard on reaching the version
> 1.0.0
> and for this we might want to clean up and change a few things”.
>
> This way we can assure we evolve the different parts as freely as
> possible.
> If someone complains that we broke something they were using, we’ve
> got an
> excuse and perhaps we’ll get more official statements about usage this
> way?
>
> What do you think?
>
> Chris
>
>

Re: Anyone feel in need of something to do during the holiday-lockdown?

[Niclas Hedhman]

Warning; The example in JetBrains documentation is far too simplistic to
actually tackle a "real" grammar, and the documentation beyond that is
really sparse and one is mostly alone in trying to figure things out. I
have a non-completed example of that; Pony Language plugin, and I basically
gave up after basic highlighting. See
https://github.com/niclash/pony-idea-plugin

Good Luck
Niclas

On Wed, Dec 23, 2020 at 7:38 PM Christofer Dutz 
wrote:

> Yeah,
>
> the grammar ist the base of the mspec parser and is available in our repo.
>
> I added a jira and linked that here:
> https://issues.apache.org/jira/browse/PLC4X-267
>
> THanks for looking into this.
>
> Chris
>
>
> -Ursprüngliche Nachricht-
> Von: Otto Fowler 
> Gesendet: Mittwoch, 23. Dezember 2020 19:35
> An: dev@plc4x.apache.org
> Betreff: Re: Anyone feel in need of something to do during the
> holiday-lockdown?
>
> Create the jira and assign it to me, I’ll see what I can do
>
> > On Dec 23, 2020, at 09:18, Christofer Dutz 
> wrote:
> >
> > Hi all,
> >
> > so if you happen to be looking for something sensible to do while in
> lockdown during the christmas holidays.
> > I think I have something for you :)
> >
> > While mspec allows us to really quickly develop new drivers, it's a bit
> of a pain do debug or find syntax-errors.
> > We always deamed of having a plugin in IntelliJ to automatically do the
> syntax checking and provide instant feedback.
> >
> > Now I stumbled over this repo:
> > https://github.com/antlr/jetbrains-plugin-sample
> >
> > Which seems to do something exactly like that for an example language.
> >
> > So if anyone here would like to have a shot at this, this would probably
> be the best thing you could do for the project :-)
> >
> > Any volunteers?
> >
> > I'm working on Auto-Discovery for KNX in PLC4Go at the moment which will
> just be the first protocol and language to get this extension ...
> > I'll probably port things back to Java as soon as I have something
> usable and some time to do it.
> >
> >
> > Chris
>
>

Re: Modbus RTU

[Niclas Hedhman]

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.


I have come across a lot of Modbus over the years, but I can't recall 
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 
formal specification. But I would like to bring attention to that a 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

[Niclas Hedhman]

On 2021-08-16 00:16, Ben Hutcheson wrote:
Niclas, For floating point and large integers, this is already 
supported,
where we serialized/parse multiple modbus registers to the different 
data
types. You should be able to use something like 40001:REAL as the 
Address

field.


Excellent!

Niclas

Re: AW: ModBus set slaveId...

[Niclas Hedhman]

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 choosing the correct write function

[Niclas Hedhman]

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: Thomas ... you still around?

[Niclas Hedhman]

On 2022-02-12 21:03, Christofer Dutz wrote:

In the end my final goal would be to have plc4c running in a mynewt
application, which is running on some super-low-power STM32 devices.
One of my development boards has a LoRaWan interface, so in the end
I'd love to send requests to the device and have the responses sent
back via LoRaWan to devides out in the field.


Sorry to intervene... I work a lot with LoraWAN and somehow this sounds 
like "All I have is a hammer so all problems look like a nail." kind of 
thinking.


LoraWAN operates on the basis that uplinks are relatively cheap, albeit 
limited in frequency, and downlinks are much more scarce resource, so 
"request/response" messaging is discouraged in general. And practically 
all devices simply send a packet at some configured interval, with as 
few bytes as possible (to minimize airtime).


I use The Things Network (have not bothered to deploy my own stack, but 
uses the community managed one), and it receives/concentrates the 
LoraWAN packets, and I have a choice there to request/reply, MQTT 
subscribe or webhook (POST to URL) upon data arriving (but after 
decoding of binary bytes to extensive JSON with a lot of useful 
metadata).


I would be happy to guide you or answer any questions, because I think 
the request/reply "mentality" from PLC world doesn't really belong in 
the LoraWAN world.


About your neighbor; I assume it is pH, phosphate and similar 
measurements to be made, maybe measuring the level. It is very likely 
that dedicated LoraWAN sensors are available off-the-shelf, and if not, 
just a generic analog inputs device with conventional sensors would be 
my solution.


And then connect it all to my upcoming http://sensetif.com (service at 
https://sensetif.net) for storage and visualization. ;-) (beta-launch 
planned for March)



Cheers
Niclas

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

[Niclas Hedhman]

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: More possible problems with connection pools

[Niclas Hedhman]

On 2022-01-21 10:12, Christofer Dutz wrote:

I think the very special problem we have here is the limitation of the
number of concurrent connections PLCs usually provide ... my S7 1200
allows 3 concurrent connections. My KNX gateway (which is one of the
better models allowing multiple concurrent connections) only allows 4
connections.


Ok, but then it sounds like "Connection Pool" isn't the appropriate 
general abstraction, since you are basically saying "Only one connection 
from PLC4X"


Cheers
Niclas

Re: More possible problems with connection pools

[Niclas Hedhman]

On 2022-01-21 09:19, Christofer Dutz wrote:

So instead of having the subscriber having to keep the connection to
keep the subscription alive, I would opt for adding subscriptions to
the connection and keeping them valid, even after the connection is
returned to the pool. Yes, this causes subscriptions from multiple
places in your application to get mixed up and potentially one part
could interfere with another one (Like unsubscribe a subscription a
different part subscribed for). But I think from an API perspective
this would probably be the best option for the normal use-cases.


I have had this exact issue (well, not KNX) a long time ago and I would 
like to provide a recommendation;


  * Don't put subscription on Request/Reply connections.

it will down the line complicate matters, with re-subscriptions when a 
request/reply fail for small modest reasons, the connection is torn 
down, and the subscriptions needing to be re-established, and possible 
clients unsubscribing while that is going on. AND dynamic allocation of 
connections becomes harder too, as one has to move subscriptions from 
one connection to another to be able to delete a connection from the 
pool.


Try to put subscription in separate API/interface.


Cheers
Niclas

Re: [DISCUSS] What should the "Connection Pool" be named?

[Niclas Hedhman]

Here is how I would create the abstraction;
There are "physical connections" from the PLC4X to zero, one or more 
devices, and a single connection is held to each device. Then we need a 
solution where different threads can access each such physical 
connection in an ordered/shared manner. So, the client API hands over a 
"virtual connection" which knows how to coordinate with the virtual 
connection (and that implementation is hidden from API, and can change 
over time, and completely different for different drivers, and possibly 
even configurable for different device types).


The "Virtual driver" is very very light, and no pool is needed. No cache 
is needed. Straight up "request a connection, hold on to it for as long 
or as short as you want, then release it".



Cheers
Niclas



On 2022-01-21 12:35, Christofer Dutz wrote:

Hi all,

in the past we had a "ConnectionPool" ... but in reality, we don't
have a pool of multiple connection to one target, like in databases,
but usually we have only one connection to each source in the "pool".
But we can have multiple connections to multiple targets.

I guess that's why Julian named the new version of the Pool
"Connection Cache". This sort of comes closer to what it technically
is.

So now the question is: How should we generally name this thing?

I would opt to stick with ConnectionPool despite it being more a
ConnectionCache. The reason for this is that people looking for
something with the functionality, will probably start looking for a
ConnectionPool and not a ConnetionCache. I think the inside nature of
the component is more a context-detail and we should rather provide
people with what they intuitively would look for.

But I would like to hear your thoughts on this.

Chris

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

[Niclas Hedhman]

On 2022-06-23 14:36, Christofer Dutz wrote:

I agree that if we use NetBeans it’s definitiely “eating our own
(Apache) dogfood” … and yes it’s quite well established.
Probably you can create Standalone Applications with Netbeans similar
to how you can do that with Eclipse.
However, do I imagine, that this would probably be a bit of overkill
for this usecase.


There is a case to be made for having these kinds of tools being part of 
an IDE, i.e. a plugin rather than an "App on NB".
So, by being a little clever, the clickable-jar could also be Netbeans 
plugin compatible, IF that is wanted by people. It is mostly a matter of 
having hooks for user input that can be hooked into NB's system rather 
than handled directly. Minor thing if one take care of it up front.
And if it is then a plugin, then it is up to someone else to package 
that as a dedicated NB app, if such desires exist.



Cheers
Niclas

Re: [DISCUSS] Is a page like this ok?

[Niclas Hedhman]

I would double-check with Brand Management...

On 2022-06-15 13:43, Christofer Dutz wrote:

Hi all,

I just recently was in need of a good profiler and EJ-Technologies
were kind enough to send me a site-license for the Apache PLC4X
project.
Usually they require a no "nofollow" link back to JProfiler. I told
them that we are not allowed to do that due to Apache policies.
They said in this case it wouldn't be a problem to have a nofollow 
link.


So, I created a page with all the commercial tools I know we get free
licenses for (didn't want to have just JProfiler on it)
It's not yet linked to the menu so you can only reach it, if you know 
the url.


https://plc4x.apache.org/developers/tools.html

Would it be ok to integrate this page into the navigation menu?

Chris

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

[Niclas Hedhman]

On 2023-01-10 14:33, Christofer Dutz wrote:

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


Depending on dates, I am interested to attend. I probably fly from 
Copenhagen.


Niclas

Re: Modbus addresses offset by 1?

[Niclas Hedhman]

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.

[jira] [Created] (PLC4X-205) Incorrect shutdown sequence on error

[Niclas Hedhman (Jira)]

Niclas Hedhman created PLC4X-205:


 Summary: Incorrect shutdown sequence on error
 Key: PLC4X-205
 URL: https://issues.apache.org/jira/browse/PLC4X-205
 Project: Apache PLC4X
  Issue Type: Bug
  Components: Core
Reporter: Niclas Hedhman



In the testcase below, there is a permission problem and I think because of 
that the closing of channel and buffers are out of order/state.


[code]
11:59:51.855 [pool-1-thread-1] WARN  i.n.c.AbstractChannelHandlerContext - 
Failed to mark a promise as failure because it has succeeded already: 
DefaultChannelPromise@63ab80ee(success)
java.lang.IllegalStateException: close() must be invoked after the channel is 
closed.
at 
io.netty.channel.ChannelOutboundBuffer.close(ChannelOutboundBuffer.java:683)
at 
io.netty.channel.ChannelOutboundBuffer.close(ChannelOutboundBuffer.java:711)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.close(AbstractChannel.java:741)
at 
io.netty.channel.AbstractChannel$AbstractUnsafe.close(AbstractChannel.java:607)
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.close(DefaultChannelPipeline.java:1352)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeClose(AbstractChannelHandlerContext.java:622)
at 
io.netty.channel.AbstractChannelHandlerContext.close(AbstractChannelHandlerContext.java:606)
at 
io.netty.channel.AbstractChannelHandlerContext.close(AbstractChannelHandlerContext.java:472)
at 
io.netty.channel.DefaultChannelPipeline.close(DefaultChannelPipeline.java:957)
at io.netty.channel.AbstractChannel.close(AbstractChannel.java:232)
at 
io.netty.channel.ChannelFutureListener$2.operationComplete(ChannelFutureListener.java:56)
at 
io.netty.channel.ChannelFutureListener$2.operationComplete(ChannelFutureListener.java:52)
at 
io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:577)
at 
io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:551)
at 
io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:490)
at 
io.netty.util.concurrent.DefaultPromise.addListener(DefaultPromise.java:183)
at 
io.netty.channel.DefaultChannelPromise.addListener(DefaultChannelPromise.java:95)
at io.netty.bootstrap.Bootstrap$3.run(Bootstrap.java:248)
at 
io.netty.channel.ThreadPerChannelEventLoop.run(ThreadPerChannelEventLoop.java:69)
at 
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at 
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at java.lang.Thread.run(Thread.java:748)
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.26 s 
<<< FAILURE! - in 
org.apache.plc4x.java.utils.rawsockets.netty.RawSocketChannelTest
[ERROR] doConnect  Time elapsed: 2.478 s  <<< ERROR!
org.pcap4j.core.PcapNativeException: lo: You don't have permission to capture 
on that device (socket: Operation not permitted)
[code]



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