Re: Account for VPN Access

[Tim Mitsch]

Hi Alex

First of all welcome to PLC4X mailing-list.
Our SPS simulates some machines and some testing stuff – so we have some 
simulation stuff going on.
I’ll setup an openvpn-server that is able to connect to our small lab and has 
restricted communication tunneling to the devices – probably this weekend.

Do u have some special application in mind? Or just testing read/write 
operations and so on – then i’ll setup some random Datatypes within a block u 
could use then.
We have a S7-1515.

I will send config-file to u in private using your e-mail from your message if 
you are interested.

Best
Tim


Von: Julian Feinauer 
Datum: Freitag, 14. Februar 2020 um 16:40
An: "dev@plc4x.apache.org" , Tim Mitsch 

Betreff: Re: Account for VPN Access

Hi Alex,

first off, nice that you found your way here : )
I guess Chris has to check if he can provide access to his PLC.

Alternatively, we could check if we could also grant access to our PLC from 
time to time (looking at @Tim Mitsch<mailto:t.mit...@pragmaticindustries.de>) 
via a special OVPN Config?

Do you have any special applications or things in mind?

Julian

Von: 
Antworten an: 
Datum: Freitag, 14. Februar 2020 um 15:38
An: 
Betreff: Account for VPN Access

Hello everybody,

I just saw your interesting project and started to write a little java 
application. Now it would be great, if I can test my application.
Is it possible to get an account in order to get access to the Siemens S7-1212 
? And if yes, could you tell me some PLC addresses, so I can transfer some data?

Thank you in advance!

With best regards

i. A. Alexander Bischof
Software-Developer

GROB-WERKE GmbH & Co. KG
Industriestraße 4
87719 Mindelheim

Tel.: 08261 996-7531
E-Mail: alexander.bisc...@grob.de<mailto:alexander.bisc...@grob.de>
Internet:  www.grobgroup.com<http://www.grobgroup.com/>

Re: Antwort: Re: Configuring a S7-1500 for Access with PLC4J

[Tim Mitsch]

Hey Sebastian

Sorry for delayed answer – but first of all warm welcome on the list.

Just tested ur code-snippet vs our S7-1515 and is working fine.
U said u activated Put/Get.
Do u have the possibility to execute the scraper runner:
Plc4j/util/scraper/test/TriggeredScraperRunner

U need to adjust the ‘example_triggered_scraper.yml’ to ur needs (ip, field) …
Please take into account that the field to be read from must be a NON-optimized 
block

If there are still issue please write on the list and I can make a cross-check 
to the S7 Settings.

Best
Tim



Von: Sebastian Wiendl 
Antworten an: "dev@plc4x.apache.org" 
Datum: Donnerstag, 7. November 2019 um 16:29
An: "dev@plc4x.apache.org" 
Betreff: Antwort: Re: Configuring a S7-1500 for Access with PLC4J

Hi Cesar,

thanks for your input.

s7://172.30.74.65/0/0  is an illegal plc4j connection 
string. (The PLC's webserver is disabled btw.)

s7://172.30.74.65/0/0 yields the same exception as before.

I checked with our IT department in parallel - there is one router between me 
and the PLC and port 102 is open and reachable. No firewalls either.

Mit freundlichen Grüßen
Kind regards

Sebastian Wiendl
DSE / Digital Solutions Software Engineer
Phone: +49 9605 919 - 9341
E-Mail: swie...@bhs-world.com
Internet: www.bhs-world.com
Shop: www.icorr.shop

 [cid:_1_150B9900150B9504005508A3C12584AB]

BHS Corrugated Maschinen- und Anlagenbau GmbH
Paul-Engel-Straße 1
92729 WEIHERHAMMER
GERMANY

Management: Christian Engel, Lars Engel
Registered at Amtsgericht Weiden, HR B 1320



[cid:_2_150BB3DC150BAFF8005508A3C12584AB]
[cid:_2_150BB9C8150BB5E4005508A3C12584AB]
[cid:_2_150BBFB4150BBBD0005508A3C12584AB]


[cid:_1_150BC450150BBD20005508A3C12584AB]




Von:"Cesar Garcia" 
An:"Apache PLC4X" 
Datum:07.11.2019 15:53
Betreff:Re: Configuring a S7-1500 for Access with PLC4J




Hello,

Try (*"s7://172.30.74.65/0/0 ")*

For S7-1200 and S7-1500 is Rack=0, Slot=0,

Best regards

El jue., 7 nov. 2019 a las 9:58, Sebastian Wiendl (<
swie...@bhs-corrugated.de>) escribió:

> Hello everyone,
>
> my sample program of PLC4J (very similiar to the hello world example)
> fails to connect to my test PLC (S7-1500):
>
> Nov 07, 2019 2:37:51 PM io.netty.channel.DefaultChannelPipeline
> onUnhandledInboundException
> WARNUNG: An exceptionCaught() event was fired, and it reached at the tail
> of the pipeline. It usually means the last handler in the pipeline did not
> handle the exception.
> java.io.IOException: Eine vorhandene Verbindung wurde vom Remotehost
> geschlossen
> at sun.nio.ch.SocketDispatcher.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:192)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> at
> io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:288)
> at
> io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1125)
> at
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:347)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:682)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:617)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:534)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:906)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
>
> "An existing connection was closed by the remote host"
>
> Thats my program at the moment:
>
>
> *public static void *main(String[] args) {
>*try *(PlcConnection plcConnection = *new *
> PlcDriverManager().getConnection(*"s7://172.30.74.65/0/2
> "*)) {
>System.*out*.println(*"connected"*);
>System.*out*.println(plcConnection);
>CompletableFuture ping = plcConnection.ping();
>ping.get(500, TimeUnit.*MILLISECONDS*);
>System.*out*.println(*"ping exception = " *+
> ping.isCompletedExceptionally());
>} *catch *(Exception e) {
>e.printStackTrace();
>}
>System.*out*.println(*"disconnected"*);
>}
>
> I can both ping the PLC as well as connect to it with the Siemens TIA
> Portal. Does the PLC 

Re: [VOTE] Apache PLC4X 0.5.0 RC3

[Tim Mitsch]

Hey everybody,
+1 (binding)

I checked:
- Checked out using tooling
- Checked Signatures and Hashes
- Checked README, RELEASE_NOTES, LICENSE and NOTICE
- Checked README and RELEASE_NOTES are same as in the zip
- No unexpected binaries

Build on all major OS:
- MacOS Mojave 10.14.6, with JDK 1.8 using './mvnw -P 
with-python,with-proxies,with-boost,with-java,with-cpp,with-dotnet install' 
without any issues
- CentOS 7.6.1810, with JDK 1.8 using './mvnw -P 
with-python,with-proxies,with-boost,with-java,with-cpp,with-dotnet install' 
without any issues
- Built on Windows 10 x86-64 using '.\mvnw.cmd -P with-java -DskipTests 
install' without any issues

Minor issues:
- Build on Windows made -DskipTests necessary, due to failing 
RawSocketChannelTest and the loopback issue, as already stated by Björn and 
addressed in Jira
- '.\mvnw.cmd -P 
with-python,with-proxies,with-boost,with-java,with-cpp,with-dotnet -DskipTests 
install' failed due to issues on building thrift, although all WinBuilds tools 
as described in ReadMe were installed, but this may be related to setup of my 
Win-VM

Best
Tim

Am 29.10.19, 14:04 schrieb "Christofer Dutz" :

Apache PLC4X 0.5.0 RC3 has been staged under [2] and it’s time to vote
on accepting it for release. All Maven artifacts are available under [1].
Voting will be open for 72hr.

A minimum of 3 binding +1 votes and more binding +1 than binding -1
are required to pass.

Release tag: release/0.5.0-rc3
Hash for the release tag: 59cd9d3839dcb6083350144802142360182c59c1

Per [3] "Before voting +1 PMC members are required to download
the signed source code package, compile it as provided, and test
the resulting executable on their own platform, along with also
verifying that the package meets the requirements of the ASF policy
on releases."

You can achieve the above by following [4].

   [ ]  +1 accept (indicate what you validated - e.g. performed the non-RM 
items in [4])
   [ ]  -1 reject (explanation required)

[1] https://repository.apache.org/content/repositories/orgapacheplc4x-1018
[2] https://dist.apache.org/repos/dist/dev/plc4x/0.5.0/rc3
[3] https://www.apache.org/dev/release.html#approving-a-release
[4] 
https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release

Re: Cleaning up of stale branches?

[Tim Mitsch]

Hi Chris

Thanks for notice. I'll clean up and delete my obsolete branches.

Best 
Tim

Am 26.10.19, 15:44 schrieb "Christofer Dutz" :

Hi all,

today I was working on cleaning up in the repo and deleting all the 
obsolete branches I was working on and which have been merged or which had 
become obsolete.

There are some branches, where I would be happy, if you could double check 
if they are still needed.
If they are, perhaps we should finish some of the tasks as when we’re going 
to refactor the API, keeping them in sync will become “challenging”.

Here comes the list:
https://github.com/apache/plc4x/commits/PLC4X-139-fix-socket-leak

https://github.com/apache/plc4x/commits/feature/code-gen-julian

https://github.com/apache/plc4x/commits/feature/improve-scraper-tim

https://github.com/apache/plc4x/commits/features/scraper-jmx-support

https://github.com/apache/plc4x/commits/fix-bytebuff-leaks

https://github.com/apache/plc4x/commits/fix-netty-usage

https://github.com/apache/plc4x/commits/merge-julian-branch

https://github.com/apache/plc4x/commits/netty-serial-nio

https://github.com/apache/plc4x/commits/scraper_refactoring_and_improvement

https://github.com/apache/plc4x/commits/too-many-open-files


Chris

Re: Simpifying the profiles?

[Tim Mitsch]

Hey everybody,

First of all it's a very good idea to simply the profile-stuff.

My thoughts to that are that we maybe could add a little shell-script 
(Mac/Linux), bat-file (Windows) that guides the user ("Do you want to build 
Java-sources? [Yes/No]) and states if all requirements for build of this 
profile is supplied by the specific machine of the user. I think that goes in 
the direction of Chris suggestion 1)

Furthermore it would be good to supply a "with-all" Profile that triggers all 
available profiles.

Best
Tim

Am 15.10.19, 10:07 schrieb "Christofer Dutz" :

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

Re: [S7] Verification of the "Date-Types"?

[Tim Mitsch]

Hey

I extended the implementation because S7-1500 family returns a not known 
datatype for those date-types, and there was a need to read those types. So I 
acquire a set of bytes and extract the date information from that.
If that causes problems with the simulator we should have a deeper look into 
that.

Best
Tim


Am 14.10.19, 18:08 schrieb "Christofer Dutz" :

Hi all,

While working on the PLC Simulator I stumbled into one pit … when receiving 
a read request and deserializing this, I was confused why a read request for 
one BYTE was received as a DATE_TIME.
A quick look showed me, that there are multiple types with the same code. I 
thought that this would not be causing any problems as long as all codes result 
in the same number of bytes being read.
Unfortunately it seems with the dates and times this doesn’t seem to fit 
well.

Not all PLCs support all of these types. But I would like to sort this out 
as for example DATE_AND_TIME (0x02) reads 8 bytes, but TIME_OF_DAY (0x02) reads 
4 byte and DATE (0x02) reads only 2 bytes. I guess the way it’s currently 
setup, this can’t be correct.

Do you have an idea how we can sort this out?

Chris

Re: [DISCUSS] Rename CRUNCH to something different

[Tim Mitsch]

Hey,

As i'm electrical engineer i like the name oscilloscope.
But full ack to Kai, name should be clearer.
Furthermore i like Kai's suggestion PLC4X DSP as it is short and clear what 
Crunch does ... processing and analyzing digitalized data. Maybe we could also 
call it PLC4X MSP for 'Mixed Signal Processing' or any other artifical acronym.

Best
Tim

Am 15.09.19, 18:20 schrieb "Kai Wähner" :

I would vote for something like Niclas proposed. Much clearer than having
yet another product / component name...

For instance, PLC4X DSP, PLC4X Signal Processor, or something what clearly
describes in one or two words / shortcuts what the component does.

See Kafka and its ecosystem: Kafka Connect, Kafka Streams, Confluent Schema
Registry, Confluent Rest Proxy, Confluent Control Center, etc...

Kai

On Sun, Sep 15, 2019 at 9:05 AM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hi,
>
> I was thinking about naming and came up with ideas like...
>
> - trace4j
> - dsp4j (digital signal processing, that is)
> - pluse (as we detect pulses and stuff)
> - oscilloscope <-- I quite like that, it fits quite well as we really look
> into signals
>
> What are thoughts on those?
>
> J
>
> Am 08.09.19, 22:38 schrieb "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 <
> j.feina...@pragmaticminds.de>
> 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: [VOTE] Accept CRUNCH as subproject for PLC4X

[Tim Mitsch]

+1 (binding)

That brings much more power to stuff like scraper, so full ack!

Best
Tim

Am 02.09.19, 20:56 schrieb "Julian Feinauer" :

Hi all,

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

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

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

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

Thanks
Julian

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

[jira] [Created] (PLC4X-141) String with real length of greater 127 throw an exception

[Tim Mitsch (JIRA)]

Tim Mitsch created PLC4X-141:


 Summary: String with real length of greater 127 throw an exception
 Key: PLC4X-141
 URL: https://issues.apache.org/jira/browse/PLC4X-141
 Project: Apache PLC4X
  Issue Type: Bug
Affects Versions: 0.4.0
Reporter: Tim Mitsch
Assignee: Tim Mitsch
 Fix For: 0.5.0


when reading out Strings the maximum and current real length is read out, the 
current length gives the number of chars that are casted into returning String



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[Driver/Connection] Connection String Validation possibility, implicit connect

[Tim Mitsch]

Hey everybody

First topic:
I just faced the problem of validating a given connection string to a PlcField 
(in general) for syntactical correctness.
For S7Field we implemented some static functionality (“matches(String)”) to 
check if the given string matches the PATTERNs , but i think we should 
implement something similar for all other implemented Devices/FieldTypes; as 
Java does not offer to override a static method defined in interface in an 
implemented class we should think about another solution.
I had a chat with Julian on slack and he suggested to acquire at first a Driver 
from DriverManager whereas the given driver (or connection) offers a method 
where the validation of a connection string to a field 
(“validateQuery(String)“) could be performed. Furthermore also DriverManager 
could offer a method to validate a field-connection-string and returning for 
what kind of Driver that string could be used.
I would highly appreciate to have a connection-string-validation as soon as 
possible; I also can start implementing that (@Chris,@Julian I promise to 
finish that in an appropriate amount of time, not like with my scraper-branch 
--> Sorry for that).

Second topic:
Close related is another topic I had some issues with: when fetching a 
Connection via getConnection() from a DriverManager we currently perform an 
implicit connect() to that connection. I think we should offer the user the 
possibility to connect to the connection on his request.

What do u think about these two topics?

Best
Tim

[jira] [Created] (PLC4X-140) Create a set of connection-tests that potentially could lead to crash or leak

[Tim Mitsch (JIRA)]

Tim Mitsch created PLC4X-140:


 Summary: Create a set of connection-tests that potentially could 
lead to crash or leak
 Key: PLC4X-140
 URL: https://issues.apache.org/jira/browse/PLC4X-140
 Project: Apache PLC4X
  Issue Type: Test
Affects Versions: 0.4.0
Reporter: Tim Mitsch
 Fix For: 0.5.0


set of connection-tests to
 * different drivers
 * different conditions (not available, avab then not avab, firewall issues)
 * heavy load
 * ...



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: [DISCUSS] Retire Daffodil and SCXML?

[Tim Mitsch]

Sorry for late response, quite busy on a fair.
But also +1 from me

Best
Tim

Am 25.06.19, 10:08 schrieb "Christofer Dutz" :

Oh wow ... 

that was a quick one ... I think I'll just do it right away.

Thanks for the ultra-quick responses

Chris


Am 25.06.19, 10:05 schrieb "Julian Feinauer" :

Hi,

I agree and I think its important to tag it as it really was an 
intersting step.

Julian

Am 25.06.19, 09:57 schrieb "Markus Sommer" :

+1

Freundliche Grüße

Markus Sommer
Geschäftsführer

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

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

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

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


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

Hi all,

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

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

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

What do you think?

Chris

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

[Tim Mitsch]

Hi @all 
and welcome to Matthias on the board

Good to see the community growing __

Go Go Go Team Toddy!

Best
Tim


Am 03.06.19, 11:28 schrieb "Christofer Dutz" :

Hi all,

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

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

Matthias: Welcome in Team Toddy! :-)

Chris

Re: [VOTE] Apache PLC4X 0.4.0 RC1

[Tim Mitsch]

Heyho,

I checked

* no incubating in name or DISCLAIMER file
* signatures and hashes correct (also used Chris' toolset)
* all source files have ASF headers (rat plugin)
* can build from sources on all major OS:
- OS X 10.14.4 (09:53min)
- Win 10 (Version 1803), (23:15min)
- CentOS7 (14:02min)

Command on 
* Mac and Linux{1}: `./mvnw -P 
with-java,with-cpp,with-dotnet,with-python,with-proxies,with-sandbox install` 
* Win{2}: ' mvnw.cmd -P with-java -P with-python -P with-proxies -P with-dotnet 
-P with-cpp -P with-python install'

So +1 (binding) 
for 0.4.0-RC1

Best
Tim

{1}: for a strange reason on some VMs occur a failing tests with 
UnknownHostException, will investigate on that further
{2}: Suggestion - if build fails due to crashin forked VM: pipe cmd-line output 
to a file outside build folder ( ... > C:\tmp\build.log ) (due to rat-check); 
for some strange reason on some VMs the cmd logging gets to big, see also [3]; 
furthermore around RAM 2GB peak is needed
[3]: https://stackoverflow.com/a/52033799 

Am 22.05.19, 00:08 schrieb "Christofer Dutz" :

   Apache PLC4X 0.4.0 has been staged under [2] and it’s time to vote
   on accepting it for release. All Maven artifacts are available under [1].
   Voting will be open for 72hr.

   A minimum of 3 binding +1 votes and more binding +1 than binding -1
   are required to pass.

   Release tag: release/0.4.0
   Hash for the release tag: 10739fd4a6d201364d5021c78e7e1c529f04336d

   Per [3] "Before voting +1 PMC members are required to download
   the signed source code package, compile it as provided, and test
   the resulting executable on their own platform, along with also
   verifying that the package meets the requirements of the ASF policy
   on releases."

   You can achieve the above by following [4].

   [ ]  +1 accept (indicate what you validated - e.g. performed the non-RM 
items in [4])
   [ ]  -1 reject (explanation required)


   [1] 
https://repository.apache.org/content/repositories/orgapacheplc4x-1009
   [2] https://dist.apache.org/repos/dist/dev/plc4x/0.4.0/rc1
   [3] https://www.apache.org/dev/release.html#approving-a-release
   [4] 
https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release

Re: Cutting our first TLP

[Tim Mitsch]

Hey all,

thanks Julian; and yes i'm working on scraper improvements and documentation 
when I find some time.
I think I won't make it to finish my stuff up to tomorrow; so I think this will 
be content for the subsequent release.

Best & see u on Friday
Tim



Am 20.05.19, 15:56 schrieb "Julian Feinauer" :

Hi Chris,

just a short notice, speaking for Tim.
I think he is about to get his scraper fixes (from Brussels) finished.

@Tim: could you comment on that? Perhaps you can use your time in the train 
today to make progress?

Julian

Am 20.05.19, 15:53 schrieb "Christofer Dutz" :

Hi all,

I just updated the RELEASE_NOTES with some details of what’s in version 
0.4.0.
If any of you are working on things that should be part of 0.4.0, 
please make yourself heard.
I would probably cut a release branch tomorrow and start the release 
process as soon as possible.

I currently don’t have anything I would like to add to it … the 
generated driver stuff doesn’t
Have any effect on the release anyway.

Help us get the first TLP version of Apache PLC4X out the door :-)

If we hurry up, we could even announce the release at our party on 
Friday.

Chris

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

[Tim Mitsch]

Of course a big welcome to Björn also from my side __
go go go TEAM TODDY

Best
Tim

Am 13.05.19, 18:15 schrieb "Bjoern Hoeper" :

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

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

Hi all,

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

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

Julian (on behalf of the PLC4X PMC)

Re: [DISCUSSION] Release 0.4

[Tim Mitsch]

Hey everybody,

full ack ... a soon release shall be done, as we have enough stuff that could 
be released.

I can do the release as i got a great introduction of how to do it with 0.3.1 
by Julian, thanks for that btw.
But i think Chris has the honor to decide if he wants to do the first Release 
of PLC4X matured to TLP - would love to support

I think end of this or beginning of next week could be a good date for a 
0.4.0-RC1

Best
Tim

 

Am 05.05.19, 21:04 schrieb "Christofer Dutz" :

Hi all,

I also think we should do a release soon. Especially for making a first tlp 
release.

Regarding the RM, I would like to actually perform the technical release 
this time. I'm quite sure I changed the graduation related stuff correctly, but 
with all this super special additional stuff (CPP, C#, Python, Thrift) I am 
sorry of expecting bumps on the road.

I'm fine with Tim doing the paperwork, if he wants to ;-)

Chris

Outlook für Android herunterladen


From: Julian Feinauer 
Sent: Sunday, May 5, 2019 7:52:31 PM
To: dev@plc4x.apache.org
Subject: [DISCUSSION] Release 0.4

Hi all,

we also had a short discussion about the next release of PLC4X but I guess 
the best place is the list.
So I think we should start very soon with the preparation of a new release.
I also think we should include some of the very recent things (Python, CPP) 
but explicitly flag them as experimental feature.
So we can give them out to others but with a clear disclaimer that this is 
more a “play around” thing.

And we are free to target the next release “soon” to add some more things.
I see that there are a lot of “small” improvements which we really should 
get out, and I would also love to start collecting feedback for the 
“experimental” stuff.

Another question that came up was who will be RM.
Tim already volunteered for that, and I absolutely support that to further 
diversify the RMs.
But as the build recently changed it could be a bit complicated so Chris 
offered to do it this time.
I cannot say what is the best solution but leave it up to everybody.

Perhaps a solution would be to have Tim “manage” it and prepare everything 
and then do the maven related stuff with supervision from chris or by chris. By 
doing this he gets at least a good knowledge of the process around (branching 
strat, vote preparation and so).

What are your opinions?
I think we could target something like the end of next week for an RC.

Julian

Re: Short wrap-up of this Weekend

[Tim Mitsch]

Hey guys

@Julian :
full ack to Chris ... great summary
i liked it also very much in Brussels ... little other than expected but 
definetly repeatable __ @TEAM TODDY (btw. who likes to have one or more of our 
Team-Toddy T-Shirts, i still have some in M, L and XL)

@Chris:
Sounds interesting - excited to know more tommorow

My scraper PR will open Tuesday probably.

Best
Tim

Am 05.05.19, 22:37 schrieb "Christofer Dutz" :

Hi Julian,

Thank you for that excellent summary. In the last two hours I had a little 
chat with the guys from the European commission. Seems they liked how we help 
the small businesses participate in the Innovation. Will probably post more 
tomorrow ... In the train and still I almost can't keep my eyes open ;-)

Totally exhausted, I am ;-)

Chris

Outlook für Android herunterladen


From: Julian Feinauer 
Sent: Sunday, May 5, 2019 7:47:42 PM
To: dev@plc4x.apache.org
Subject: Short wrap-up of this Weekend

Hi all,

hi to (hopefully) some new people on the list, hi to all attendees of the 
FOSSA Hackathon in Brussels and also Hi to all others who had to stay at home.
As we are currently driving home I wanted to give everybody a short wrap-up 
of what happened in the project and what things we talked about (well, 95% in 
fact was simply bullshit… but the 5%...).

Most notably we have a first Version of the C# (or .NET) Api finished by 
Björn and merged by Chris, so big props to those two!
Then, Tim did a lot of refactoring for the Scraper (where we really rely 
on…) so thanks to Tim. I guess the PR will come in one or two days.
Lukasz spent some time in fixing the Karaf integration and made quite some 
progress, as far as I understood it (you know, the shortest programmer joke 
“nearly done”…). So hopefully, we can also celebrate his first PR very soon.
Other than that, lovely Chris gave some new people an introduction to PLC4X 
and we had several people hanging around with us and coding a bit around.
Of course Niklas has to be named who did his first PR after sitting with us 
for some MINUTES, so this definetly is a record (Lukasz needed about 2 years… I 
guess :P ).
Finally, Chris, Björn and I spend some time on the Code Generation thing 
and we are in quite good state as we are able to nicely generate POJOs in Java 
and Python (well I guess in Python those are not Pojos… how are they called? 
POPOs? (that’s the german word for butt)).
So it seems reasonable that we can soon(tm) generate some serialization / 
deserialization automatically for DFDL files. As Chris already finished those 
for S7 this would be a HUGE step forward.

So after all, it was a really nice weekend with really nice beer and really 
short nights and a lot of fun and community and I can only come to one 
conlusion… we need more Hackathons with our community.
So I’m open for any suggestions (Mallorca?) and I’m looking really forward 
to our next meetup which will be awesome!

Julian

[jira] [Created] (PLC4X-119) Nett ByteBuffer Leak

[Tim Mitsch (JIRA)]

Tim Mitsch created PLC4X-119:


 Summary: Nett ByteBuffer Leak
 Key: PLC4X-119
 URL: https://issues.apache.org/jira/browse/PLC4X-119
 Project: Apache PLC4X
  Issue Type: Bug
Affects Versions: 0.3.1
Reporter: Tim Mitsch


 

When Scraping for other frequently connectionto plc  the following exception 
comes up ... more or  less frequently but quite rare; has no functional 
consequence, but maybe someone knows more about

[http://netty.io/wiki/reference-counted-objects.html]
{code:java}
23:39:40.555 [nioEventLoopGroup-5-1] ERROR io.netty.util.ResourceLeakDetector - 
LEAK: ByteBuf.release() was not called before it's garbage-collected. See 
http://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records:
Created at:
io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:349)
io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:187)
io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:123)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:864)
io.netty.buffer.WrappedByteBuf.readBytes(WrappedByteBuf.java:616)
org.apache.plc4x.java.isoontcp.protocol.IsoOnTcpProtocol.decode(IsoOnTcpProtocol.java:100)
io.netty.handler.codec.ByteToMessageCodec$1.decode(ByteToMessageCodec.java:42)
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:502)
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:441)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:278)
io.netty.handler.codec.ByteToMessageCodec.channelRead(ByteToMessageCodec.java:103)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1408)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:930)
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:682)
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:617)
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:534)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:906)
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
java.lang.Thread.run(Thread.java:748)
{code}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Draft of our first Board Report

[Tim Mitsch]

+1

Am 29.04.19, 17:15 schrieb "Christofer Dutz" :

Hi all,

I just finished a first version of our first board report: 
https://cwiki.apache.org/confluence/display/PLC4X/2019-May

Please review and comment. Even if it’s not expected to be in there, I’ll 
probably add a “numbers” section asap which should also provide some 
information on the development of the community.

Chris

Re: [DISCUSS ] PLC4X Teamware

[Tim Mitsch]

+1 very good idea


 Ursprüngliche Nachricht 
Von: Julian Feinauer 
Gesendet: Saturday, April 27, 2019 02:27 PM
An: dev@plc4x.apache.org
Betreff: [DISCUSS ] PLC4X Teamware

Hi all,

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

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

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

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

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

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

What do you think?

Julian

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

Von meinem Mobiltelefon gesendet

[jira] [Created] (PLC4X-112) Write Readme for usage of (triggered) scraper

[Tim Mitsch (JIRA)]

Tim Mitsch created PLC4X-112:


 Summary: Write Readme for usage of (triggered) scraper
 Key: PLC4X-112
 URL: https://issues.apache.org/jira/browse/PLC4X-112
 Project: Apache PLC4X
  Issue Type: Task
Affects Versions: 0.3.1
Reporter: Tim Mitsch
Assignee: Tim Mitsch
 Fix For: 0.4.0






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Anyone interested in revamping the Kafka-Connect adapter?

[Tim Mitsch]

Hey

I'm not so deep in Kafka-Connect - but i would be interested to work on the 
camel implementation of scraper - i will do a jira issue for that, good point 
Julian.
But time is quite rare until weekend.

Best
Tim

Am 10.04.19, 10:35 schrieb "Julian Feinauer" :

Hi,

yes, that should be the way to go (also for something like Camel...).
I have no time to contriobute this week, I can only offer to answer 
questions... perhaps Tim can say something?

Julian

PS.: Oh, we should at least add Jira issues... we have to learn that

Am 10.04.19, 10:32 schrieb "Christofer Dutz" :

Hi all,

yesterday I have been trying to understand the Kafka-Connect adapter 
and think I managed to get to a point where I sort of understand it.
However I’m not quite happy with the way it currently works (I think 
you have to put every item address in a space-separate list also does it use 
manual polling)

I know Kafka-Connect supports both push and pull types … I think sort 
of using the new Scraper and it’s trigger strategies makes it a perfect 
candidate
for changing the connector into a pull-connector. Also do I think we 
have to provide an alternate way of configuring … I know that one poc of 
collecting
2600 Items on 200 PLCs was quite a long configuration string ;-)

Anyone interested in taking on the fight? Ideally one with either 
Scraper knowledge and/or Kafka … I sort of don’t qualify for either of them ;-)

Chris

[jira] [Created] (PLC4X-109) Add comparision to previous values as TriggerStrategy to TriggeredScraper

[Tim Mitsch (JIRA)]

Tim Mitsch created PLC4X-109:


 Summary: Add comparision to previous values as TriggerStrategy to 
TriggeredScraper
 Key: PLC4X-109
 URL: https://issues.apache.org/jira/browse/PLC4X-109
 Project: Apache PLC4X
  Issue Type: Improvement
Affects Versions: 0.3.1
Reporter: Tim Mitsch
Assignee: Tim Mitsch
 Fix For: 0.4.0






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Graduate Apache PLC4X (incubating) to become a Top-Level-Project at the ASF

[Tim Mitsch]

+1 (binding)  (Graduate Apache PLC4X (incubating) to TLP)

Best
Tim

Am 01.04.19, 15:18 schrieb "Christofer Dutz" :

Today exactly one month ago we had a discussion on graduating and it was 
generally approved [1]
Justin mentioned some trademark related issues in the same thread and 
suggested we do a maturity assessment …
all of this was discussed in the same thread.

The maturity assessment can be found here [2]. All issues reported by 
Justin have been addressed.

Therefore I would like to cast a vote that the Apache PLC4X (Incubating) 
podling graduates to become a TLP.

We have decided NOT to carry over the podling PPMC and Committer List to 
the TLP and have had a vote on who
wants to remain while keeping the list of PMCs equal to the committers 
group [3].
The following individuals would be part of this PMC:

* Christofer Dutzmailto:cd...@apache.org>>
* Julian Feinauermailto:jfeina...@apache.org>>
* Justin Mclean  mailto:jmcl...@apache.org>>
* Markus Sommer  mailto:msom...@apache.org>>
* Sebastian Rühl mailto:sru...@apache.org>>
* Tim Mitsch mailto:tmit...@apache.org>>

Also has a vote been done and we would suggest the Board to assign 
Christofer Dutz as Chair of the to be established TLP [4]

Having gone through the documentation I think we are as far as we can get.

So here goes:

[ ] +1 (Graduate Apache PLC4X (incubating) to TLP)
[ ] +0 (no opinion)
[ ] -1 (Don’t Graduate – with reason)

This vote will stay open for 72 hours.

Chris


[1] 
https://lists.apache.org/thread.html/d7b9ef8000ccf20bc7facd13a16bd8045e9b391da5d6fdf804b0be48@%3Cdev.plc4x.apache.org%3E
[2] http://plc4x.apache.org/developers/maturity.html
[3] 
https://lists.apache.org/thread.html/7a979438fa050bc873a4df0da9b628edaa61d350a17364b837a059d3@%3Cdev.plc4x.apache.org%3E
[4] 
https://lists.apache.org/thread.html/cc0436a89a2279cddf440af154c4274a31142dc7bc4742cd51094e16@%3Cprivate.plc4x.apache.org%3E

Re: [DISCUSS] Send Code Review mails to commits@

[Tim Mitsch]

+1

Am 29.03.19, 13:42 schrieb "Julian Feinauer" :

Hi all,

as we all got a lot of spam from Sebastians Code Review and my changes we 
had a short discussion in the Slack channel.
I suggest to send these mails to the commits@ mailing list or probably 
another one (which I don’t usually read that well),
What do you think?

Julian

Re: [VOTE] Defining the initial PMC/Committers for graduation

[Tim Mitsch]

+1

Am 25.03.19, 11:27 schrieb "Christofer Dutz" :

Hi all.

As we discussed this here before, our PPMC is quite full of people that 
have never showed much interest in the project.
This was a result of how we setup the project when we started it here at 
codecentric. A lot of people raised their hands
When I asked: “Who wants to join?”, but never actually did something or did 
something for a few weeks and then disappeared.
We simply took that list into the incubator.

We discussed this on the list previously, that we are going to give every 
existing PPMC the chance to be part of the PMC,
If he expresses the wish to do so.

So in this VOTE thread I would like everyone on the PLC4X PPMC who wishes 
to become part of the PMC of the PLC4X top
level project to vote with +1. We’ll keep this vote open for a week to give 
even the less active mailing-list readers the
chance to vote. Anyone voting -1 or not voting at all will NOT be part of 
the PMC list which we’ll use in the graduation vote.

Chris

Re: [WEBSITE] Please review the latest page changes and additions ...

[Tim Mitsch]

Hi Chris

At first +1 for adding those pages! Thanks!
For me it looks good and all information, as far as i can rate it, are included
I added a short bio and a picture of myself as well to team-page.

Best
Tim


Am 20.03.19, 14:21 schrieb "Christofer Dutz" :

Hi all,

please review the pages I added in the last 2-3 days. Especially:
http://plc4x.apache.org/developers/contributing.html
http://plc4x.apache.org/developers/decisions.html
http://plc4x.apache.org/developers/maturity.html
http://plc4x.apache.org/developers/team.html

I would like to see consent on the content in our team before we go the 
next steps :-)

Chris

[jira] [Created] (PLC4X-104) S7 Driver Datatype TIME_OF_DAY causes NPE

[Tim Mitsch (JIRA)]

Tim Mitsch created PLC4X-104:


 Summary: S7 Driver Datatype TIME_OF_DAY causes NPE
 Key: PLC4X-104
 URL: https://issues.apache.org/jira/browse/PLC4X-104
 Project: Apache PLC4X
  Issue Type: Bug
  Components: Driver-S7
Affects Versions: 0.3.1
Reporter: Tim Mitsch
 Fix For: 0.4.0


 
{code:java}
2019-03-14 12:00:39.909 WARN 35900 --- [ntLoopGroup-2-1] 
io.netty.channel.DefaultChannelPipeline : An exceptionCaught() event was fired, 
and it reached at the tail of the pipeline. It usually means the last handler 
in the pipeline did not handle the exception.
java.lang.ArrayIndexOutOfBoundsException: null
 at java.lang.System.arraycopy(Native Method) ~[na:1.8.0_112]
 at 
org.apache.plc4x.java.s7.netty.strategies.DefaultS7MessageProcessor.getMergedResponseMessage(DefaultS7MessageProcessor.java:422)
 ~[plc4j-protocol-s7-0.3.2.jar:0.3.2]
 at 
org.apache.plc4x.java.s7.netty.strategies.DefaultS7MessageProcessor.processResponse(DefaultS7MessageProcessor.java:346)
 ~[plc4j-protocol-s7-0.3.2.jar:0.3.2]
 at org.apache.plc4x.java.s7.netty.S7Protocol.decode(S7Protocol.java:483) 
[plc4j-protocol-s7-0.3.2.jar:0.3.2]
 at org.apache.plc4x.java.s7.netty.S7Protocol$1.decode(S7Protocol.java:86) 
[plc4j-protocol-s7-0.3.2.jar:0.3.2]
 at 
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88)
 [netty-codec-4.1.31.Final.jar:4.1.31.Final]
 at org.apache.plc4x.java.s7.netty.S7Protocol.channelRead(S7Protocol.java:416) 
[plc4j-protocol-s7-0.3.2.jar:0.3.2]
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
 [netty-codec-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111)
 [netty-codec-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:323)
 [netty-codec-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:297)
 [netty-codec-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.handler.codec.ByteToMessageCodec.channelRead(ByteToMessageCodec.java:103)
 [netty-codec-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1434)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at 
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:965)
 [netty-transport-4.1.31.Final.jar:4.1.31.Final]
 at

Re: [DISCUSS] Release Strategy for future releases

[Tim Mitsch]

Hello everybody,

I'll agree with Chris as well as with Julian ... think lots of people are under 
heavy load in incubator so high release frequency won't be the best solution as 
long as we are an incubating project.
On the other hand we should take care about not releasing in too less frequency 
to make interested people more interested in what we're doing and make feature 
available as early as possible.
As already said ... I think we should create a more or less regular 
release-interval when we are graduated.

As I had a look on Julian doing 0.3.1 release procedure I think I can do the RM 
for next release which I think will be 0.4.0 (maybe end of April or beginning 
of may).
If there is nothing against it I'll start to prepare a feature list and opening 
a new topic on mailing-list for that as well as creating the regarding 
jira-tickets.

Best
Tim

Am 06.03.19, 21:55 schrieb "Julian Feinauer" :

Hey Otto,

fair point. I think we should to decide a new release strategy. But if we 
consider to keep it as it is now we should not have to vote.

Or?

Julian

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: Re: [DISCUSS] Release Strategy for future releases
Von: Otto Fowler
An: dev@plc4x.apache.org,Christofer Dutz
Cc:

Shouldn’t you call an official vote for something like this?


On March 6, 2019 at 15:29:18, Christofer Dutz (christofer.d...@c-ware.de)
wrote:

Big +1 for that ;-)

Chris


Am 06.03.19, 21:26 schrieb "Julian Feinauer" :


Hi Chris,

No offense. I agree that we should not stress those lovely people more than
necessary.
So we keep our aim on 0.4 (with whatever accumulates till then) for now and
start regular releases when graduated.

Is this a plan?

Julian

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: Re: [DISCUSS] Release Strategy for future releases
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:

Hi Julian,

I would +1 this, but please have one thing in Mind ... every release we do
requires us to check it (of course) ... but also we have to have people in
the Incubator also validate these releases.
Some people there are under heavy load and I would not like to increase
this load too much.

But how about starting with that as soon as we have left the incubator? I
would really like that.

Chris


Am 06.03.19, 09:15 schrieb "Julian Feinauer" :


Hi all,

perhaps some may find this email too early (as we are still in the process
of doing a Release) but I want to ask / discuss about how we plan to do
releases in the future.
Up till now, they were were infrequent due to the early stage of the
project but now I think we have stabilized well, we have stable APIs and
mostly new features coming in.
One problem we had most of the time was, that we had to work on “forked
releases” because the last official release lacked (newer) features we
needed.
Thus, I suggest that we start to release more often or even on a regular
schedule (like e.g. Calcite does it) to ship the new features soon.
Also this could help us, to teach more people how to release / rm.

As we are mostly shipping features, there’s nothing speaking against doing
minor (i.e. compatible) releases which makes it really easy for users to
update.
Perhaps, we could aim for monthly releases (if we have things to release)
and already start the setup for that. I am really eager to get the PLC4X-88
(Triggered Scraper) merged and then shipped!
Next would then be 0.3.2 in early April.

What do you think of that concrete and more general?

Julian

PS.: If we move forward with graduation the release process is also
becoming a bit easier, as there’s only one vote necessary (and no longer
the second vote from the IPMC)

Re: [DISCUSS] Major refactoring of the "Fields" API

[Tim Mitsch]

Hi everybody

The scraper is not really S7 specific as the sources can be entered via 
connection-string and the regarding fields as well. We yet only tested 
functionality with S7 devices because priority has been the highest.
The only thing that is S7 specific right now is the S7_TRIGGER i introduced 
with my pull-request because we needed something like that for that case. So 
after exchange with Chris i reworked my code to be a bit more trigger-like, the 
result can been seen in PR and i think soon in develop ... it's good to make it 
more generic as discussed in PR and i made two jira issues fort hat.
Btw refactoring of fields as started by Julian is also a part oft he puzzle ... 
we are getting better and better each day.

Best
Tim 


Am 07.03.19, 12:27 schrieb "Andreas Oswald" :

Hi there, 

from my maybe ignorant point of view, I also don’t understand why a feature 
like the scraper (as I have understood it) should be specific for a special 
automation family. I´d think that such ideas as reacting on a trigger or doing 
something on timed trigger basis is pretty basic and straightforward from the 
view of getting automation tasks done, so why should it be something special 
for e.g. S7 just because it was first implemented with a special S7 task in 
mind? 

Just my two cents

Take care 

Andreas

 

> Am 07.03.2019 um 09:46 schrieb Christofer Dutz 
:
> 
> Hi Julian,
> 
> the new Scraper is S7 specific? Was the old one too? Just asking, cause I 
don't really like the idea of having protocol-specific tools as it's the whole 
point of PLC4X to be unspecific.
> 
> Regarding the other topics ... I sort of couldn't immediately wrap my 
head around that ... could you maybe do a branch where you have your proposed 
changes (doesn't have to work) ... so we can see the difference? 
> I guess we can understand much easier what you have in mind that way.
> 
> But in general I think it's a good idea to support structures (Are you 
thinking of structures the way they are handled in C ... where there's simply 
an array of bytes and the "struct" lays a pattern/template/stencil on that and 
allows to to access individual fields.
> I think this would be a great feature ... especially as we could use this 
for automatic optimizations of request (automatically generate a struct if this 
is more efficient then loading individual fields on their own).
> 
> Chris
> 
> 
> 
> Am 07.03.19, 09:21 schrieb "Julian Feinauer" 
:
> 
>Hi all,
> 
>I think PLC4X is pretty stable and major right now and we currently 
have two main points of improvement. First, is the generative driver topics 
which is “driven” by chris mostly.
>The other direction is to add new drivers.
> 
>But there is one thing in the API which I do not like (and which is 
not very good from usability standpoint) and this is the “Fields” API.
>I think we made a big step forward with the last refactoring we did 
(from Java Types to “Custom Types”).
> 
>Currently PlcField is a Merker interface which bytes us on some cross 
cutting concerns.
>E.g. Tims implementation of the Triggered Scraper (PLC4X-88) is 
currently S7 specific, because he needs to get some information about the 
(parsed) Field.
> 
>Furthermore, when getting a Response, the BaseDefaultFieldItem 
Interface is quite a Killer.
> 
> 
> 
>So I suggest to do a (major) internal refactoring of both these 
(related) sides.
> 
>More concrete I propose:
> 
> 
> 
>PlcField:
> 
>After parsing, each Driver should report (via PlcField) what he knows 
about the Field, like the Datatype (see comment below about primitive and non 
primitive types).
> 
>Perhaps we can evene extend this to StructFields, i.e. a Field which 
is build on a sequence of (aligned) “primitive” Fields (although I’m unsure 
about the latter).
> 
> 
> 
> 
>BaseDefaultFieldItem:
>I propose to Model the Array, List or Map behavior differently than 
with all these getters.
>I would propose to have several subclasses with Methods like
>isArray()
>isList()
>isMap()
>and suitable getters (untyped)
>get()
>get(int)
>getMap(key)
>and typed
>getBoolean()
>…
> 
>This could be done very similar then the RelDataType in Calcite 
[1](except that we would add getters).
> 
>Perhaps, in the same refactoring we could even introduce a 
“PreparedField” or something, which would mean that there was already a round 
trip to the PLC and the field is “valid”, i.e. will not lead to an exception 
like “unknown address” or something.
>This is something we currently handle pretty bad in the scraper (as we 
do not differentiate between parsing exceptions 

[jira] [Created] (PLC4X-90) TriggeredScraper: Improve Testcoverage and Refactoring of Code

[Tim Mitsch (JIRA)]

Tim Mitsch created PLC4X-90:
---

 Summary: TriggeredScraper: Improve Testcoverage and Refactoring of 
Code
 Key: PLC4X-90
 URL: https://issues.apache.org/jira/browse/PLC4X-90
 Project: Apache PLC4X
  Issue Type: Improvement
Reporter: Tim Mitsch
 Fix For: 0.4.0


e.g. refactoring of start-procedure of trigger ... see ToDos in code linked to 
this topic



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PLC4X-89) Make Triggers for TriggeredScraper more generic

[Tim Mitsch (JIRA)]

Tim Mitsch created PLC4X-89:
---

 Summary: Make Triggers for TriggeredScraper more generic
 Key: PLC4X-89
 URL: https://issues.apache.org/jira/browse/PLC4X-89
 Project: Apache PLC4X
  Issue Type: Improvement
Reporter: Tim Mitsch
 Fix For: 0.4.0


suggestion from [~julian.feinauer] Using Composite Pattern



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: S7 read multiple variables

[Tim Mitsch]

Hello Gunther

This bug is known and we fixed it already in development branch.
The problem is not the amount of variables rather than one-byte variables like 
BOOL,BYTE,USINT, ... - Simens uses a filling-byte when acquiring a single 
one-byte request
Right now we have the bugfix-release 0.3.1 as RC1 in vote, so you can try using 
a checkout development-branch from GitHub or just wait a few days until vote is 
finished and the version is available on MavenCentral.
Or you can use the staging-repository by integrating that in your pom and 
change plc4x-version to 0.3.1: 
https://repository.apache.org/content/repositories/orgapacheplc4x-1008

Best
Tim

Am 06.03.19, 13:40 schrieb "Gunther Gruber" :

I try to read multiple variables synchronous from a S7-1500 and get a 
exception. I use the code from the hello world example. When i split up the 
variables into smaller units like 5-8 it works. any suggestion on this? Is 
there a limit to the number of variables?

Gunther


String vars = 
"%Q73:WORD,%Q75:WORD,%I73:WORD,%I75:WORD,%I74:WORD,%I77:WORD,%F81.1:BOOL,%Q82:REAL,%F86:INT,%F89:REAL,%I40:INT,%Q2.5:BOOL,%Q3:INT,%I66:WORD,%Q20:REAL,%I61:WORD,%Q25:WORD,%I58.0:BOOL,%F1:BYTE,%F1.0:BOOL,%F1.1:BOOL,%F1.2:BOOL,%F1.3:BOOL,%F28.0:BOOL,%I58:WORD,%F0.7:BOOL,%F0.6:BOOL,%F0.5:BOOL,%F0.4:BOOL,%F0.3:BOOL,%F0.2:BOOL,%F0.1:BOOL,%F0.0:BOOL,%F0:BYTE";

for (String item : splitVariables(vars)){
  variables.add(item);
}


460 [main] INFO com.ida.moira.collector.plc4j.PLCCollectorOperatorTest  - 
Synchronous request ...
487 [nioEventLoopGroup-2-1] WARN io.netty.channel.DefaultChannelPipeline  - 
An exceptionCaught() event was fired, and it reached at the tail of the 
pipeline. It usually means the last handler in the pipeline did not handle the 
exception.
io.netty.handler.codec.DecoderException: java.lang.NullPointerException
at 
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:98)
at 
org.apache.plc4x.java.s7.netty.S7Protocol.channelRead(S7Protocol.java:410)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at 
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
at 
io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at 
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
at 
io.netty.handler.codec.ByteToMessageCodec.channelRead(ByteToMessageCodec.java:103)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at 
io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1434)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:965)
at 
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
 

[jira] [Created] (PLC4X-88) Implement Triggered Scraper

[Tim Mitsch (JIRA)]

Tim Mitsch created PLC4X-88:
---

 Summary: Implement Triggered Scraper
 Key: PLC4X-88
 URL: https://issues.apache.org/jira/browse/PLC4X-88
 Project: Apache PLC4X
  Issue Type: New Feature
Affects Versions: 0.4.0
Reporter: Tim Mitsch
Assignee: Tim Mitsch
 Fix For: 0.4.0


Right now only scheduled scraping is possible.

Scraping shall be enabled for more trigger events, starting with a comparision 
to a read-out-value from S7



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Apache PLC4X (Incubating) 0.3.1 RC1

[Tim Mitsch]

+1 (binding)

All checks performed:
* Checked out using the new tooling: OK
* Checked signatures: OK
* Checked the zip correctly unpacks to the expected directory structure: OK
* verify the existence of DISCLAIMER, LICENSE, NOTICE, README, RELEASE_NOTES: OK
* Checked the contents of DISCLAIMER, LICENSE, NOTICE, README, RELEASE_NOTES: OK
* Built from sources (including tests) according to instructions in README: OK
* All tests pass: OK

I encountered the following issue that should be no problem:

gpg: Korrekte Signatur von "Julian Feinauer " [unbekannt]
gpg: alias "[jpeg image of size 8797]" [unbekannt]
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg:  Es gibt keinen Hinweis, daß die Signatur wirklich dem 
vorgeblichen Besitzer gehört.
Haupt-Fingerabdruck  = ADBD 428C B5BF 6C9F FC77  B907 C336 E014 3A55 3B89
-

Best
Tim

Am 05.03.19, 12:29 schrieb "Julian Feinauer" :

+1 (binding)

Checks performed:
- Checked out using the new tooling: OK
- Checked signatures: OK
- [RM] Checked signature is from a valid Apache signature referencing a 
valid Apache-Email address: OK
gpg: Korrekte Signatur von "Julian Feinauer " 
[ultimativ]
- Checked the zip correctly unpacks to the expected directory structure: OK
- [RM] Checked the "incubating" in the name of the artifacts: OK
- verify the existence of DISCLAIMER, LICENSE, NOTICE, README, 
RELEASE_NOTES: OK
- [RM] Check the RC README and RELEASE_NOTES matches that of the source 
bundle: OK
- Checked the contents of DISCLAIMER, LICENSE, NOTICE, README, 
RELEASE_NOTES: OK
- Built from sources (including tests) according to instructions in README: 
OK
. [RM] Check content of rat.txt: OK (Site images and PCAP(NG) files are 
only binaries)
- All tests pass: OK

Best
Julian

Am 05.03.19, 12:11 schrieb "Julian Feinauer" :

Apache PLC4X (Incubating) 0.3.1 has been staged under [2] and it’s time 
to vote
on accepting it for release.  All Maven artifacts are available under 
[1].
If approved we will seek final release approval from the IPMC.
Voting will be open for 72hr.

A minimum of 3 binding +1 votes and more binding +1 than binding -1
are required to pass.

Release tag: release/0.3.1
Hash for the release tag: 7852b6d78a2b4c36ecf0f7c902816131e339adff

Per [3] "Before voting +1 [P]PMC members are required to download
the signed source code package, compile it as provided, and test
the resulting executable on their own platform, along with also
verifying that the package meets the requirements of the ASF policy
on releases."

You can achieve the above by following [4].

[ ]  +1 accept (indicate what you validated - e.g. performed the non-RM 
items in [4])
[ ]  -1 reject (explanation required)


[1] 
https://repository.apache.org/content/repositories/orgapacheplc4x-1008
[2] 
https://dist.apache.org/repos/dist/dev/incubator/plc4x/0.3.1-incubating/rc1
[3] https://www.apache.org/dev/release.html#approving-a-release
[4] 
https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release

[S7-Scraper| scraper functionality extension

[Tim Mitsch]

Hi everybody,

we currently have an application where a block of data from an S7 device shall 
only be acquired when a specific variable has been set to a specific value.
So for this application we need something like a triggered scraping job rather 
then the existing scheduled scraping job.
Right now i’m developping a solution for that, based on the existing scraper, 
in a forked repo ... will this be something thats interesting as well for 
productive repo?

What do you think or any ideas for further scraper functionality?

Best
Tim

Re: Preparation of Release 0.3.1

[Tim Mitsch]

Hey guys

Sorry that has been my fault ... i fixed that issue but did not resolved the 
jira ticket.
I have done that just few minutes ago with relation the regarding commit.

So from my side we could start for preparing 0.3.1 RC

Best 
Tim 


Am 28.02.19, 12:33 schrieb "Christofer Dutz" :

Cause that would have been the last open S7 bug that's been reported and is 
still open...

Chris

Am 28.02.19, 12:33 schrieb "Christofer Dutz" :

Not quite sure, if we should also have a look at:
PLC4X-78 Write operations seem to fail

Am 28.02.19, 12:03 schrieb "Julian Feinauer" 
:

Thanks Chris,

@tim: Can you clarify or give your feedback about PLC4X-83?


Julian


Von: Christofer Dutz 
Gesendet: Donnerstag, 28. Februar 2019 11:27:17
An: dev@plc4x.apache.org
Betreff: Re: Preparation of Release 0.3.1

Hi Julian,

I thought Tim had fixed that ... as he did that I didn't want to 
close it as this way I would have been the person who resolved it ;-)

Chris



Am 28.02.19, 10:19 schrieb "Julian Feinauer" 
:

Hey,


did anyone do any further checks for our planned release 0.3.1.

The two TIckets PLC4X-82 and PLC4X-84 are marked as done but 
PLC4X-83 (When requesting an odd number of bytes in payload the fill-byte is 
not handled correctly) is still open.


@cdutz, @tim

Both of you did most of the work... can you give an update?

I would like to end this soon and prepare an RC.


Best

Julian

Re: [DISCUSS] Send Jira emails to dev@plc4x.apache.org?

[Tim Mitsch]

+1


Am 26.02.19, 17:15 schrieb "Andreas Oswald" :


+1

Von: Christofer Dutz 
Gesendet: Dienstag, 26. Februar 2019 16:21
An: dev@plc4x.apache.org
Betreff: Re: [DISCUSS] Send Jira emails to dev@plc4x.apache.org?

Ok ... I took the liberty of creating the iss...@plc4x.apache.org list ... 
will probably take up to a day for it to be created.
As soon as that's done I'll create an issue for setting up the Jira 
notifications.

Chris

Am 26.02.19, 16:15 schrieb "Otto Fowler" :

+1


On February 26, 2019 at 08:06:24, Julian Feinauer (
j.feina...@pragmaticminds.de) wrote:

+1

Am 26.02.19, 13:29 schrieb "Christofer Dutz" 
:

In the new Apache Training podling someone came up with something cool 
...

How about sending Issue creates to dev@ and issues@ and all updates and
closes just to @issues
This way we are informed for something new coming in and are not 
spammed by
updates?

I really like this idea

Chris

Am 22.02.19, 16:32 schrieb "Christofer Dutz" 
:

Thanks for that ... I just added it to the pom.xml ... should appear in 
a
while.

Chris

Am 22.02.19, 14:40 schrieb "Otto Fowler" :

It isn’t listed on the website is it?


On February 22, 2019 at 04:26:08, Christofer Dutz 
(christofer.d...@c-ware.de)

wrote:

Well we already have a commits@ mailing list ;-)

But if we had a separate list, I would prefer that than directing 
things to
commits@.

We intentionally didn't have more than dev and commits as the incubator
likes it's podlings to have a reduced number of lists at the start as 
this
way community is better built. Otherwise you'll just feel lost in empty
lists.

Chris

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


From: Julian Feinauer 
Sent: Friday, February 22, 2019 9:38:48 AM
To: dev@plc4x.apache.org
Subject: Re: [DISCUSS] Send Jira emails to dev@plc4x.apache.org?

Hi,

I agree with Chris... I would start with our dev@ list and monitor it 
and
go over to a separate list when necessary.

Julian

Am 22.02.19, 09:29 schrieb "Tim Mitsch" 
:

I don’t know the amount of work that has to be spent on creating a new 
list
for those kind of notifications.
But with this project continouusly growing and growing maybe also
ticket-count and stuff like this will rise, so i can understand Otto
concern.
If it’s possible (and could be done in a tolerable amount of time) i 
like
the idea of splitting mailing-list into dev-stuff (feature and 
discussions)
and orga-stuff (issues,commits)

Best
Tim

Von: Christofer Dutz 
    Datum: Freitag, 22. Februar 2019 um 09:14
An: "dev@plc4x.apache.org" , Tim Mitsch <
t.mit...@pragmaticindustries.de>
Betreff: Re: [DISCUSS] Send Jira emails to dev@plc4x.apache.org?

I think it's all a volume thing ... I agree that github code review 
emails
in some projects (Apache Commons) are super annoying, however do we only
have a hand full of new issues per month. Didn't think it's worth 
creating
a dedicated List for that. And we can always create it and redirect as 
soon
as it starts really becoming annoying ... But what do the others think?
Rather create a separate list?
Chris
Outlook für Android<https://aka.ms/ghei36> herunterladen

____________
From: Otto Fowler 
Sent: Thursday, February 21, 2019 4:31:09 PM
To: dev@plc4x.apache.org; Tim Mitsch
Subject: Re: [DISCUSS] Send Jira emails to dev@plc4x.apache.org?

-1 most projects have an issues@ list for this type of thing.
Dev lists that have build, jira, github stuff spamming them stink.

Does this incubator have:
issues@
    commits@
users@
setup or is it just dev@?





On February 21, 2019 at 06:22:52, Tim Mitsch (
t.mit...@pragmaticindustries.de) wrote:

+1

It would be good to be noticed.

Am 21.02.19, 11:32 schrieb "Christofer Dutz" 
:

Hi all,

today I noticed again that a user seems to have created an issue and we
didn’t get notified. I would like to have infra configure our project to
automatically send emails to the dev list …
If there are no objections, I would request this ASAP.

Chris

Re: [DISCUSS] Send Jira emails to dev@plc4x.apache.org?

[Tim Mitsch]

I don’t know the amount of work that has to be spent on creating a new list for 
those kind of notifications.
But with this project continouusly growing and growing maybe also ticket-count 
and stuff like this will rise, so i can understand Otto concern.
If it’s possible (and could be done in a tolerable amount of time) i like the 
idea of splitting mailing-list into dev-stuff (feature and discussions) and 
orga-stuff (issues,commits)

Best
Tim

Von: Christofer Dutz 
Datum: Freitag, 22. Februar 2019 um 09:14
An: "dev@plc4x.apache.org" , Tim Mitsch 

Betreff: Re: [DISCUSS] Send Jira emails to dev@plc4x.apache.org?

I think it's all a volume thing ... I agree that github code review emails in 
some projects (Apache Commons) are super annoying, however do we only have a 
hand full of new issues per month. Didn't think it's worth creating a dedicated 
List for that. And we can always create it and redirect as soon as it starts 
really becoming annoying ... But what do the others think? Rather create a 
separate list?
Chris
Outlook für Android<https://aka.ms/ghei36> herunterladen


From: Otto Fowler 
Sent: Thursday, February 21, 2019 4:31:09 PM
To: dev@plc4x.apache.org; Tim Mitsch
Subject: Re: [DISCUSS] Send Jira emails to dev@plc4x.apache.org?

-1 most projects have an issues@   list for this type of thing.
Dev lists that have build, jira, github stuff spamming them stink.

Does this incubator have:
issues@
commits@
users@
setup or is it just dev@?





On February 21, 2019 at 06:22:52, Tim Mitsch (
t.mit...@pragmaticindustries.de) wrote:

+1

It would be good to be noticed.

Am 21.02.19, 11:32 schrieb "Christofer Dutz" :

Hi all,

today I noticed again that a user seems to have created an issue and we
didn’t get notified. I would like to have infra configure our project to
automatically send emails to the dev list …
If there are no objections, I would request this ASAP.

Chris

Re: [DISCUSS] Send Jira emails to dev@plc4x.apache.org?

[Tim Mitsch]

+1

It would be good to be noticed.

Am 21.02.19, 11:32 schrieb "Christofer Dutz" :

Hi all,

today I noticed again that a user seems to have created an issue and we 
didn’t get notified. I would like to have infra configure our project to 
automatically send emails to the dev list …
If there are no objections, I would request this ASAP.

Chris

Re: Strange build errors

[Tim Mitsch]

Hi Chris

Thanks for the info ... i first thought it was because of my fix to odd-size 
arrays - but verify succeeded without any problems.
I'm neither build nor jenkins pro ... so i can't help much - but if i see 
anything i'll report.

Best
Tim

Am 20.02.19, 23:00 schrieb "Christofer Dutz" :

Hi all,

I just noticed that again one of my commits failed even if I did the full 
build.
An investigation showed that it exited somewhere in the API module.
I have seen this occasionally and I think it might be related to concurrent 
builds.
Cause I get these random failures whenever we have concurrent build jobs 
running.

Would really like to find out the reason for this.

So if you see any failures with the build complaining about some exit code, 
try simply re-running the build.

Chris

Re: plc4j Marker not implemented

[Tim Mitsch]

Hallo everybody and welcome Gunther

I think the NPE parsing "%M0.4:BOOL" is coming from the one-byte data-type bug 
that we have already fixed in develop branch.

@Gunther:
This isn't the only variable that you are scanning, are u? In v0.3.0, i think 
ur using, you should get no error if you only scan this address, could you 
verify this?

@all
Using the current develop-branch i could not reproduce the NPE on request of 
"%M0.4:BOOL" alone as well in combination with other values, testing with our 
S71500, so i think we should starting to prepare 0.3.1 bugfix release. The odd 
length bug for arrays of one-byte base types is also fixed in develop.

Best
Tim

Am 20.02.19, 19:39 schrieb "Julian Feinauer" :

Thanks for the research Chris. Could you prepare a release in Jira and link 
the tickets to keep things organized?
I'm still missing the mojo :)

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: Re: plc4j Marker not implemented
Von: Christofer Dutz
An: dev@plc4x.apache.org,Gunther Gruber
Cc:

Hi Julian,

yes we should add that to the list of things for a 0.3.1 release.
I just did some research on this and it seems to be a naming-thing.

As I found here [1] it seems as if Flags / Markers are used synonym.

@Gunther Gruber could you please give an address a try and use "F" instead 
of "M" (and omit any "D" or "W" behind the first letter)?

If this works, we should however adjust the parser as it looks as if these 
marker-addresses also have the "D" and "W" (but not the "X" suffixes the DB 
addresses have).
So it seems that "%MW3" is a valid address ... I guess the parser would 
currently not parse "%FW3".
I know the "W" is redundant if we provide the type at the end, but I would 
not like to force on our users to know that.

Chris


[1] 
https://www.citect.schneider-electric.com/scada/clearscada/help/2017/Content/SimaticS7DriverGuide/ConfiguretheScanProperties.htm

Am 20.02.19, 19:00 schrieb "Julian Feinauer" :

Hi,

first, thanks for the report Gunther.
Should we consider this as a bug and also consider it for the 0.3.1 
release?
Would like to have that soon to allow us to focus on new thinks.

Did anyone file a Jira for that?
@tim: did you make some progress with the "odd byte" fix?

Julian

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: Re: plc4j Marker not implemented
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:

Hi Gunther,

I double checked and indeed the memory area enum is missing a constant 
for markers. I'll investigate the issue.

Thanks for reporting and thanks for giving Plc4x a try :-)

Chris

Outlook f?r Android herunterladen


From: Gunther Gruber 
Sent: Wednesday, February 20, 2019 5:26:33 PM
To: dev@plc4x.apache.org
Subject: plc4j Marker not implemented

Hello,

i use plc4j for a small project demo. Thx for developing this driver, 
must have take some time to figure out the details to talk to these machines :)

I took the hello world example and try to read some variables from a 
S7-1500, however I get a null pointer exception. I guess only %I and %Q is 
implemented.

The variable i try to read is:

%M0.4:BOOL


java.util.concurrent.ExecutionException: java.lang.NullPointerException
at 
java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
at 
java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
at 
collector.plc4j.PLCCollectorOperatorTest.initPLC(PLCCollectorOperatorTest.java:100)
at 
collector.plc4j.PLCCollectorOperatorTest.Test(PLCCollectorOperatorTest.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.

Re: Bugfix-Release 0.3.1

[Tim Mitsch]

Hi Chris

You have been completly right.
I just made a test vs our device where reading an odd and an even number of 
array-items (based on one-byte base type e.g. USINT).
Reading a odd number this resulted in filling byte, whereas an even number did 
not have a filling byte.

I think we should implement this as well (dependent on configuration i could 
cause some NPEs on reading) and validate behavior by a significant test. 

Best
Tim


Am 13.02.19, 16:12 schrieb "Christofer Dutz" :

Hi Tim,

I thought of reading an array of 3 bytes ... that should produce an odd 
number of bytes in the response (Don't forget to request another item after 
that)

Chris


Am 13.02.19, 15:55 schrieb "Tim Mitsch" :

Hi Chris

I thought about that too, but did not evaluate if something like this 
can happen.
You mean something like odd-adress to even padding?!
But the SPS is answering the base types requested isn't it, so there is 
no basic type that has an odd length in byte except BYTE, USINT and all other 
one byte long datatypes, or am i wrong.
But before preparing BugFix-RC we'll should check this, you're right. 
Later this day i can support with this.

Best
Tim


Am 13.02.19, 15:42 schrieb "Christofer Dutz" 
:

Hi all,

last night I had another idea what we should check before 
triggering a new release ...
I was sort of wondering why we have to add an empty byte if the 
data is only one byte long.
Then I thought ... could it be that the device is using a WORD 
padding? So it expects every part to be of an even number of bytes.
If that was the case, if we read for example 3 bytes, we would get 
an additional fill byte too. 
Then we should verify and eventually fix this before pushing out a 
0.3.1.

Chris


Am 11.02.19, 19:26 schrieb "Julian Feinauer" 
:

Hey all,

I agree we should do this of 0.3 branch. Would be a good 
exercise with cherry picking and so.

I suggest that I do the rm and Tim does all steps with me 
{we're working together}.

Is this okay Tim or do you want to do everything on your own.?

Julian

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: Re: Bugfix-Release 0.3.1
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:

Hi Tim,

I have no objections ... I guess you are in possession of a 
signed key? (I think us signing stuff at the Finka ... but if not, Julian could 
always sign your key)
And having more people able to release is never a bad thing.

If this bug is causing you to have problems in production, I 
agree and we should send a bugfix version (That would be released from the 
existing 0.3 branch).
So the bugfix would have to be cherry-picked into that branch. 
I doubt it qualifies for a full release (0.4.0) as the only other significant 
change would have been my work on the dynamic driver.

Chris


    
    
Am 11.02.19, 16:13 schrieb "Tim Mitsch" 
:

Hallo everybody

As we just released version 0.3, we found (and already 
fixed within develop-branch – thanks to Chris) a bug regarding exchange of 
One-Byte-long variables within S7, where sometimes a filling Byte hast o be 
used.
This maybe leads to some strange behavior and it maybe be 
better to release a bugfix version where this bug is fixed.
Julian (thanks for taking care about release of 0.3) as 
leader and supervisor and me (I have to learn it as well) would care about the 
release process for this bugfix release.

What do you think?

Best
Tim

Re: Bugfix-Release 0.3.1

[Tim Mitsch]

Hi Chris

I thought about that too, but did not evaluate if something like this can 
happen.
You mean something like odd-adress to even padding?!
But the SPS is answering the base types requested isn't it, so there is no 
basic type that has an odd length in byte except BYTE, USINT and all other one 
byte long datatypes, or am i wrong.
But before preparing BugFix-RC we'll should check this, you're right. Later 
this day i can support with this.

Best
Tim


Am 13.02.19, 15:42 schrieb "Christofer Dutz" :

Hi all,

last night I had another idea what we should check before triggering a new 
release ...
I was sort of wondering why we have to add an empty byte if the data is 
only one byte long.
Then I thought ... could it be that the device is using a WORD padding? So 
it expects every part to be of an even number of bytes.
If that was the case, if we read for example 3 bytes, we would get an 
additional fill byte too. 
Then we should verify and eventually fix this before pushing out a 0.3.1.

Chris


Am 11.02.19, 19:26 schrieb "Julian Feinauer" :

Hey all,

I agree we should do this of 0.3 branch. Would be a good exercise with 
cherry picking and so.

I suggest that I do the rm and Tim does all steps with me {we're 
working together}.

Is this okay Tim or do you want to do everything on your own.?

Julian

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: Re: Bugfix-Release 0.3.1
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:

Hi Tim,

I have no objections ... I guess you are in possession of a signed key? 
(I think us signing stuff at the Finka ... but if not, Julian could always sign 
your key)
And having more people able to release is never a bad thing.

If this bug is causing you to have problems in production, I agree and 
we should send a bugfix version (That would be released from the existing 0.3 
branch).
So the bugfix would have to be cherry-picked into that branch. I doubt 
it qualifies for a full release (0.4.0) as the only other significant change 
would have been my work on the dynamic driver.

Chris



    
    Am 11.02.19, 16:13 schrieb "Tim Mitsch" 
:

Hallo everybody

As we just released version 0.3, we found (and already fixed within 
develop-branch – thanks to Chris) a bug regarding exchange of One-Byte-long 
variables within S7, where sometimes a filling Byte hast o be used.
This maybe leads to some strange behavior and it maybe be better to 
release a bugfix version where this bug is fixed.
Julian (thanks for taking care about release of 0.3) as leader and 
supervisor and me (I have to learn it as well) would care about the release 
process for this bugfix release.

What do you think?

Best
Tim

Bugfix-Release 0.3.1

[Tim Mitsch]

Hallo everybody

As we just released version 0.3, we found (and already fixed within 
develop-branch – thanks to Chris) a bug regarding exchange of One-Byte-long 
variables within S7, where sometimes a filling Byte hast o be used.
This maybe leads to some strange behavior and it maybe be better to release a 
bugfix version where this bug is fixed.
Julian (thanks for taking care about release of 0.3) as leader and supervisor 
and me (I have to learn it as well) would care about the release process for 
this bugfix release.

What do you think?

Best
Tim

Re: [DISCUSS] Adding a "ping" method to the API?

[Tim Mitsch]

+1 from my side.
Ping is low cost and avoids unneeded connection traffic


Am 06.02.19, 11:31 schrieb "Christofer Dutz" :

Hi all,

Having had the same problem several times now, I think we might consider 
solving this …

I’ve had the problem that potential customers say things like “We 
communicate via S7” … well the thing is they have an S7, but that doesn’t mean 
the communication is done in the native S7 protocol. It could be:

  *   Profinet
  *   S7Pluss (New TIA Version of the protocol)
  *   Modbus
  *   OPC-UA

So what I would like to do, is to add a “ping” method to the connection, 
that would allow to try connecting to a given PLC. With this we could write 
code that for example tries all supported protocols for a given IP address and 
reports which ones are enabled.
We could also write a PLC scanner that pings an IP range and tries pinging 
the different protocols for each responsive IP address … this would be a huge 
help for people using PLC4X applications in the field …

What do you think?

We sort of would need to define “ping” operations for each connection type 
(Like the “SELECT 1” SQL query in JDBC and JPA).

Chris

[S7] Coding-Session in Nürtingen - Friday 2019/02/15

[Tim Mitsch]

Hi everybody

Next Friday 2019/02/15 we will perform a PLC4X coding session with focus on S7 
communication in our buero in Nuertingen (PRAGMATIC INDUSTRIES GmbH, Zementwerk 
1, 72622 Nürtingen, Germany).
Everybody who likes to join is welcome - pizza, drinks and snacks will be 
provided by us.
If wanted we can also start the day before in the afternoon if someone wants to 
join earlier.

It will be good if everybody who likes to join will send a short notice – but 
if someone joins spontaneously he or she is welcome as well 😊

For any question you can also contact me via mail:
t.mit...@pragmaticindustries.de

Best
Tim

[S7] (manual) testing vs physical device

[Tim Mitsch]

Hi everybody

We had a discussion about how to ensure correct functionality vs a physical S7 
device as we just noticed some minor bugs during testing along arrays.
I setuped a TIA programm with different datablocks containing different 
datatypes, arrays and so on; i will extend this with anything that could be 
interesting and nessesary.
If this is interesting we could provide this programm for reproduction within 
repo, if allowed or by download if not.
Furthermore repo can be extended by manual test that can be executed against a 
certain device with the given blocks.

What do you think about that?

Best
Tim

AW: Integration of OPC UA into PLC4X

[Tim Mitsch]

Hey all

Sounds good - lets have a look for a suitable date with respect to our daily 
work.
What about Fr 2018/12/14?

Best
Tim

Am 04.12.18, 16:54 schrieb "Julian Feinauer" :

Hey Matthias,

it would also be a pleasure for us, if you woudl help us : )
But, back to topic... what about a small pre-christmas one day hackathon in 
Nürtingen for OPC UA?
We could provide all that’s necessary ("Glühwein", cookies, ...).

@Matthis, @Tim, what do you think?

Of course all others are also invited to join!!

Julian

Am 04.12.18, 10:38 schrieb "Strljic, Matthias Milan" 
:

Hi Tim, 

+ 1

That would be greate! 
If i could help you there a bit it would be a pleasure for me ;)


Greetings
Matthias Strljic, M.Sc.
--
Interesse an Steuerungstechnik aus der Cloud und anderen Innovationen?
Informieren Sie sich über die Stuttgarter Innovationstage vom 12.-13. 
Februar 2019.
https://www.stuttgarter-innovationstage.de
--
Universität Stuttgart
Institut für Steuerungstechnik der Werkzeugmaschinen und 
Fertigungseinrichtungen (ISW)

Seidenstraße 36
70174 Stuttgart
GERMANY

Tel: +49 711 685-84530
Fax: +49 711 685-74530

E-Mail: matthias.strl...@isw.uni-stuttgart.de
Web: http://www.isw.uni-stuttgart.de


-Ursprüngliche Nachricht-
Von: Tim Mitsch [mailto:t.mit...@pragmaticindustries.de] 
Gesendet: Samstag, 24. November 2018 11:51
An: dev@plc4x.apache.org
Betreff: Integration of OPC UA into PLC4X


Hallo everybody

As more and more great features have been and will be integrated into 
PLC4X something like OPC-UA server functionality (e.g. based on Eclipse 
Milo<https://github.com/eclipse/milo>) would be a great feature for usage in 
various environments and fast implementing visualization according to free OPC 
UA clients.

Task has been addressed by Julian within 
https://issues.apache.org/jira/browse/PLC4X-51 and has been clearified by Chris 
due to legal-reasons (https://issues.apache.org/jira/browse/PLC4X-7 ).

If nobody had yet started working on these topics I would give the 
(milo) integration a try and will start working on OPC UA integration.

What do you think?

Best
Tim

AW: SPS IPC Drives summary

[Tim Mitsch]

Hey Chris,

Like Julian I also want to thank you for the interesting report on what happend 
on SPS IPC Drives.
I think we are on a good way and all that motivates me and all the other 
co-workers within PLC4X spent more time for increasing the features for PLC4X.
Furthermore i think more or less all manufactures (earlier or later) will 
realize that there will be no way beside open-source especially as they what to 
sell their Hardware and programming SW predomaninatly.

We would have had nothing yet when you did not start your work on PLC4X ... 
thank you so much for that and all your work - every good idea needs some 
clever head to push i forward!

So lets move on and let Toddy conquer the (industrial and since Code.Retreat 
also consumer) world.

Best
Tim 


Am 28.11.18, 03:14 schrieb "Julian Feinauer" :

Hi Chris,

thank you for that nice report (I won't make it to Nürnberg this year).
It is great to hear that, also the "big players" seem to start to shift 
their points of view (well, you cant turn around an aircraft carrier in one 
day). 
We see that movement already with many of our small and medium-sized 
clients but I didn't expect it to happen that "fast" in this area (even 
expensive PLCs have like 4MB RAM... and yes, I'm talking about MEGA bytes).
Did you get any "deeper" interest from anybody in the sense of "hey of 
course we can hack some days together with you and implement our protocol"?

And I agree that this is perhaps (not yet) a result of our work as the 
PLC4X community but I would definitely say that this is, at least to a certain 
amount a result of YOUR work. Of your vision, of all your visits to fairs, 
talks, presentations. This is my personal opinion but I'm pretty sure there are 
more people here on the list thinking the same way.

So let's keep going on rocking this shit... there's a whole industry 
waiting to be evangelized to the OSS side of things.

Julian


Am 27.11.18, 18:47 schrieb "Christofer Dutz" :

Hi all,

today I had my second visit at the SPS IPC Drives in Nürnberg. It’s one 
of the world’s biggest (if not even THE biggest industry fair on everything in 
industrial automation).
Last year people treated me with sort of an attitude of being someone 
with really strange point of view. This was with the first line of PLC4X being 
about 1-2 months old.
This year people (even sales guys) seem to have gotten used to the 
industry. I wouldn’t say that’s our work, but at least things seem to be 
changing.

Also I visited all the big PLC vendors for my annual “Who’s an Ass and 
who’s not” ranking ;-) Last year most of the companies in business for over 50 
years were on the red side of the list.

This year, the worst I got was a: “But we don’t want you to do that” 
from Rockwell.

On the Opposite side, I have to mention: Beckhoff and Phoenix Contact. 
These were extremely kind and seem to have adopted and embraced the idea of 
Open-Source.

The other ones that were “just nice to me” were:

  *   Festo
  *   Rexroth
  *   Codesys
  *   ABB
  *   Schneider Electric

Also I had a talk with one of the Profinet guys.
The takeaway from that was, that we don’t need to become a member in 
order to be allowed to implement a driver. We can simply purchase the Specs.
If we want to actively communicate (Active-Mode Driver) we need a 
vendor-id, but we could get that for free too. I was asked to contact the guy I 
talked with after the fair and he would send me all needed information. The 
only thing we are not allowed to do without a membership is use the ProfiNet 
Logo … guess I can live with that.

So guess there’s nothing preventing us from implementing a ProfiNet 
driver. :-)

Also did I do a quick summary of which protocols we would need to talk 
to the different types of PLCs:

  *   Rockwell: Ethernet/IP
  *   Phoenix Contact: Ethernet/IP, Modbus-TCP, ProfiNet
  *   Festo: Ethernet/IP, Modbus-TCP, ProfiNet
  *   Pilz: Modbus-TCP
  *   Beckhoff: ADS. OPC-UA
  *   Rexroth: OCI (MLPI for PLCs, EAL for Drives)
  *   Codesys: Codesys (Profinet, OPC-UA, Modbus, via plugins)
  *   ABB: Codesys, Profinet, Modbus-TCP
  *   Schneider Electric: Modbus-TCP (simple PLCs), EtherNet/IP 
(Controll Systems)

So it seems implementing ProfiNet, Codesys and OPC-UA would increase 
the coverage even more.

So far my summary …

Chris

Integration of OPC UA into PLC4X

[Tim Mitsch]

Hallo everybody

As more and more great features have been and will be integrated into PLC4X 
something like OPC-UA server functionality (e.g. based on Eclipse 
Milo) would be a great feature for usage in 
various environments and fast implementing visualization according to free OPC 
UA clients.

Task has been addressed by Julian within 
https://issues.apache.org/jira/browse/PLC4X-51 and has been clearified by Chris 
due to legal-reasons (https://issues.apache.org/jira/browse/PLC4X-7 ).

If nobody had yet started working on these topics I would give the (milo) 
integration a try and will start working on OPC UA integration.

What do you think?

Best
Tim

Re: Meetup in Nürtingen on 20.09.2018

[Tim Mitsch]

Hi everybody

Just a short notice for all participants coming to Nürtingen by car.
Directly at our buero are only few parking lots, which are usually occupied 
early in the morning.
So the best solution is using some parking lots at the center next to us (100m 
walking). It is stated, that parking is not allowed there for people not 
visiting the center ... but nobody cares about that, we usually also park our 
cars over there. See link below.

I'm also really looking forward to meet all of u __

Link to parking possibilities and PI building:
https://advice.pragmaticindustries.com/parking_and_entry_pi.png

Best
Tim

Am 18.09.18, 09:55 schrieb "Julian Feinauer" :

Hi Andreas,

great, thanks for your message.
Looking forward to meet you!

Julian

Am 18.09.18, 09:53 schrieb "Uschold Andreas" 
:

Hi Julian,

we didn't participate in the doodle, but we would like to join, too.
I will take a colleague with me. 

Best regards
Andreas

-Ursprüngliche Nachricht-
Von: Julian Feinauer [mailto:j.feina...@pragmaticminds.de] 
Gesendet: Mittwoch, 12. September 2018 23:38
An: dev@plc4x.apache.org
Betreff: [EXT] Meetup in Nürtingen on 20.09.2018

Hi everybody,

I am really looking forward to our first PLC4X meetup next week in 
Nürtingen.
In this mail you find all necessary information.

Where?

pragmatic industries GmbH
Zementwerk 1
72622 Nürtingen

From the main-street look for the spiral-stair.
Go up the spiral-stair and you are there!

When?

Date: 20.09.2018
Start: 10 am
End: whenever we are fine

What?

The main goals are to get in contact with each other and learn 
something about the past and the current state of PLC4X and, of course, discuss 
about the future.
We have a rough agenda with provided Talks which is

* Chris: History and Wrap-Up of PLC4X

* Chris: Architecture and Deep-Dive PLC4X and new API

* (Hopefully) Matthias Strlijc: Efforts with PLC Communication at 
University Stuttgart

* Julian: "Industrie 4.0" and use cases for PLC4X in the german 
"Mittelstand"

* Discussion: Where is PLC4X currently used or will be soon? Feedbacks 
from Industry.

* Discussion: How to we proceed in the future, what could be next 
features & milestones and Releases

Everybody is invited to participate in the meetup / workshop or bring 
other contributions to it.
I am really excited about this workshop.

Julian

PS.: One small organizational note, it would be good if we know a rough 
estimate about the participants. Currently we assume all people who 
participated in the doodle to be coming and no one else. So if anybody else 
likes to join us (or cannot due to other duties) please give me a short notice.

Re: [VOTE] Change the format of the S7 Adresses

[Tim Mitsch]

+1 Tim

That will make it more intuitive for the TIA-side users



Am 03.08.2018 um 15:41 schrieb Christofer Dutz 
mailto:christofer.d...@c-ware.de>>:

Hi all,

We have recently discussed changing something to allow defining not only the 
Java-Side type, but also the expected type in the PLC.
For the S7 protocol, we propose to extend the “S7Address” by an additional 
plcType. While at it we would also like to change the general format of the S7 
Address Strings
To the format used in Siemens’ TIA Portal software as this simplifies the 
communication between automation engineers and software developers.

We would append the plcType to these addresses in the address string and a 
fully qualified S7 Resource would look like this:

%DB3.DBX0.0:BOOL (Boolean variable in the DataBlock DB3 which consumes one bit 
of memory)
%DB3.DBW2:INT (Int variable in DataBlock DB3 which consumes one word (two byte) 
of memory)
%DB3.DBD4:REAL (Real variable in DataBlock DB3 which consumes one double-word 
(four bytes) of memory)
%DB3.DBB8:BYTE (Byte variable in DataBlock DB3 which consumes one byte of 
memory)
%I0.1:BOOL (Boolean input variable referring to the second digital input of the 
PLC)
%M0.3:BOOL (Boolean output variable referring to the fourth digital output of 
the PLC)
%IW64:DOUBLE (Double input variable referring to one of the analog inputs of 
the PLC)

Please Vote in this thread and take discussions into the [DISCUSS] thread.

Chris


PS: I know this is overkill, but I want to practice voting on stuff here with 
you ;-)