from:"Stefano Bossi"

Re: [NOTICE] Enabled OWASP plugin ... automated CVE checks ...

2021-12-27 Thread Stefano Bossi


That's a great news!

Security is always important in Industry.

Thanks,
S.


On 26/12/21 18:51, Christofer Dutz wrote:

Hi all,

as I was a bit unsure if we really got all the potentially vulnerable log4j 
versions excluded (yes, we did). I enabled the owasp dependency checker.
Also did I update all dependencies to the latest released versions as 
especially most of the integration modules just received fixed versions.

When enabling the owasp maven plugin we now continuously check our build 
against the official CVE registry. If a dependency is detected for which any 
non-minor vulnerabilities exist, the build automatically failed.

I did need a bit of tweaking of some dependencies, but now I was able to set 
the score to 4 which means that we don't have any dependency in our tree that 
has any medium or severe issues reported.

The first build might take a bit longer, as the plugin must download the bug 
databases for the last years, but this only has to be done once.

Chris






OpenPGP_signature
Description: OpenPGP digital signature

Re: [DISCUSS] Permanently move our monthly video call?

2021-12-21 Thread Stefano Bossi


+1

S.


On 20/12/21 17:22, Cesar Garcia wrote:

+1

El lun, 20 dic 2021 a las 4:08, Christofer Dutz ()
escribió:


Hi all,

I would like to move our monthly call to the first Tuesday of the month
(same time)

If we leave it, I will not be participating on events that happen to be on
even week numbers.


Chris


Holen Sie sich Outlook für Android







OpenPGP_signature
Description: OpenPGP digital signature

[jira] [Created] (PLC4X-279) nioEventLoopGroup thread proliferation

2021-02-01 Thread Stefano Bossi (Jira)

Stefano Bossi created PLC4X-279:
---

 Summary: nioEventLoopGroup thread proliferation
 Key: PLC4X-279
 URL: https://issues.apache.org/jira/browse/PLC4X-279
 Project: Apache PLC4X
  Issue Type: Bug
  Components: Driver-S7
Affects Versions: 0.8.0
Reporter: Stefano Bossi
 Attachments: Screenshot 2021-02-01 at 09.19.07.png, Screenshot 
2021-02-01 at 09.20.42.png, Threads total 2021-01-31 at 11.34.15.png, Threads 
total 2021-02-01 at 09.14.02.png

Dear developers,

I did a stability test with the plc4x 0.8.0 and pool2 library.

The test is just reading continuously a couple of DataBlock from a S7 Siemens 
1200 PLC.

During the test I have used VisualVM like profiler to inspect the use of the 
Heap and the threads and I found something strange.

The test runs for a couple of days and I have sampled the threads in a couple 
of snapshot found that the number of running nioEventLoopGroup thread increase 
and doesn't seems to be bounded by a limit.

These are the total of the Threads of the applications at 2021-01-31 at 
11.34.15; the total number is 246 and the number of nioEventLoopGroup is 192

!Threads total 2021-01-31 at 11.34.15.png|width=568,height=332!

These are the total of the Threads of the applications at 2021-02-01 at 
09.14.02; the total number is 358 and the number of nioEventLoopGroup is 305

!Threads total 2021-02-01 at 09.14.02.png|width=549,height=309!

 Form the profiler two of this thread are:

!Screenshot 2021-02-01 at 09.19.07.png|width=530,height=210!

!Screenshot 2021-02-01 at 09.20.42.png|width=539,height=271!  

 

It seems a leakage and seems a dangerous one. 

I think the problem is inside the pool2 library but I am note sure. 

What do you think? 

Regards,

S.

 

 



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

[jira] [Created] (PLC4X-278) Double Reading Error

2021-01-31 Thread Stefano Bossi (Jira)

Stefano Bossi created PLC4X-278:
---

 Summary: Double Reading Error
 Key: PLC4X-278
 URL: https://issues.apache.org/jira/browse/PLC4X-278
 Project: Apache PLC4X
  Issue Type: Bug
  Components: Driver-S7
Affects Versions: 0.8.0
 Environment: Client on Linux box:
Linux RevPi33574 4.9.76-rt60-v7+ #1 SMP PREEMPT RT Tue, 12 Mar 2019 15:19:36 
+0100 armv7l GNU/Linux

PLC Siemens S7 1200 (CPU 1214C DC/DC/DC Firmware Version V1.0)
Reporter: Stefano Bossi
 Attachments: trace-01-30-10-20-28-1611998428-drop01.pcap, 
trace-01-30-10-20-28-1611998428-drop01.png

Dear developers,

I think I have found the reason of some disconnection from the PLC (Siemens 
1200 S7) I see on the logs of a software I am writing. Let me explain the 
scenario. 
The software reads a lot of data from the PLC a polling variable and a complete 
DataBlock I am using a Raspberry like a client an a Siemens S7 1200 PLC. 
The reading are usually fine but randomly I have an error in the logs coming 
from low level Driver. 
I am using 0.8.0-SNAPSHOT coming from 
[pool2|https://github.com/apache/plc4x/tree/feature/integrate-pool2] 
experimental feature.

The error I read on the logs is: 


{code:txt}
2021-01-30 10:27:58 WARN  CachedDriverManager - Watchdog detected a long 
borrowed connection, will be forcefully closed!
2021-01-30 10:27:58 WARN  CachedDriverManager - Broken Connection was returned, 
although it is not borrowed, currently.
2021-01-30 10:27:58 ERROR DbFetcher - Time out Exception in reading DataBlock
java.util.concurrent.TimeoutException: null
at 
java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886) 
~[?:?]
at 
java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021) ~[?:?]
at 
it.fox.chronos.plc.observers.DbFetcher.onObservableChanged(DbFetcher.java:92) 
[chronos-0.0.3.jar:0.0.3]
at it.fox.chronos.plc.Poller.notifyObservers(Poller.java:177) 
[chronos-0.0.3.jar:0.0.3]
at it.fox.chronos.plc.Poller.run(Poller.java:105) 
[chronos-0.0.3.jar:0.0.3]
at java.lang.Thread.run(Thread.java:834) [?:?]
2021-01-30 10:27:58 INFO  PlcDriverManager - Instantiating new PLC Driver 
Manager with class loader jdk.internal.loader.ClassLoaders$AppClassLoader@c77c2e
2021-01-30 10:27:58 WARN  CachedPlcConnection - Request finished with 
exception. Reporting Connection as Broken
java.util.concurrent.CancellationException: null
at 
java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2396) 
~[?:?]
at 
org.apache.plc4x.java.utils.connectionpool2.CachedPlcConnection.lambda$wrapWithTimeout$0(CachedPlcConnection.java:84)
 ~[plc4j-connection-cache-0.8.0-SNAPSHOT.jar:0.8.0-SNAPSHOT]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
 ~[?:?]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) 
~[?:?]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) 
~[?:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
2021-01-30 10:27:58 INFO  PlcDriverManager - Registering available drivers...
2021-01-30 10:27:58 WARN  CachedDriverManager - Broken Connection was returned, 
although it is not borrowed, currently.
2021-01-30 10:27:58 INFO  PlcDriverManager - Registering driver for Protocol s7 
(Siemens S7 (Basic))
2021-01-30 10:27:58 INFO  TcpChannelFactory - Configuring Bootstrap with 
Configuration{local-rack=1, local-slot=1, remote-rack=0, remot-slot=0, 
pduSize=1024, maxAmqCaller=8, maxAmqCallee=8, controllerType='null'}
2021-01-30 10:27:58 INFO  S7ProtocolLogic - S7 Driver running in ACTIVE mode.
{code}

At the first sight it seems that a connection became stale and the watchdog 
drop it but I think this is just the effect of an error on the wire.
Here is the screenshot of the capture on the wire (I attach the capture to the 
ticket too).

 !trace-01-30-10-20-28-1611998428-drop01.png! 

At 2021-01-30 10:27:53.899233 there's a request for 7 variables in the DB2: 

{code:java}
Frame 9: 157 bytes on wire (1256 bits), 157 bytes captured (1256 bits)
Ethernet II, Src: KUNBUS_01:5e:53 (c8:3e:a7:01:5e:53), Dst: SiemensN_02:19:4c 
(00:1c:06:02:19:4c)
Internet Protocol Version 4, Src: 192.168.1.190, Dst: 192.168.1.192
Transmission Control Protocol, Src Port: 36240, Dst Port: 102, Seq: 94, Ack: 
736, Len: 103
TPKT, Version: 3, Length: 103
ISO 8073/X.224 COTP Connection-Oriented Transport Protocol
S7 Communication
Header: (Job)
Parameter: (Read Var)
Function: Read Var (0x04)
Item count: 7
Item [1]: (DB 2.DBX 3238.0 INT 47)
Item [2]: (DB 2.DBX 7348.0 BIT 1)
Item [3]: (DB 2

[jira] [Created] (PLC4X-277) Double Reading Error

2021-01-31 Thread Stefano Bossi (Jira)

Stefano Bossi created PLC4X-277:
---

 Summary: Double Reading Error
 Key: PLC4X-277
 URL: https://issues.apache.org/jira/browse/PLC4X-277
 Project: Apache PLC4X
  Issue Type: Bug
  Components: Driver-S7
Affects Versions: 0.8.0
 Environment: Client on Linux box:
Linux RevPi33574 4.9.76-rt60-v7+ #1 SMP PREEMPT RT Tue, 12 Mar 2019 15:19:36 
+0100 armv7l GNU/Linux

PLC Siemens S7 1200 (CPU 1214C DC/DC/DC Firmware Version V1.0)
Reporter: Stefano Bossi
 Attachments: trace-01-30-10-20-28-1611998428-drop01.pcap, 
trace-01-30-10-20-28-1611998428-drop01.png

Dear developers,

I think I have found the reason of some disconnection from the PLC (Siemens 
1200 S7) I see on the logs of a software I am writing. Let me explain the 
scenario. 
The software reads a lot of data from the PLC a polling variable and a complete 
DataBlock I am using a Raspberry like a client an a Siemens S7 1200 PLC. 
The reading are usually fine but randomly I have an error in the logs coming 
from low level Driver. 
I am using 0.8.0-SNAPSHOT coming from 
[pool2|https://github.com/apache/plc4x/tree/feature/integrate-pool2] 
experimental feature.

The error I read on the logs is: 


{code:txt}
2021-01-30 10:27:58 WARN  CachedDriverManager - Watchdog detected a long 
borrowed connection, will be forcefully closed!
2021-01-30 10:27:58 WARN  CachedDriverManager - Broken Connection was returned, 
although it is not borrowed, currently.
2021-01-30 10:27:58 ERROR DbFetcher - Time out Exception in reading DataBlock
java.util.concurrent.TimeoutException: null
at 
java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886) 
~[?:?]
at 
java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021) ~[?:?]
at 
it.fox.chronos.plc.observers.DbFetcher.onObservableChanged(DbFetcher.java:92) 
[chronos-0.0.3.jar:0.0.3]
at it.fox.chronos.plc.Poller.notifyObservers(Poller.java:177) 
[chronos-0.0.3.jar:0.0.3]
at it.fox.chronos.plc.Poller.run(Poller.java:105) 
[chronos-0.0.3.jar:0.0.3]
at java.lang.Thread.run(Thread.java:834) [?:?]
2021-01-30 10:27:58 INFO  PlcDriverManager - Instantiating new PLC Driver 
Manager with class loader jdk.internal.loader.ClassLoaders$AppClassLoader@c77c2e
2021-01-30 10:27:58 WARN  CachedPlcConnection - Request finished with 
exception. Reporting Connection as Broken
java.util.concurrent.CancellationException: null
at 
java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2396) 
~[?:?]
at 
org.apache.plc4x.java.utils.connectionpool2.CachedPlcConnection.lambda$wrapWithTimeout$0(CachedPlcConnection.java:84)
 ~[plc4j-connection-cache-0.8.0-SNAPSHOT.jar:0.8.0-SNAPSHOT]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
 ~[?:?]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) 
~[?:?]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) 
~[?:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
2021-01-30 10:27:58 INFO  PlcDriverManager - Registering available drivers...
2021-01-30 10:27:58 WARN  CachedDriverManager - Broken Connection was returned, 
although it is not borrowed, currently.
2021-01-30 10:27:58 INFO  PlcDriverManager - Registering driver for Protocol s7 
(Siemens S7 (Basic))
2021-01-30 10:27:58 INFO  TcpChannelFactory - Configuring Bootstrap with 
Configuration{local-rack=1, local-slot=1, remote-rack=0, remot-slot=0, 
pduSize=1024, maxAmqCaller=8, maxAmqCallee=8, controllerType='null'}
2021-01-30 10:27:58 INFO  S7ProtocolLogic - S7 Driver running in ACTIVE mode.
{code}

At the first sight it seems that a connection became stale and the watchdog 
drop it but I think this is just the effect of an error on the wire.
Here is the screenshot of the capture on the wire (I attach the capture to the 
ticket too).

 !trace-01-30-10-20-28-1611998428-drop01.png! 

At 2021-01-30 10:27:53.899233 there's a request for 7 variables in the DB2: 

{code:java}
Frame 9: 157 bytes on wire (1256 bits), 157 bytes captured (1256 bits)
Ethernet II, Src: KUNBUS_01:5e:53 (c8:3e:a7:01:5e:53), Dst: SiemensN_02:19:4c 
(00:1c:06:02:19:4c)
Internet Protocol Version 4, Src: 192.168.1.190, Dst: 192.168.1.192
Transmission Control Protocol, Src Port: 36240, Dst Port: 102, Seq: 94, Ack: 
736, Len: 103
TPKT, Version: 3, Length: 103
ISO 8073/X.224 COTP Connection-Oriented Transport Protocol
S7 Communication
Header: (Job)
Parameter: (Read Var)
Function: Read Var (0x04)
Item count: 7
Item [1]: (DB 2.DBX 3238.0 INT 47)
Item [2]: (DB 2.DBX 7348.0 BIT 1)
Item [3]: (DB 2

Re: AW: [DISCUSS] Drop Logstash support?

2021-01-26 Thread Stefano Bossi


I think you are right.

Regards,
S.


On 26/01/21 09:56, Christofer Dutz wrote:


Hi Stefano,

well a colleague of mine built the Logstash adapter as first step of a 
plan to build a Machine-Beats Integration for Elastic. This would have 
been something comparable to Kafka Connect for the Kafka-World.


Well Elastic never did the promissed second step. And as they now have 
this aweful new license, I actually don’t want to put my time in this.


Chris

*Von:* Stefano Bossi 
*Gesendet:* Dienstag, 26. Januar 2021 09:35
*An:* dev@plc4x.apache.org
*Betreff:* Re: [DISCUSS] Drop Logstash support?

Hi,

logstash is basicalli a "translator" for Elastic Search, it's mostly 
used for parsing an unstructured data source, like a log from syslog 
and extract all the needed information to feed ElasticSearch with 
beefy Json.


I think that with plc4x it's a better approach to build the json 
directly an sent them to Elastic directly, it's pretty easy; achieving 
the plus of not dealing with an another machine for Logstash.


I think that dropping the support for Elastic is good because not so 
useful in our scenario.


Regards,
S.

On 25/01/21 21:55, Christofer Dutz wrote:

Hi all

Right now, on Windows machines the build of the logstash plugin seems to 
work when run in IntelliJ, but fail when run on the commandline. This seems to 
be a known issue and probably wasn't detected yet as most PLC4X devs don't work 
on Windows and I just recently started to.

Given the Elastic folks recently changed their license to one that is 
definitely incompatible, if we update, I am not willing to invest time into 
this and would rather like to remove the logstash support alltogether.

What do you think?

Chris





OpenPGP_signature
Description: OpenPGP digital signature

Re: [DISCUSS] Drop Logstash support?

2021-01-26 Thread Stefano Bossi


Hi,

logstash is basicalli a "translator" for Elastic Search, it's mostly 
used for parsing an unstructured data source, like a log from syslog and 
extract all the needed information to feed ElasticSearch with beefy Json.


I think that with plc4x it's a better approach to build the json 
directly an sent them to Elastic directly, it's pretty easy; achieving 
the plus of not dealing with an another machine for Logstash.


I think that dropping the support for Elastic is good because not so 
useful in our scenario.


Regards,
S.


On 25/01/21 21:55, Christofer Dutz wrote:

Hi all

Right now, on Windows machines the build of the logstash plugin seems to work 
when run in IntelliJ, but fail when run on the commandline. This seems to be a 
known issue and probably wasn't detected yet as most PLC4X devs don't work on 
Windows and I just recently started to.

Given the Elastic folks recently changed their license to one that is 
definitely incompatible, if we update, I am not willing to invest time into 
this and would rather like to remove the logstash support alltogether.

What do you think?

Chris







OpenPGP_signature
Description: OpenPGP digital signature

[jira] [Created] (PLC4X-262) Error in reading Array

2020-12-10 Thread Stefano Bossi (Jira)

Stefano Bossi created PLC4X-262:
---

 Summary: Error in reading Array
 Key: PLC4X-262
 URL: https://issues.apache.org/jira/browse/PLC4X-262
 Project: Apache PLC4X
  Issue Type: Bug
  Components: Driver-S7
Affects Versions: 0.8.0
Reporter: Stefano Bossi


Dear developer,

after the commit [ Improve the reading of S7 Date and Time 
handling|https://github.com/apache/plc4x/commit/9c25eb319f5c4e9192d4fc6a4abf5bedc3838c0c]
 I have found that reading array raise an exception. 
The code I am trying to use is the HelloWord:

{code:java}
try (PlcConnection conn = manager.getConnection(connectionString)) {
if (conn.isConnected()){
PlcReadRequest.Builder builder = conn.readRequestBuilder();
builder.addItem("PollingValue", "%DB2:126.0:INT[2]");
// builder.addItem("PollingValue", "%DB2:114.0:INT");
PlcReadRequest readRequest = builder.build();
PlcReadResponse syncResponse = readRequest.execute().get(2000, 
TimeUnit.MILLISECONDS);
printResponse(syncResponse);
} else {
logger.info("PLC is not connected, let's try to connect");
conn.connect();
}
}
{code}

and the exception is: 

{noformat}
[INFO ] 10:58:21.274 
org.apache.plc4x.java.transport.tcp.TcpChannelFactory.configureBootstrap() - 
Configuring Bootstrap with Configuration{local-rack=1, local-slot=1, 
remote-rack=0, remot-slot=0, pduSize=1024, maxAmqCaller=8, maxAmqCallee=8, 
controllerType='null'}
[INFO ] 10:58:21.412 
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.onConnect() - S7 
Driver running in ACTIVE mode.
[ERROR] 10:58:23.656 it.fox.datapicker.HelloPlc4x.main() - Timeout exception 
fired
java.util.concurrent.TimeoutException: null
at 
java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1957) 
~[?:?]
at 
java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2092) ~[?:?]
at it.fox.datapicker.HelloPlc4x.main(HelloPlc4x.java:43) [main/:?]
{noformat}

If I try with the simple 
{code:java}
builder.addItem("PollingValue", "%DB2:114.0:INT");
{code}

Everything works. 

Regards,
Stefano Bossi





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

Re: AW: Test on plc4x-pool2

2020-11-27 Thread Stefano Bossi


ok,

l'et's wait Julian, who is probably doing his father work :-D

Anyway, Netty is really hard to fine tune!

Regards,
S.


On 27/11/2020 08:52, Christofer Dutz wrote:

Hi Stefano,

I really wonder how often I will end up looking up this stupid 
java.lang.UnsupportedOperationException …
I have to admit that for me this is one of the most annoying things with Netty 
:-/

But seeing the actual error is coming from the pool, I guess Julian should 
probably help you with this, I doubt this is something I can help with.

Chris

Von: Stefano Bossi 
Datum: Donnerstag, 26. November 2020 um 23:16
An: dev@plc4x.apache.org 
Betreff: Test on plc4x-pool2
Hi Julian,

I have tried to integrate in my code the new pool library you wrote but without 
success, I have probably did something wrong.

I am started trying to work with the HelloPlc4x


 PlcDriverManager manager = new PlcDriverManager();

 PlcDriverManager cached = new CachedDriverManager(connectionString, 
() -> {

 try {

 return manager.getConnection(connectionString);

 } catch (PlcConnectionException e) {

 e.printStackTrace();

 }

 return null;

 });

 PlcConnection plcConnection = 
cached.getConnection(connectionString);

 // Check if this connection support reading of data.

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

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

 return;

 }





integrate When the code reach the line plcConnection.getMetadata().canRead()

  integrate an exception is rised:



bash-3.2$  /Users/fox/.jenv/versions/openjdk64-13.0.2/bin/java 
-agentlib:jdwp=transport=dt_socket,server=n,suspend=y,address=localhost:51806 
-ea -Dfile.encoding=UTF-8 
@/var/folders/p1/lb5grfpn3tncxdtrptqq9fw4gp/T/cp_dkqa6x1i5h7yfdha7mxc6sn5h.argfile
 it.fox.datapicker.HelloPlc4x

2020-11-26 23:09:30,677 main DEBUG Apache Log4j Core 2.14.0 initializing 
configuration 
XmlConfiguration[location=/Users/fox/Documents/workspace/2020-06-30 - 
HelloPlc4x/bin/main/log4j2.xml]

2020-11-26 23:09:30,684 main DEBUG Installed 1 script engine

Warning: Nashorn engine is planned to be removed from a future JDK release

2020-11-26 23:09:30,885 main DEBUG Oracle Nashorn version: 13.0.2, language: 
ECMAScript, threading: Not Thread Safe, compile: true, names: [nashorn, 
Nashorn, js, JS, JavaScript, javascript, ECMAScript, ecmascript], factory 
class: jdk.nashorn.api.scripting.NashornScriptEngineFactory

2020-11-26 23:09:30,885 main DEBUG PluginManager 'Core' found 122 plugins

2020-11-26 23:09:30,885 main DEBUG PluginManager 'Level' found 0 plugins

2020-11-26 23:09:30,889 main DEBUG PluginManager 'Lookup' found 16 plugins

2020-11-26 23:09:30,890 main DEBUG Building Plugin[name=layout, 
class=org.apache.logging.log4j.core.layout.PatternLayout].

2020-11-26 23:09:30,899 main DEBUG PluginManager 'TypeConverter' found 26 
plugins

2020-11-26 23:09:30,911 main DEBUG PatternLayout$Builder(pattern="[%-5level] %d{HH:mm:ss.SSS} %logger{36}.%M() - %msg%n", 
PatternSelector=null, Configuration(/Users/fox/Documents/workspace/2020-06-30 - HelloPlc4x/bin/main/log4j2.xml), Replace=null, 
charset="null", alwaysWriteExceptions="null", disableAnsi="null", noConsoleNoAnsi="null", 
header="null", footer="null")

2020-11-26 23:09:30,911 main DEBUG PluginManager 'Converter' found 44 plugins

2020-11-26 23:09:30,912 main DEBUG Building Plugin[name=appender, 
class=org.apache.logging.log4j.core.appender.ConsoleAppender].

2020-11-26 23:09:30,917 main DEBUG ConsoleAppender$Builder(target="SYSTEM_OUT", follow="null", direct="null", 
bufferedIo="null", bufferSize="null", immediateFlush="null", ignoreExceptions="null", PatternLayout([%-5level] 
%d{HH:mm:ss.SSS} %logger{36}.%M() - %msg%n), name="Console", Configuration(/Users/fox/Documents/workspace/2020-06-30 - 
HelloPlc4x/bin/main/log4j2.xml), Filter=null, ={})

2020-11-26 23:09:30,919 main DEBUG Starting OutputStreamManager 
SYSTEM_OUT.false.false

2020-11-26 23:09:30,919 main DEBUG Building Plugin[name=appenders, 
class=org.apache.logging.log4j.core.config.AppendersPlugin].

2020-11-26 23:09:30,922 main DEBUG createAppenders(={Console})

2020-11-26 23:09:30,922 main DEBUG Building Plugin[name=AppenderRef, 
class=org.apache.logging.log4j.core.config.AppenderRef].

2020-11-26 23:09:30,926 main DEBUG createAppenderRef(ref="Console", 
level="TRACE", Filter=null)

2020-11-26 23:09:30,926 main DEBUG Building Plugin[name=root, 
class=org.apache.logging.log4j.core.config.LoggerConfig$RootLogger].

2020-11-26 23:09:30,927 main DEBUG createLogger(additivity="false", level="DEBUG", 
includeLocation

Test on plc4x-pool2

2020-11-26 Thread Stefano Bossi


Hi Julian,

I have tried to integrate in my code the new pool library you wrote but 
without success, I have probably did something wrong.


I am started trying to work with the HelloPlc4x

||PlcDriverManager manager = new PlcDriverManager(); PlcDriverManager 
cached = new CachedDriverManager(connectionString, () -> { try { return 
manager.getConnection(connectionString); } catch (PlcConnectionException 
e) { e.printStackTrace(); } return null; }); PlcConnection plcConnection 
= cached.getConnection(connectionString); // Check if this connection 
support reading of data. if (!plcConnection.getMetadata().canRead()) { 
logger.error("This connection doesn't support reading."); return; }| |

|integrate When the code reach the line 
|||plcConnection.getMetadata().canRead()||
 |integrate|  an exception is rised:

bash-3.2$  /Users/fox/.jenv/versions/openjdk64-13.0.2/bin/java 
-agentlib:jdwp=transport=dt_socket,server=n,suspend=y,address=localhost:51806 
-ea -Dfile.encoding=UTF-8 
@/var/folders/p1/lb5grfpn3tncxdtrptqq9fw4gp/T/cp_dkqa6x1i5h7yfdha7mxc6sn5h.argfile
 it.fox.datapicker.HelloPlc4x
2020-11-26 23:09:30,677 main DEBUG Apache Log4j Core 2.14.0 initializing 
configuration 
XmlConfiguration[location=/Users/fox/Documents/workspace/2020-06-30 - 
HelloPlc4x/bin/main/log4j2.xml]
2020-11-26 23:09:30,684 main DEBUG Installed 1 script engine
Warning: Nashorn engine is planned to be removed from a future JDK release
2020-11-26 23:09:30,885 main DEBUG Oracle Nashorn version: 13.0.2, language: 
ECMAScript, threading: Not Thread Safe, compile: true, names: [nashorn, 
Nashorn, js, JS, JavaScript, javascript, ECMAScript, ecmascript], factory 
class: jdk.nashorn.api.scripting.NashornScriptEngineFactory
2020-11-26 23:09:30,885 main DEBUG PluginManager 'Core' found 122 plugins
2020-11-26 23:09:30,885 main DEBUG PluginManager 'Level' found 0 plugins
2020-11-26 23:09:30,889 main DEBUG PluginManager 'Lookup' found 16 plugins
2020-11-26 23:09:30,890 main DEBUG Building Plugin[name=layout, 
class=org.apache.logging.log4j.core.layout.PatternLayout].
2020-11-26 23:09:30,899 main DEBUG PluginManager 'TypeConverter' found 26 
plugins
2020-11-26 23:09:30,911 main DEBUG PatternLayout$Builder(pattern="[%-5level] %d{HH:mm:ss.SSS} %logger{36}.%M() - %msg%n", 
PatternSelector=null, Configuration(/Users/fox/Documents/workspace/2020-06-30 - HelloPlc4x/bin/main/log4j2.xml), Replace=null, 
charset="null", alwaysWriteExceptions="null", disableAnsi="null", noConsoleNoAnsi="null", 
header="null", footer="null")
2020-11-26 23:09:30,911 main DEBUG PluginManager 'Converter' found 44 plugins
2020-11-26 23:09:30,912 main DEBUG Building Plugin[name=appender, 
class=org.apache.logging.log4j.core.appender.ConsoleAppender].
2020-11-26 23:09:30,917 main DEBUG ConsoleAppender$Builder(target="SYSTEM_OUT", follow="null", direct="null", 
bufferedIo="null", bufferSize="null", immediateFlush="null", ignoreExceptions="null", PatternLayout([%-5level] 
%d{HH:mm:ss.SSS} %logger{36}.%M() - %msg%n), name="Console", Configuration(/Users/fox/Documents/workspace/2020-06-30 - 
HelloPlc4x/bin/main/log4j2.xml), Filter=null, ={})
2020-11-26 23:09:30,919 main DEBUG Starting OutputStreamManager 
SYSTEM_OUT.false.false
2020-11-26 23:09:30,919 main DEBUG Building Plugin[name=appenders, 
class=org.apache.logging.log4j.core.config.AppendersPlugin].
2020-11-26 23:09:30,922 main DEBUG createAppenders(={Console})
2020-11-26 23:09:30,922 main DEBUG Building Plugin[name=AppenderRef, 
class=org.apache.logging.log4j.core.config.AppenderRef].
2020-11-26 23:09:30,926 main DEBUG createAppenderRef(ref="Console", 
level="TRACE", Filter=null)
2020-11-26 23:09:30,926 main DEBUG Building Plugin[name=root, 
class=org.apache.logging.log4j.core.config.LoggerConfig$RootLogger].
2020-11-26 23:09:30,927 main DEBUG createLogger(additivity="false", level="DEBUG", 
includeLocation="null", ={Console}, ={}, Configuration(/Users/fox/Documents/workspace/2020-06-30 - 
HelloPlc4x/bin/main/log4j2.xml), Filter=null)
2020-11-26 23:09:30,929 main DEBUG Building Plugin[name=loggers, 
class=org.apache.logging.log4j.core.config.LoggersPlugin].
2020-11-26 23:09:30,930 main DEBUG createLoggers(={root})
2020-11-26 23:09:30,931 main DEBUG Configuration 
XmlConfiguration[location=/Users/fox/Documents/workspace/2020-06-30 - 
HelloPlc4x/bin/main/log4j2.xml] initialized
2020-11-26 23:09:30,932 main DEBUG Starting configuration 
XmlConfiguration[location=/Users/fox/Documents/workspace/2020-06-30 - 
HelloPlc4x/bin/main/log4j2.xml]
2020-11-26 23:09:30,932 main DEBUG Started configuration 
XmlConfiguration[location=/Users/fox/Documents/workspace/2020-06-30 - 
HelloPlc4x/bin/main/log4j2.xml] OK.
2020-11-26 23:09:30,933 main DEBUG Shutting down OutputStreamManager 
SYSTEM_OUT.false.false-1
2020-11-26 23:09:30,933 main DEBUG OutputStream closed
2020-11-26 23:09:30,933 main DEBUG Shut down OutputStreamManager 
SYSTEM_OUT.false.false-1, all resources released: true
2020-11-26 23:09:30,934 main DEBUG Appender DefaultConsole-1

Re: AW: Starting to heat up the engine on the release-train ...

2020-11-26 Thread Stefano Bossi


Ok,

optimizer from the terrace is for sure good code :-D :-D :-D

Thanks,
S.


On 26/11/2020 22:25, Christofer Dutz wrote:

Hi Stefano,

I could probably just go into the 0.6.0 branch and copy part of my code from 
there over. I did address the issue once before, but didn’t want to do it again 
as we were instead planning on building a more generic optimizer, but as that’s 
probably not going to come soon, I’ll try to port my old code.

Guess it depends on the weather. If it’s good, I’ll be working on my terrace, 
but if it sucks like today, I might get it done this weekend.

Chris



Von: Stefano Bossi 
Datum: Donnerstag, 26. November 2020 um 22:19
An: dev@plc4x.apache.org 
Betreff: Re: Starting to heat up the engine on the release-train ...
Thanks Chris,

I wrote a very ugly code to manage the stuff outside your library but I am not 
able to port the code inside the library.

Anyway thanks.
S.

On 25/11/2020 19:35, Christofer Dutz wrote:

Hi Stefano,



unfortunately I haven’t addressed this … but I probably should soon.

No idea if I’ll manage to get it in 0.8.0, but I’ll have a look at it.



Chris



Von: Stefano Bossi <mailto:stefano.bo...@gmail.com>

Antworten an: <mailto:dev@plc4x.apache.org>

Datum: Mittwoch, 25. November 2020 um 16:53

An: <mailto:dev@plc4x.apache.org>

Betreff: Re: Starting to heat up the engine on the release-train ...



Hi,



just to know, the bug about the DB request size bigger than the maximum frame 
size is fixed in this version?



I mean the one here in Jira: https://issues.apache.org/jira/browse/PLC4X-241



Just to know.



Thanks,

S.



On 24/11/2020 22:47, Christofer Dutz wrote:



Hi all







I just did some final cleanups on the build-tools and thing I will start a RC 
on this (but probably on Thursday).



So is there anything that you think belongs in there? Next week we can then 
start the release on the main project.







Are there any features/bugs still open that we need handled in this?







Chris


















OpenPGP_signature
Description: OpenPGP digital signature

Re: Starting to heat up the engine on the release-train ...

2020-11-26 Thread Stefano Bossi


Thanks Chris,

I wrote a very ugly code to manage the stuff outside your library but I 
am not able to port the code inside the library.


Anyway thanks.
S.


On 25/11/2020 19:35, Christofer Dutz wrote:

Hi Stefano,

unfortunately I haven’t addressed this … but I probably should soon.
No idea if I’ll manage to get it in 0.8.0, but I’ll have a look at it.

Chris

Von: Stefano Bossi 
Antworten an: 
Datum: Mittwoch, 25. November 2020 um 16:53
An: 
Betreff: Re: Starting to heat up the engine on the release-train ...

Hi,

just to know, the bug about the DB request size bigger than the maximum frame 
size is fixed in this version?

I mean the one here in Jira: https://issues.apache.org/jira/browse/PLC4X-241

Just to know.

Thanks,
S.

On 24/11/2020 22:47, Christofer Dutz wrote:

Hi all



I just did some final cleanups on the build-tools and thing I will start a RC 
on this (but probably on Thursday).

So is there anything that you think belongs in there? Next week we can then 
start the release on the main project.



Are there any features/bugs still open that we need handled in this?



Chris










OpenPGP_signature
Description: OpenPGP digital signature

Re: Starting to heat up the engine on the release-train ...

2020-11-25 Thread Stefano Bossi


Hi,

just to know, the bug about the DB request size bigger than the maximum 
frame size is fixed in this version?


I mean the one here in Jira: https://issues.apache.org/jira/browse/PLC4X-241

Just to know.

Thanks,
S.


On 24/11/2020 22:47, Christofer Dutz wrote:

Hi all

I just did some final cleanups on the build-tools and thing I will start a RC 
on this (but probably on Thursday).
So is there anything that you think belongs in there? Next week we can then 
start the release on the main project.

Are there any features/bugs still open that we need handled in this?

Chris






OpenPGP_signature
Description: OpenPGP digital signature

Re: Doing some read-tests with S7

2020-10-28 Thread Stefano Bossi

Hi Chris,

the STRING(x)[] stuff was something you implemented on the issue I have
opened a month ago or more; unfortunately my first work suck all my time
and I don't have any time to try to code for your library.

Yes the splitting issue is generalized for all the datatype and for
reading large datablock.

Sorry for that, hope to have more time in the Christmas holidays.

Thanks again for your work.

Ciao,
S.


On 25/10/2020 23:42, Christofer Dutz wrote:
> Ok ... so I fixed most of the issues.
>
> So-far the problems I need to address are the following:
>
> - When using "BOOL[]" we have to read a bit-string (byte, word, dword) 
> instead and filter out the bits that are not asked for.
> - When reading "STRING(x)[]" (limited strings), we have to split up the 
> request into multiple items as the typical array notation doesn't work.
> - When reading bit-strings the order of the bits looks the wrong way around
> - When reading bit-string arrays, I would like to concatenate the values to 
> one bit-string instead of returning lists of lists
>
> Chris
>
>
>
>
> Am 25.10.20, 21:59 schrieb "Christofer Dutz" :
>
> Hi all,
>
> in order to have some good tests for the S7 protocol, I defined a lot of 
> variables in one of the data-blocks of one of my S7 devices.
> I then created a little test program that should simply use this to read 
> all sorts of types of elements.
> With these tests I found some things:
>
>
>   *   In general all Bit-String operations, when reading arrays, produce 
> lists of lists … I think it would be cooler if for bit-strings they would 
> return one large List
>   *   STRING handling seems to be messed up again
>   *   When reading a BOOL array, it seems the S7 only returns the first 
> bit (I would have expected it to send up to 8 bits in one byte and after that 
> to add more bytes, but it’s always just one and that always just contains the 
> first bit) -> We need to translate BOOL-array reads into bit-string 
> operations which return partial lists.
>   *   Reading of DATE_AND_TIME arrays seems to be messed up as only the 
> first item is correct and the succeeding elements are always “null”
>   *   Reading of CHAR values seems messed up
>
> I’ll be working on addressing this asap
>
> Chris
>
>
>



signature.asc
Description: OpenPGP digital signature

Re: Plc4x connection reset by peer exception uncaught

2020-09-17 Thread Stefano Bossi

; > @Override
>> > public String getProtocolCode() {
>> > return "lalel-tcp";
>> > }
>> >
>> > @Override
>> > protected ProtocolStackConfigurer
>> > getStackConfigurer()
>> > {
>> > return DriverUtils.buildStackConfigurer(
>> > EthernetMessage.class, EthernetMessageIO.class,
>> > LalelProtocolLogicTcp.class,
>> ByteLengthEstimator.class
>> > );
>> > }
>> >
>> > /**
>> >  * Estimate the Length of a Packet
>> >  */
>> > public static class ByteLengthEstimator implements
>> > ToIntFunction {
>> > @Override
>> > public int applyAsInt(ByteBuf byteBuf) {
>> > if (byteBuf.readableBytes() >= 2) {
>> > return
>> > byteBuf.getUnsignedShortLE(byteBuf.readerIndex());
>> > }
>> > return -1;
>> > }
>> > }
>> >
>> > }
>> >
>> > And connection code:
>> >
>> > this.connection = driver.getConnection(connectionString);
>> >
>> > this.connection.connect();
>> >
>> >
>> > Kind regards,
>> > Vlad
>> >
>> >
>> > Kind regards,
>> > Vlad
>> >
>> > чт, 17 сент. 2020 г. в 12:09, Christofer Dutz <
>> > christofer.d...@c-ware.de>:
>> >
>> > > Hi Vlad,
>> > >
>> > > 0.8.0-SNAPSHOT is the current development version ...
>> > > we'll be releasing that as soon as we tied up some things we're
>> > currently
>> > > working on.
>> > >
>> > > Chris
>> > >
>> > >
>> > >
>> > > Am 17.09.20, 11:02 schrieb "Vladyslav Milutin" <
>> v.milu...@aegas.io>:
>> > >
>> > > Hi Stefano,
>> > >
>> > > I'm curious about the 0.8.0 version, where I can find it?
>> Since
>> > maven
>> > > repo
>> > > contains the latest version 0.7.0.
>> > >
>> > > Kind regards,
>> > > Vlad
>> > >
>> > > ср, 16 сент. 2020 г. в 17:30, Stefano Bossi <
>> > stefano.bo...@gmail.com>:
>> > >
>> > > > Hi Vlad,
>> > > >
>> > > > this seems similar to a bug fixed some time ago, I am not
>> > really
>> > > sure but
>> > > > it worth to try to use the 0.8.0 version where this fix
>> is
>> > present.
>> > > >
>> > > > You should try to build the version and here you could
>> fine
>> > some
>> > > help:
>> > > > https://plc4x.apache.org/developers/index.html
>> > > >
>> > > > Regards,
>> > > > Stefano
>> > > >
>> > > > On 16/09/2020 14:32, Vladyslav Milutin wrote:
>> > > >
>> > > > Hello guys,
>> > > >
>> > > > I'm writing to you with a hope that you can help me with
>> > exception
>> > > > handling.
>> > > > Currently after a long time connection can be reset by
>> peer.
>> > See
>> > > stacktrace
>> > > > below.
>> > > >
>> > > > I've tried to add a custom ChannelHandler which Overrides
>> > > exceptionCaught()
>> > > > and add it in Driver#initializePipeline() see code
>> below. Also
>> > has
>> > > tried to
>> > > > add a channel that can be ob

Re: Plc4x connection reset by peer exception uncaught

2020-09-16 Thread Stefano Bossi

Hi Vladyslav,

just because a I am a curious guy, why did you choose to build a custom
driver?

Do you need something special ?

Regards,
Stefano

P.S. feel free to answer: it's not your business  As said is just a
curiosity, anyone has the right to choose it's road.



On 16/09/2020 17:54, Christofer Dutz wrote:
> Hi Vladyslav,
>
> oh ... a custom driver. In that case it will definitely be tricky to help you 
> unless we can have a look at the code.
>
> Is this something you consider bringing into the PLC4X project, or something 
> that's meant to stay outside of the project?
>
> I guess this is the first time such a question has come up ;-)
>
> With integrations, I was referring to: Camel, Kafka, Edgent, NiFi, ... 
> integrations that the PLC4X provides. But I guess you answered the question 
> and you're not using any of them.
>
> The connection pool does a little more. Before returning a connection it 
> checks if it's still alive and if it's not, it creates a new one. 
>
> Chris
>
>
>
> Am 16.09.20, 17:39 schrieb "Vladyslav Milutin" :
>
> Hi Christofer,
>
> Thanks for your quick response.
> I'm using a custom driver which extends GeneratedDriverBase, for 
> connection
> I use a simple call to .connect, I know that you have PooledDriverManager,
> but it won't have the same issue if connection was reset by peer, since
> it's just look up for the specific connection?
> As
> integrations: plc4j-transport-tcp, plc4j-api, plc4j-spi, 
> plc4j-connection-pool
> and other code generation and build utils. Or by integration you mean
> frameworks? If yes, Spring Frameworks.
>
> Kind regards,
> Vlad
>
> ср, 16 сент. 2020 г. в 17:28, Christofer Dutz :
>
> > Hi Vladyslav,
> >
> > could you please tell us which driver and which version you are using?
> > Also it would be interesting if you are using any integration modules?
> >
> > Chris
> >
> > Am 16.09.20, 14:36 schrieb "Vladyslav Milutin" :
> >
> > Hello guys,
> >
> > I'm writing to you with a hope that you can help me with exception
> > handling.
> > Currently after a long time connection can be reset by peer. See
> > stacktrace
> > below.
> >
> > I've tried to add a custom ChannelHandler which Overrides
> > exceptionCaught()
> > and add it in Driver#initializePipeline() see code below. Also has
> > tried to
> > add a channel that can be obtained from DefaultNettyPlcConnection. 
> And
> > none
> > of them actualy was added to the pipeline where this exception was
> > thrown.
> >
> > plc4x version: 0.7.0
> >
> > StatckTrace:
> > 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
> > [io.netty.channel.DefaultChannelPipeline] 
> onUnhandledInboundException
> > - 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: Connection reset by peer
> >   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> >   at java.base/sun.nio.ch
> > .SocketDispatcher.read(SocketDispatcher.java:39)
> >   at 
> java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
> >   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
> >   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
> >   at java.base/sun.nio.ch
> > .SocketChannelImpl.read(SocketChannelImpl.java:358)
> >   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
> >   at
> > io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
> >   at
> >
> > 
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
> >   at
> >
> > 
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
> >   at
> >
> > 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
> >   at
> >
> > 
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
> >   at
> >
> > 
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
> >   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
> >   at
> >
> > 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> >   at
> >
> > 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> >   at
> >
> > 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> >   at java.base/java.lang.Thread.run(Thread.java:834)
> >
> > Driver#initializePipeline:
> > try {
>

Re: Plc4x connection reset by peer exception uncaught

2020-09-16 Thread Stefano Bossi

Hi,

an another suggestion is to give a try to the pooled drive manager
instead of the simple dirve manager, here you could fine some more info:
https://plc4x.apache.org/users/tools/connection-pool.html

Regards,
Stefano


On 16/09/2020 16:30, Stefano Bossi wrote:
> Hi Vlad,
>
> this seems similar to a bug fixed some time ago, I am not really sure
> but it worth to try to use the 0.8.0 version where this fix is present.
>
> You should try to build the version and here you could fine some help:
> https://plc4x.apache.org/developers/index.html
>
> Regards,
> Stefano
>
> On 16/09/2020 14:32, Vladyslav Milutin wrote:
>> Hello guys,
>>
>> I'm writing to you with a hope that you can help me with exception
>> handling.
>> Currently after a long time connection can be reset by peer. See stacktrace
>> below.
>>
>> I've tried to add a custom ChannelHandler which Overrides exceptionCaught()
>> and add it in Driver#initializePipeline() see code below. Also has tried to
>> add a channel that can be obtained from DefaultNettyPlcConnection. And none
>> of them actualy was added to the pipeline where this exception was thrown.
>>
>> plc4x version: 0.7.0
>>
>> StatckTrace:
>> 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
>> [io.netty.channel.DefaultChannelPipeline] onUnhandledInboundException - 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: Connection reset by peer
>>   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
>>   at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
>>   at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
>>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
>>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
>>   at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:358)
>>   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
>>   at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
>>   at
>> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
>>   at
>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
>>   at
>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
>>   at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
>>   at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
>>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>>   at
>> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>>   at
>> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>>   at
>> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>>   at java.base/java.lang.Thread.run(Thread.java:834)
>>
>> Driver#initializePipeline:
>> try {
>> final Channel channel =
>> channelFactory.createChannel(this.handler);
>> channelFactory.initializePipeline(channel.pipeline());
>>
>> } catch (PlcConnectionException e) {
>> log.error("Failed to create channel");
>> }
>>
>> ChannelHandler:
>> @Override
>> public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause)
>> {
>> log.warn("ExceptionCaught in worker: ctx = [{}], cause = [{}, {}],
>> workerName = [{}]",
>> ctx, cause.getClass(), cause.getMessage(), workerName);
>> if (cause instanceof ConnectTimeoutException) {
>> log.warn("ConnectionTimeout caught: workerName = [{}]",
>> workerName);
>> }
>> if ((cause instanceof IOException) &&
>> cause.getMessage().contains("Connection reset by peer")) {
>> log.warn("Connection reset by peer caught: workerName = [{}]",
>> workerName);
>> } else {
>> log.info("Unexpected exception caught: workerName = [{}]",
>> workerName);
>> }
>>
>> this.callback.accept(cause);
>> }
>>
>> DefaultNettyPlcConnection#channel:
>> log.info("Trying to get connection channel: worker name = [{}]",
>> this.workerName);
>> final Channel channel = ((DefaultNettyPlcConnection)
>> this.connection).getChannel();
>> log.info("Channel obtained successfully. Adding custom
>> channelHandler to it: channel = [{}], workerName = [{}]", channel,
>> this.workerName);
>> channel.pipeline().addLast(this.channelHandler);
>> log.info("ChannelHandler added: channel = [{}], channelHandler =
>> [{}], workerName = [{}]", channel, this.channelHandler, this.workerName);
>>
>> Kind regards,
>> Vlad
>>
>



signature.asc
Description: OpenPGP digital signature

Re: Plc4x connection reset by peer exception uncaught

2020-09-16 Thread Stefano Bossi

Hi Vlad,

this seems similar to a bug fixed some time ago, I am not really sure
but it worth to try to use the 0.8.0 version where this fix is present.

You should try to build the version and here you could fine some help:
https://plc4x.apache.org/developers/index.html

Regards,
Stefano

On 16/09/2020 14:32, Vladyslav Milutin wrote:
> Hello guys,
>
> I'm writing to you with a hope that you can help me with exception
> handling.
> Currently after a long time connection can be reset by peer. See stacktrace
> below.
>
> I've tried to add a custom ChannelHandler which Overrides exceptionCaught()
> and add it in Driver#initializePipeline() see code below. Also has tried to
> add a channel that can be obtained from DefaultNettyPlcConnection. And none
> of them actualy was added to the pipeline where this exception was thrown.
>
> plc4x version: 0.7.0
>
> StatckTrace:
> 2020-09-16 13:50:03.340 WARN  [nioEventLoopGroup-58-1]
> [io.netty.channel.DefaultChannelPipeline] onUnhandledInboundException - 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: Connection reset by peer
>   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
>   at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
>   at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
>   at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:358)
>   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
>   at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
>   at
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
>   at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
>   at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
>   at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
>   at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>   at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>   at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>   at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:834)
>
> Driver#initializePipeline:
> try {
> final Channel channel =
> channelFactory.createChannel(this.handler);
> channelFactory.initializePipeline(channel.pipeline());
>
> } catch (PlcConnectionException e) {
> log.error("Failed to create channel");
> }
>
> ChannelHandler:
> @Override
> public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause)
> {
> log.warn("ExceptionCaught in worker: ctx = [{}], cause = [{}, {}],
> workerName = [{}]",
> ctx, cause.getClass(), cause.getMessage(), workerName);
> if (cause instanceof ConnectTimeoutException) {
> log.warn("ConnectionTimeout caught: workerName = [{}]",
> workerName);
> }
> if ((cause instanceof IOException) &&
> cause.getMessage().contains("Connection reset by peer")) {
> log.warn("Connection reset by peer caught: workerName = [{}]",
> workerName);
> } else {
> log.info("Unexpected exception caught: workerName = [{}]",
> workerName);
> }
>
> this.callback.accept(cause);
> }
>
> DefaultNettyPlcConnection#channel:
> log.info("Trying to get connection channel: worker name = [{}]",
> this.workerName);
> final Channel channel = ((DefaultNettyPlcConnection)
> this.connection).getChannel();
> log.info("Channel obtained successfully. Adding custom
> channelHandler to it: channel = [{}], workerName = [{}]", channel,
> this.workerName);
> channel.pipeline().addLast(this.channelHandler);
> log.info("ChannelHandler added: channel = [{}], channelHandler =
> [{}], workerName = [{}]", channel, this.channelHandler, this.workerName);
>
> Kind regards,
> Vlad
>



signature.asc
Description: OpenPGP digital signature

Re: [DISCUSS] Add Wrappers to PLC4X Project

2020-09-09 Thread Stefano Bossi

Hi,

personally I think this kind of approach will limit the usability of the
library in a very narrow subset of uses do to the windows operating
system dependency.

I think you guys put a lot of effort in portability and small footprint
of the library and this is a great think in the industrial world where
typically there are small PC or embedded one.

Using the library in a small PC like a Rasperry Pi with a linux distro
and a lot of attention for the security and hardening of the environment
I think is a pro for any industrial project
(e.g. Selinux, Firewall, minimal service installation, OSCAP security
profile compliance, etc ).

Evaluating the effort required in reversing the DCOM protocol is
something to be taken into consideration before integrating a windows
library in the plc4x code.

Maybe this could be a transient solution or a way to validate a full
open source solution.

Regards,
Stefano



On 09/09/2020 13:35, Christofer Dutz wrote:
> Hi Julian,
>
> the issue I see here is that it will make the build more complex (the part 
> using the wrapper will only be runnable on windows and not sure if the 
> license of the wrapped DLLs would allow including them). 
>
> It will also eliminate the ability to auto-port the driver to other 
> languages. 
>
> And, beyond that, it would limit these drivers to only work on a subset of 
> platforms (Aka ... a Java Driver that only works on Windows Systems with 
> installed subsystem for the PLC)
>
> I wouldn't want to make such a solution a first class citizen (aka live in 
> plc4j/drivers) ... we could sort of start providing some sort of 
> "plc4j/contrib" modules, if we have to go this path.
>
> But personally I would opt for at least having a look at the path I described 
> in slack:
>
> - Use the native libs and build an application that does the basic 
> interaction with the Windows DLLs
> - Use WireShark to record the communication
> - Have a look if it's not just a very small subset of DCOM that is used
>
> Perhaps it would sort of be like using some mspec types with a lot of const 
> fields to allow communication without any intermediate DLL  this would 
> make it runnable on all target platforms and auto-portable to all target 
> languages of PLC4X.
>
>
> Chris
>
> Am 09.09.20, 09:50 schrieb "Julian Feinauer" :
>
> Hi all,
>
> wanted to bring it tot he list as we already had a discussion in the 
> slack channel.
> We have a project where we consider integrating machinery in our system.
> The machinery offers an SDK for communication which is windows only and 
> based on DCOM.
> Thus, the integration would be a wrapper around the SDK with „only“ a 
> PLC4X „frontend“.
>
> Personally, I consider this viable as our aim ist o have one interface 
> for „everything“.
> Nonetheless, I also agree with everybody saying that its not as nice as 
> having the complete stack in our hands.
>
> What do others think, should this be part oft he PLC4X project or should 
> we just do it separately.
> Personally idk that much but think it would be nice to have maximum 
> support in plc4x, if possible.
>
> Best
> Julian
>



signature.asc
Description: OpenPGP digital signature

Re: [DISCUSS] Start releasing build tools?

2020-09-07 Thread Stefano Bossi

+1 I agree, waiting with all the fix it's impossible.

We could anyway open a 0.9.0 after the freezing of the 0.8.0

Regards,
Stefano


On 07/09/2020 11:45, Julian Feinauer wrote:
> Hi,
>
> +1 from my side.
> Andi f we still find something.. we just do another release.
>
> J
>
> Am 07.09.20, 09:14 schrieb "Christofer Dutz" :
>
> Hi all,
>
> I know I started this thread multiple times, but this time I really think 
> we should do it. I know that perhaps after we release we will be needing some 
> changes, but I guess we can’t change that.
> So I would like to stage a RC soon, so we can start a new release on 
> 0.8.0 very soon. There are a lot of bugfixes in there which I would like to 
> see people using and not having to use the 0.7.0.
>
>
> Chris
>
>
>



signature.asc
Description: OpenPGP digital signature

Re: Adding Using PLC4X with Grade to documentation ... WAS: Re: S7 read issue

2020-09-01 Thread Stefano Bossi

:-)

Ok, I think i have added to the project the incredible quantity of 20
line of documentation with a Pull Request 

WOW, I am officially an open source community contributor !!!

Regards,
S.


On 01/09/2020 11:10, Christofer Dutz wrote:
> And if you have problems creating the PR from the documentation … PRs for 
> that welcome too ;-)
>
> Just kidding … if you need help with that, just ask :-)
>
> Chris
>
> Von: Stefano Bossi 
> Antworten an: 
> Datum: Dienstag, 1. September 2020 um 10:40
> An: 
> Betreff: Re: Adding Using PLC4X with Grade to documentation ... WAS: Re: S7 
> read issue
>
> ok, I try, I will read how to do a PR and I will add the documentation on git.
>
> Ciao,
> S.
>
>
> On 01/09/2020 09:18, Christofer Dutz wrote:
>
> Hi Stefano,
>
>
>
> it would be super-great if you could whip up a PR for our documentation … 
> it’s also in the same repo under src/site/asciidoc …
>
>
>
> Chris
>
>
>
>
>
>
>
> Von: Stefano Bossi <mailto:stefano.bo...@gmail.com>
>
> Antworten an: <mailto:dev@plc4x.apache.org>
>
> Datum: Montag, 31. August 2020 um 15:18
>
> An: <mailto:dev@plc4x.apache.org>
>
> Betreff: Re: S7 read issue
>
>
>
>
>
> Hi Sebastian,
>
>
>
> Chris wrote a very good page on how to compile the library which is a very 
> big software: https://plc4x.apache.org/developers/building.html
>
>
>
> On Mac I found no problem to follow the guide and I think on windows should 
> be fine too.
>
>
>
> As extra suggestion on the guide I could add something if you use Gradle for 
> your software: the compilation build and install all the jars local in your 
> machine, if you would access this local jar storage via gradle you have just 
> to add mavenLocal() to the list of repositories:
>
>
>
> repositories {
>
>
>
> mavenCentral()
>
>
>
> mavenLocal()
>
>
>
> }
>
>
>
> I’s not not difficult to figure out but I spend a couple of hours wandering 
> how to do so it’s worth sharing
>
>
>
> Regards,
>
> S.
>
>
>
> On 31/08/2020 14:45, Christofer Dutz wrote:
>
>
>
> Hi Sebasitan,
>
>
>
>
>
>
>
> Just some minutes ago I submitted a fix for your problem.
>
>
>
> Please give it a try :-)
>
>
>
>
>
>
>
> Chris
>
>
>
>
>
>
>
>
>
>
>
> Am 31.08.20, 11:41 schrieb "Sebastian Voss" 
> <mailto:svdevl...@gmail.com><mailto:svdevl...@gmail.com><mailto:svdevl...@gmail.com>:
>
>
>
>
>
>
>
> Hi Chris,
>
>
>
>
>
>
>
> JIRA issue with attachment is created 
> https://issues.apache.org/jira/browse/PLC4X-246 
> <https://issues.apache.org/jira/browse/PLC4X-246><https://issues.apache.org/jira/browse/PLC4X-246><https://issues.apache.org/jira/browse/PLC4X-246><https://issues.apache.org/jira/browse/PLC4X-246>.
>  I will try to change the settings and report back the result.
>
>
>
>
>
>
>
> Thanks a lot and best regards,
>
>
>
> Sebastian
>
>
>
>
>
>
>
> > On 31. Aug 2020, at 11:08, Christofer Dutz 
> <mailto:christofer.d...@c-ware.de><mailto:christofer.d...@c-ware.de><mailto:christofer.d...@c-ware.de>
>  wrote:
>
>
>
> >
>
>
>
> > Hi Sebastian …
>
>
>
> >
>
>
>
> > Unfortunately attachments don’t work on this mailing list. Could you 
> please create a JIRA issue?
>
>
>
> >
>
>
>
> > And I think I can help you with that error of yours:
>
>
>
> > Go into the settings of your S7 and  enable PUT/GET … the folks from 
> NodeRed made a nice video:
>
>
>
> > https://www.youtube.com/watch?v=rTUs-_EiZ3A (Just the first 1,5 minutes)
>
>
>
> >
>
>
>
> > But the driver should definitely report this … as it is a known thing 
> and if we reported that it would help a lot of others.
>
>
>
> >
>
>
>
> > Chris
>
>
>
> >
>
>
>
> >
>
>
>
> >
>
>
>
> >
>
>
>
> > Von: Sebastian Voss 
> <mailto:svdevl...@gmail.com><mailto:svdevl...@gmail.com><mailto:svdevl...@gmail.com>
>
>
>
> > Antworten an: 
> "dev@plc4x.apache.org"<mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org>
>  
> <mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org&

Re: Adding Using PLC4X with Grade to documentation ... WAS: Re: S7 read issue

2020-09-01 Thread Stefano Bossi

ok, I try, I will read how to do a PR and I will add the documentation
on git.

Ciao,
S.



On 01/09/2020 09:18, Christofer Dutz wrote:
> Hi Stefano,
>
> it would be super-great if you could whip up a PR for our documentation … 
> it’s also in the same repo under src/site/asciidoc …
>
> Chris
>
>
>
> Von: Stefano Bossi 
> Antworten an: 
> Datum: Montag, 31. August 2020 um 15:18
> An: 
> Betreff: Re: S7 read issue
>
>
> Hi Sebastian,
>
> Chris wrote a very good page on how to compile the library which is a very 
> big software: https://plc4x.apache.org/developers/building.html
>
> On Mac I found no problem to follow the guide and I think on windows should 
> be fine too.
>
> As extra suggestion on the guide I could add something if you use Gradle for 
> your software: the compilation build and install all the jars local in your 
> machine, if you would access this local jar storage via gradle you have just 
> to add mavenLocal() to the list of repositories:
>
> repositories {
>
> mavenCentral()
>
> mavenLocal()
>
> }
>
> I’s not not difficult to figure out but I spend a couple of hours wandering 
> how to do so it’s worth sharing
>
> Regards,
> S.
>
> On 31/08/2020 14:45, Christofer Dutz wrote:
>
> Hi Sebasitan,
>
>
>
> Just some minutes ago I submitted a fix for your problem.
>
> Please give it a try :-)
>
>
>
> Chris
>
>
>
>
>
> Am 31.08.20, 11:41 schrieb "Sebastian Voss" 
> <mailto:svdevl...@gmail.com>:
>
>
>
> Hi Chris,
>
>
>
> JIRA issue with attachment is created 
> https://issues.apache.org/jira/browse/PLC4X-246 
> <https://issues.apache.org/jira/browse/PLC4X-246><https://issues.apache.org/jira/browse/PLC4X-246>.
>  I will try to change the settings and report back the result.
>
>
>
> Thanks a lot and best regards,
>
> Sebastian
>
>
>
> > On 31. Aug 2020, at 11:08, Christofer Dutz 
> <mailto:christofer.d...@c-ware.de> wrote:
>
> >
>
> > Hi Sebastian …
>
> >
>
> > Unfortunately attachments don’t work on this mailing list. Could you 
> please create a JIRA issue?
>
> >
>
> > And I think I can help you with that error of yours:
>
> > Go into the settings of your S7 and  enable PUT/GET … the folks from 
> NodeRed made a nice video:
>
> > https://www.youtube.com/watch?v=rTUs-_EiZ3A (Just the first 1,5 minutes)
>
> >
>
> > But the driver should definitely report this … as it is a known thing 
> and if we reported that it would help a lot of others.
>
> >
>
> > Chris
>
> >
>
> >
>
> >
>
> >
>
> > Von: Sebastian Voss <mailto:svdevl...@gmail.com>
>
> > Antworten an: "dev@plc4x.apache.org"<mailto:dev@plc4x.apache.org> 
> <mailto:dev@plc4x.apache.org>
>
> > Datum: Montag, 31. August 2020 um 10:49
>
> > An: "dev@plc4x.apache.org"<mailto:dev@plc4x.apache.org> 
> <mailto:dev@plc4x.apache.org>
>
> > Betreff: Re: S7 read issue
>
> >
>
> > Hi Chris, Hi Stefano,
>
> >
>
> > Thanks a lot for your valuable feedback. It is highly appreciated.
>
> >
>
> > I followed Stefanos suggestions and applied the simplifications. In 
> addition I created a Wireshark capture which is attached to this email.
>
> >
>
> > It seems it replies with “[Error code: This service is not implemented 
> on the module or a frame error was reported (0x8104)]"
>
> >
>
> > Does this mean the address is wrong or is it something else?
>
> >
>
> > Best regards,
>
> > Sebastian
>
> >
>
> >
>
> >> On 31. Aug 2020, at 09:42, Stefano Bossi 
> <mailto:stefano.bo...@gmail.com> wrote:
>
> >>
>
> >> Hi Sebastian,
>
> >>
>
> >> if you need some help in setup the wireshark capture software or open 
> the jira ticket I could help.
>
> >>
>
> >> It’s definitely worth to follow the Chris suggestion to help him to 
> spot the real problem.
>
> >>
>
> >> In the mean time I think you could simplify the PLC query in this way:
>
> >>
>
> >> String Url: s7:tcp://172.3.4.5:102?controller-type=S7_1200
>
> >>
>
> >> String field: %DB20:5.0:BOOL
>
> >>
>
> >> As far as the

Re: S7 read issue

2020-08-31 Thread Stefano Bossi

Hi Sebastian,

Chris wrote a very good page on how to compile the library which is a
very big software: https://plc4x.apache.org/developers/building.html

On Mac I found no problem to follow the guide and I think on windows
should be fine too.

As extra suggestion on the guide I could add something if you use Gradle
for your software: the compilation build and install all the jars local
in your machine, if you would access this local jar storage via gradle
you have just to add |mavenLocal()| to the list of repositories:

|repositories { mavenCentral() mavenLocal() } |

I’s not not difficult to figure out but I spend a couple of hours
wandering how to do so it’s worth sharing

Regards,
S.

On 31/08/2020 14:45, Christofer Dutz wrote:

> Hi Sebasitan,
>
> Just some minutes ago I submitted a fix for your problem. 
> Please give it a try :-)
>
> Chris
>
>
> Am 31.08.20, 11:41 schrieb "Sebastian Voss" :
>
> Hi Chris,
>
> JIRA issue with attachment is created 
> https://issues.apache.org/jira/browse/PLC4X-246 
> <https://issues.apache.org/jira/browse/PLC4X-246>. I will try to change the 
> settings and report back the result.
>
> Thanks a lot and best regards,
> Sebastian
>
> > On 31. Aug 2020, at 11:08, Christofer Dutz  
> wrote:
> > 
> > Hi Sebastian …
> > 
> > Unfortunately attachments don’t work on this mailing list. Could you 
> please create a JIRA issue?
> > 
> > And I think I can help you with that error of yours:
> > Go into the settings of your S7 and  enable PUT/GET … the folks from 
> NodeRed made a nice video:
> > https://www.youtube.com/watch?v=rTUs-_EiZ3A (Just the first 1,5 minutes)
> > 
> > But the driver should definitely report this … as it is a known thing 
> and if we reported that it would help a lot of others.
> > 
> > Chris
> > 
> > 
> > 
> > 
> > Von: Sebastian Voss 
> > Antworten an: "dev@plc4x.apache.org" 
> > Datum: Montag, 31. August 2020 um 10:49
> > An: "dev@plc4x.apache.org" 
> > Betreff: Re: S7 read issue
> > 
> > Hi Chris, Hi Stefano,
> > 
> > Thanks a lot for your valuable feedback. It is highly appreciated.
> > 
> > I followed Stefanos suggestions and applied the simplifications. In 
> addition I created a Wireshark capture which is attached to this email.
> > 
> > It seems it replies with “[Error code: This service is not implemented 
> on the module or a frame error was reported (0x8104)]"
> > 
> > Does this mean the address is wrong or is it something else?
> > 
> > Best regards,
> > Sebastian
> > 
> > 
> >> On 31. Aug 2020, at 09:42, Stefano Bossi  
> wrote:
> >> 
> >> Hi Sebastian,
> >> 
> >> if you need some help in setup the wireshark capture software or open 
> the jira ticket I could help.
> >> 
> >> It’s definitely worth to follow the Chris suggestion to help him to 
> spot the real problem.
> >> 
> >> In the mean time I think you could simplify the PLC query in this way:
> >> 
> >> String Url: s7:tcp://172.3.4.5:102?controller-type=S7_1200
> >> 
> >> String field: %DB20:5.0:BOOL
> >> 
> >> As far as the address of the Data Block and the bool value are 
> correct, should work.
> >> There were nothing particular wrong in your query but the library is 
> somewhat “sensible” if something goes wrong in the dialogue with the PLC
> >> 
> >> An another thing you should pay attention is that the Data Block MUST 
> be NOT optimized; reading of optimized block is not currently supported. This 
> shouldn’t be your case because an attempt to read an optimized block raise an 
> exception or a null value.
> >> 
> >> Try and let us know.
> >> 
> >> Regards,
> >> Stefano
> >> 
> >> On 31/08/2020 08:48, Christofer Dutz wrote:
> >> 
> >> 
> >> 
> >>> Hi Sebastian,
> >>> 
> >>> could you possibly do a wireshark recording of this, create an issue 
> in our jira and attach the capture there?
> >>> I am sure we haven't handled all things that could go wrong and with 
> this information I might be able to improve the error handling.
> >>> 
> >>> Chris
> >>> 
> >>> 
> >>

Re: S7 read issue

2020-08-31 Thread Stefano Bossi

Hi Sebastian,

if you need some help in setup the wireshark capture software or open
the jira ticket I could help.

It’s definitely worth to follow the Chris suggestion to help him to spot
the real problem.

In the mean time I think you could simplify the PLC query in this way:

|String Url: s7:tcp://172.3.4.5:102?controller-type=S7_1200 |

|String field: %DB20:5.0:BOOL |

As far as the address of the Data Block and the bool value are correct,
should work.
There were nothing particular wrong in your query but the library is
somewhat “sensible” if something goes wrong in the dialogue with the PLC

An another thing you should pay attention is that the Data Block MUST be
NOT optimized; reading of optimized block is not currently supported.
This shouldn’t be your case because an attempt to read an optimized
block raise an exception or a null value.

Try and let us know.

Regards,
Stefano

On 31/08/2020 08:48, Christofer Dutz wrote:

> Hi Sebastian,
>
> could you possibly do a wireshark recording of this, create an issue in our 
> jira and attach the capture there?
> I am sure we haven't handled all things that could go wrong and with this 
> information I might be able to improve the error handling.
>
> Chris
>
>
>
>
> Am 30.08.20, 18:28 schrieb "Sebastian Voss" :
>
> Hi,
>
> I’m trying to read a value from an Siemens S7-1200 PLC). This is my first 
> project using the S7 protocol and plc4x. When I try to read a value the read 
> request is not being executed (I also do not receive an error message or 
> timeout). Would this be the normal behaviour when the field address is wrong? 
> I’m out of ideas how to trace this down. Any hints would be highly 
> appreciated.
>
> This is the simple program I created:
>
> String url = 
> "s7://172.3.4.5:102?local-rack=0=1=0=1=S7_1200
>  
> ";
> PlcDriverManager manager = new PlcDriverManager();
> PlcConnection connection = manager.getConnection(url);
>
> boolean isConnected = connection.isConnected();
> boolean canRead = connection.getMetadata().canRead();
>
> System.out.println(isConnected);  // prints true
> System.out.println(canRead);  // prints true
>
> String field = "%DB20:DBX05.0:BOOL";
> PlcReadRequest request = connection
>.readRequestBuilder()
>.addItem("value-1", field)
>.build();
>
> PlcReadResponse response = request.execute().get();  // here is hangs 
> forever
>
> System.out.println(response.getFieldNames());
>
> connection.close();
>
> Thanks a lot in advance!
>
> Best regards,
> Sebastian
>

signature.asc
Description: OpenPGP digital signature

Re: Leaking nioEventLoopGroup threads

2020-08-25 Thread Stefano Bossi

Yupiii !!!

good news !!!

Regards,
S.


On 25/08/2020 15:45, Adam Rossi wrote:
> Juilan,
>
> My apologies - your fix did indeed work. The issue is that
> PooledPlcDriverManager does not seem to be calling the close method on the
> connection. Switching back to PlcDriverManager from PooledPlcDriverManager
> results in your new log comments showing up in the log, and more
> importantly no more leaks of the nioEventLoopGroup threads. I have tested
> the code in a loop for an hour or so and it is working perfectly.
>
> The PooledPlcDriverManager seems to intercept the close method on the
> plcConnection (lines 125 - 130):
>
> if ("close".equals(method.getName())) {
> LOGGER.debug("close called on {}", plcConnection);
> proxyInvalidated.set(true);
> keyedObjectPool.returnObject(poolKey, plcConnection);
> return null;
> } else {
>
> Which makes sense as it is trying to keep active connections pooled.
> However, when this connection is again retrieved from the pool it seems the
> plcConnection connects again and creates an additional nioEventLoopGroup
> thread, which is never closed.
>
> I am new to working with this project and Jira. It seems to me that I
> should close the issue I just created as your fix does indeed correct the
> original issue, and perhaps open another issue on PooledPlcDriverManager
> for this thread leak?
>
> Regards, Adam
>
> On Mon, Aug 24, 2020 at 4:39 AM Julian Feinauer <
> j.feina...@pragmaticminds.de> wrote:
>
>> Hi,
>>
>> short feedback. I looked into the code and indeed it seems that we had a
>> bug there which could lead tot he socket leak you described.
>> I pushed a fix in the branch:
>>
>> https://github.com/apache/plc4x/tree/bugfix/close-eventloop-after-channel
>>
>> Would you mind taking a look and testing this with your code @Adam Rossi?
>>
>> Thanks!
>> Juliasn
>>
>> Am 24.08.20, 08:26 schrieb "Julian Feinauer" <
>> j.feina...@pragmaticminds.de>:
>>
>> Perhaps, some related questions:
>>
>> - You are using Linux for your Tests?
>> - Do you close all Connections properly?
>> Normally the `PlcConnection.close()` method should close the EventLoop.
>>
>> Julian
>>
>> Am 24.08.20, 08:23 schrieb "Julian Feinauer" <
>> j.feina...@pragmaticminds.de>:
>>
>> Hi Adam,
>>
>> I will have a look today!
>>
>> Do we have a Jira Issue for it already?
>>
>> Julian
>>
>> Am 24.08.20, 07:38 schrieb "Christofer Dutz" <
>> christofer.d...@c-ware.de>:
>>
>> Hi Adam,
>>
>> of course that's unfortunate ... also I will not be able to
>> address this issue soon as I have to work on the tasks of my research
>> project.
>> I have one more month to work on this and I'm months behind
>> schedule because I have been doing free support way too much lately.
>>
>> I really hope Julian will be able to help ... he's way more
>> into the details of Netty than I am (cause he's got the book ;-) )
>>
>> So Julian? ... it would be super awesome if you could take on
>> this issue.
>>
>> Chris
>>
>>
>>
>> Am 24.08.20, 00:17 schrieb "Adam Rossi" :
>>
>> Thanks, I did test with 0.8.0-SNAPSHOT and see the same
>> behavior. In every
>> plcConnection a nioEventLoopGroup thread is created and
>> does not ever seem
>> to be destroyed.
>>
>> I wish I understood the io.netty.channel.EventLoopGroup
>> class better to be
>> more helpful here. Would an example program that
>> reproduces this thread
>> leak be useful?
>>
>> jconsole shows the thread data as:
>>
>> Name: nioEventLoopGroup-19-1
>> State: RUNNABLE
>> Total blocked: 0  Total waited: 0
>>
>> Stack trace:
>> java.base@13.0.2/sun.nio.ch.EPoll.wait(Native Method)
>> java.base@13.0.2
>>
>> /sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)
>> java.base@13.0.2
>>
>> /sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)
>>- locked
>> io.netty.channel.nio.SelectedSelectionKeySet@1838f97
>>- locked sun.nio.ch.EPollSelectorImpl@1f49287
>> java.base@13.0.2/sun.nio.ch
>> .SelectorImpl.select(SelectorImpl.java:141)
>>
>> app//io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68)
>>
>> app//io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:803)
>>
>> app//io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:457)
>>
>> app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>>
>> app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>>
>>

Re: Leaking nioEventLoopGroup threads

2020-08-25 Thread Stefano Bossi

Hi Adam,

it's much better to not forget your problem if you open a new ticket on
Jira.

here is the link: https://issues.apache.org/jira/projects/PLC4X/summary

You should open an account a copy your mail in there.

Just a suggestion to keep the things in order.

Thanks,
S.


On 24/08/2020 17:26, Adam Rossi wrote:
> Julian, thank you so much for your attention on this. Your code changes
> look good but unfortunately I am still experiencing the problem.
>
> Here is some log output from my program. You can see that the close is
> called on the DefaultNettyPlcConnection, but I do not see the output from
> your code modification that I would expect if the closeEventLoopForChannel
> method was being called (Either logger.info("Channel is closed, closing
> worker Group also") or logger.warn("Trying to remove EventLoop for Channel
> {} but have none stored", channel).
>
> The nioEventLoopGroup threads continue to persist after every
> plcConnection.
>
> I hope I have built everything correctly...I checked out your branch with:
>
> git clone --single-branch --branch bugfix/close-eventloop-after-channel
> https://github.com/apache/plc4x.git
>
> And wiped out my local m2 maven repository before building the code with:
>
> ./mvnw install -DskipTests
>
> I also removed references to the apache snapshot repo from my project pom
> and by all appearances I am using the correct 0.8.0-SNAPSHOT jars that are
> locally built in my local m2 repo. Here is some log info from my test:
>
>
>
>
> 2020-08-24_10:15:43.450 DEBUG PooledPlcDriverManager - Try to borrow an
> object for url modbus://192.168.0.5:503?unit-identifier=50
> 2020-08-24_10:15:43.452 INFO  TcpChannelFactory - Configuring Bootstrap
> with Configuration{}
> 2020-08-24_10:15:43.458 DEBUG ModbusManager - Connection Metadata:
> 2020-08-24_10:15:43.459 DEBUG ModbusManager -
> org.apache.plc4x.java.spi.connection.DefaultNettyPlcConnection@185c140
> 2020-08-24_10:15:43.462 DEBUG Plc4xNettyWrapper - Forwarding request to plc
> ModbusTcpADU[transactionIdentifier=10,unitIdentifier=50,pdu=ModbusPDUReadHoldingRegistersRequest[startingAddress=67,quantity=1]]
> 2020-08-24_10:15:43.466 DEBUG GeneratedDriverByteToMessageCodec - Sending
> bytes to PLC for message
> ModbusTcpADU[transactionIdentifier=10,unitIdentifier=50,pdu=ModbusPDUReadHoldingRegistersRequest[startingAddress=67,quantity=1]]
> as data 000a0006320300430001
> 2020-08-24_10:15:43.470 DEBUG Plc4xNettyWrapper - Forwarding request to plc
> ModbusTcpADU[transactionIdentifier=11,unitIdentifier=50,pdu=ModbusPDUReadHoldingRegistersRequest[startingAddress=69,quantity=1]]
> 2020-08-24_10:15:43.471 DEBUG GeneratedDriverByteToMessageCodec - Sending
> bytes to PLC for message
> ModbusTcpADU[transactionIdentifier=11,unitIdentifier=50,pdu=ModbusPDUReadHoldingRegistersRequest[startingAddress=69,quantity=1]]
> as data 000b0006320300450001
> 2020-08-24_10:15:43.480 DEBUG Plc4xNettyWrapper - Forwarding request to plc
> ModbusTcpADU[transactionIdentifier=12,unitIdentifier=50,pdu=ModbusPDUReadHoldingRegistersRequest[startingAddress=68,quantity=1]]
> 2020-08-24_10:15:43.481 DEBUG GeneratedDriverByteToMessageCodec - Sending
> bytes to PLC for message
> ModbusTcpADU[transactionIdentifier=12,unitIdentifier=50,pdu=ModbusPDUReadHoldingRegistersRequest[startingAddress=68,quantity=1]]
> as data 000c0006320300440001
> 2020-08-24_10:15:43.484 DEBUG Plc4xNettyWrapper - Forwarding request to plc
> ModbusTcpADU[transactionIdentifier=13,unitIdentifier=50,pdu=ModbusPDUReadHoldingRegistersRequest[startingAddress=66,quantity=1]]
> 2020-08-24_10:15:43.485 DEBUG GeneratedDriverByteToMessageCodec - Sending
> bytes to PLC for message
> ModbusTcpADU[transactionIdentifier=13,unitIdentifier=50,pdu=ModbusPDUReadHoldingRegistersRequest[startingAddress=66,quantity=1]]
> as data 000d0006320300420001
> 2020-08-24_10:15:43.489 DEBUG PooledPlcDriverManager - close called on
> org.apache.plc4x.java.spi.connection.DefaultNettyPlcConnection@185c140
> 2020-08-24_10:15:43.490 INFO  ReadModbusTask - Read Modbus Task Completed.
>
> Some details from my code:
>
> Getting the connection:
>
> PlcConnection plcConnection =
> pooledDriverManager.getConnection(modbusServerURI);
> if (plcConnection.isConnected()) {
> LOG.trace("The connection is connected");
>  } else {
> LOG.trace("The connection is not connected. Connecting
> now...");
> plcConnection.connect();
>  }
>
> Reading the plc and closing the connection:
>
> PlcReadRequest.Builder builder = plcConnection.readRequestBuilder();
> builder.addItem("devicename", "holding-register:1[8]");
> builder.addItem("generatorstate", "holding-register:67");
> builder.addItem("batteryvoltage", "holding-register:513[2]");
> builder.addItem("batterycurrent", "holding-register:515[2]");
> builder.addItem("pvpowerwatts", "holding-register:69[2]");
> builder.addItem("pvinputthishourkwh", "holding-register:307[2]");
> PlcReadRequest readRequest = builder.build();
>

Re: Leaking nioEventLoopGroup threads

2020-08-24 Thread Stefano Bossi

Yes thanks !

This will be very important for my stability test too!

Let's see if Adam confirm the patch !

Thanks,
Stefano



On 24/08/2020 11:35, Christofer Dutz wrote:
> Thanks Julian for that quick fix.
>
> Chris
>
>
> Am 24.08.20, 10:39 schrieb "Julian Feinauer" :
>
> Hi,
>
> short feedback. I looked into the code and indeed it seems that we had a  
> bug there which could lead tot he socket leak you described.
> I pushed a fix in the branch:
>
> https://github.com/apache/plc4x/tree/bugfix/close-eventloop-after-channel
>
> Would you mind taking a look and testing this with your code @Adam Rossi?
>
> Thanks!
> Juliasn
>
> Am 24.08.20, 08:26 schrieb "Julian Feinauer" 
> :
>
> Perhaps, some related questions:
>
> - You are using Linux for your Tests?
> - Do you close all Connections properly?
> Normally the `PlcConnection.close()` method should close the 
> EventLoop.
>
> Julian
>
> Am 24.08.20, 08:23 schrieb "Julian Feinauer" 
> :
>
> Hi Adam,
>
> I will have a look today!
>
> Do we have a Jira Issue for it already?
>
> Julian
>
> Am 24.08.20, 07:38 schrieb "Christofer Dutz" 
> :
>
> Hi Adam,
>
> of course that's unfortunate ... also I will not be able to 
> address this issue soon as I have to work on the tasks of my research project.
> I have one more month to work on this and I'm months behind 
> schedule because I have been doing free support way too much lately.
>
> I really hope Julian will be able to help ... he's way more 
> into the details of Netty than I am (cause he's got the book ;-) ) 
>
> So Julian? ... it would be super awesome if you could take on 
> this issue.
>
> Chris
>
>
>
> Am 24.08.20, 00:17 schrieb "Adam Rossi" :
>
> Thanks, I did test with 0.8.0-SNAPSHOT and see the same 
> behavior. In every
> plcConnection a nioEventLoopGroup thread is created and 
> does not ever seem
> to be destroyed.
>
> I wish I understood the io.netty.channel.EventLoopGroup 
> class better to be
> more helpful here. Would an example program that 
> reproduces this thread
> leak be useful?
>
> jconsole shows the thread data as:
>
> Name: nioEventLoopGroup-19-1
> State: RUNNABLE
> Total blocked: 0  Total waited: 0
>
> Stack trace:
> java.base@13.0.2/sun.nio.ch.EPoll.wait(Native Method)
> java.base@13.0.2
> 
> /sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)
> java.base@13.0.2
> 
> /sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)
>- locked 
> io.netty.channel.nio.SelectedSelectionKeySet@1838f97
>- locked sun.nio.ch.EPollSelectorImpl@1f49287
> 
> java.base@13.0.2/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:141)
> 
> app//io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68)
> 
> app//io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:803)
> 
> app//io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:457)
> 
> app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> 
> app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> 
> app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> java.base@13.0.2/java.lang.Thread.run(Thread.java:830)
>
>
> Regards, Adam
>
> On Sun, Aug 23, 2020 at 1:00 PM Christofer Dutz 
> 
> wrote:
>
> > Hi Adam,
> >
> > the Apache SNAPSHOT repo is at:
> > 
> https://repository.apache.org/content/repositories/snapshots
> >
> > Adding this to your pom should help:
> >
> >   
> >   
> > 
> >   apache-snapshots
> >   
> https://repository.apache.org/content/repositories/snapshots
> > 
> >   
> > false
> >   
> >   
> > true
> >   
> > 
> >   
> >
> >   
>

[jira] [Created] (PLC4X-241) Reading long Int Array

2020-08-22 Thread Stefano Bossi (Jira)

Stefano Bossi created PLC4X-241:
---

 Summary: Reading long Int Array
 Key: PLC4X-241
 URL: https://issues.apache.org/jira/browse/PLC4X-241
 Project: Apache PLC4X
  Issue Type: Bug
  Components: Driver-S7
Affects Versions: 0.8.0
Reporter: Stefano Bossi
 Attachments: Screenshot 2020-08-22 at 09.57.45.png, 
readComplexDBError.pcapng, readLongIntArray_v0.8.0_Error.pcapng, 
readLongIntArray_v0_6_0.pcapng

Dear Chris,

I need to report an another bug. 
As you know I am trying to read a very complex Data Bloc from a S7-1200, in the 
future I will try with a 1500. A picture of one of this block in in the 
attached picture.
I found a problem which actually is similar to the String problem I reported in 
[PLC4X-240|https://issues.apache.org/jira/projects/PLC4X/issues/PLC4X-240], in 
reading long array of Int. 
The software running in the PLC as a component which actually samples an analog 
value a store the data in long Array of Integer or Real. An example is:

{code:java}
PLC_CellValue_2[400]='%DB2:928.0:INT[400]'
{code}

or 

{code:java}
PLC_SpeedNotSafety[400]='%DB2:6542.0:REAL[400]'
{code}

Reading such a long array of values is not possible because the request on the 
wire is for a too huge payload (probably this is the same problem we had with 
the string). 
I have attached the wireshark capture for you.

I did the comparison with the 0.6.0 version of the library and the array is 
correctly read. On the wire I see 3 read of 110 Integer and a last one of 70 
which are my 400 Integer. 
As for this reading I have captured the wireshark.

just to complete the big picture my final target is to read a big DB. In this 
complex scenario there a similar problem that I think is a data request size 
problem too. 
If I try to read a list of variables like this one: 

{code:java}
PLC_ReportColpoDateLast='%DB2:0.0:DATE_AND_TIME'
PLC_@timestamp='%DB2:12.0:DATE_AND_TIME'
PLC_ReportColpoDateLastID='%DB2:24.0:DINT'
PLC_ReportColpoDateID='%DB2:28.0:DINT'
PLC_RichiestaCurva='%DB2:32.0:INT'
PLC_TrasferimentoCurva='%DB2:34.0:BOOL'
PLC_ArchiveReport='%DB2:36.0:BOOL'
PLC_DeleteReport='%DB2:36.1:BOOL'
PLC_Report='%DB2:36.2:BOOL'
PLC_Enable='%DB2:36.3:BOOL'
PLC_SetCelloffset='%DB2:36.4:BOOL'
PLC_ResCelloffset='%DB2:36.5:BOOL'
PLC_IDX='%DB2:38.0:INT'
PLC_KW='%DB2:40.0:BOOL'
PLC_TemCen='%DB2:42.0:REAL'
PLC_TemBiella='%DB2:46.0:REAL'
PLC_TemBroDx='%DB2:50.0:REAL'
PLC_TemBroSx='%DB2:54.0:REAL'
PLC_PreCen='%DB2:58.0:REAL'
PLC_PreFreno='%DB2:62.0:REAL'
PLC_PreCil='%DB2:66.0:REAL'
PLC_EncPosAct='%DB2:70.0:REAL'
PLC_EncPosActSafety='%DB2:74.0:REAL'
PLC_EncSpeedSafety='%DB2:78.0:REAL'
PLC_EncSpeed='%DB2:82.0:REAL'
PLC_CellValue[5]='%DB2:86.0:INT[5]'
PLC_CellValueOffset[5]='%DB2:96.0:INT[5]'
PLC_N_TotPezzi='%DB2:106.0:DINT'
PLC_N_TotColpi='%DB2:110.0:DINT'
PLC_KW_Max='%DB2:114.0:INT'
PLC_CellValueMax[5]='%DB2:116.0:INT[5]'
PLC_CellValue_1[2]='%DB2:126.0:INT[2]'
PLC_CellValue_2[400]='%DB2:928.0:INT[100]'
{code}

The error I find on the wire is the same. Pleas note that in the list of 
variables there are no array of 400 samples but, I suppose, that the sum of all 
the request fire the same bug about the request of more than 240 byte length. 
I have attached a wireshark capture of this scenario too. 

Hope this analysis could help to find an universal solution for this problem. 

Regards,
Stefano 

P.S. As usual I am using the HellpPlc4x code and the latest compiled version of 
the 0.8.0 library. 



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

Re: Starting a new project

2020-08-21 Thread Stefano Bossi

Thanks I see  :-D

S.


On 21/08/2020 14:33, Julian Feinauer wrote:
> Many thanks again, its online now: 
> https://plc4x.apache.org/users/adopters.html
>
> <3
>
> Julian
>
> Am 21.08.20, 12:55 schrieb "Julian Feinauer" :
>
> Hi Stefano,
>
> thats awesome to hear and thank you VERY MUCH for caring that much about 
> PLC4X and also thanks to Daniele for providing us the Logo!
>
> I will quickly add a PR for you to review!
>
> Julian
>
> Von: Stefano Bossi 
> Antworten an: 
> Datum: Freitag, 21. August 2020 um 12:31
> An: "dev@plc4x.apache.org" , Christofer Dutz 
> 
> Cc: Daniele Rimoldi 
> Betreff: Starting a new project
>
>
> Dear Chris,
>
> as discussed privately, I am sending you some brief information about the 
> project I am dealing with for the Pietro Rimoldi S.n.c Company.
> The technical director, added in copy, agreed to list the name of the 
> company to the “Companies using Apache PLC4X” page of your site.
>
> Here are the data for the page:
> · Name of the company: PIETRORIMOLDI s.r.l.
> · Company Site: www.rimoldi.it<http://www.rimoldi.it>
> · Market: IIoT / Analytics
> · Summary of the project: We started a project which deals with 
> long term data analysis; the data are gathered from machines controlled in 
> real time by PLC. Failure prediction and behavioral working condition 
> monitoring are the main goals. PLC4x library is a fundamental part of the 
> process.
> Logo: attached to the mail
>
> Best regards,
> Stefano Bossi
>
>



signature.asc
Description: OpenPGP digital signature

Re: Error in using new String feature in 0.8.0-SNAPSHOT

2020-08-21 Thread Stefano Bossi

YESSS !

It works !

I could read a string with a notation like: |%DB1:6:STRING(10)| for
reading 10 chars.

It’s worth to mention here for the community:

  * the notation |%DB1:6:STRING| doesn’t work for the S7 1200 due to the
problem of the request of 256 Byte length which is not supported by
that kind of PLC. The synchronous call hang forever;
  * the notation |%DB1:6.0:STRING(10)| doesn’t work either because raise
a |PlcInvalidFieldException: %DB1:6.0:STRING(10) invalid| exception;

I could confirm that the reading of |DATE_AND_TIME| works too with a
super beautiful output like: |2020-08-21T09:05:24.001890204|

Wonderful 

Thanks Chris for your work!

I will keep going with my tests.

Regards,
Stefano

On 21/08/2020 09:56, Christofer Dutz wrote:

> Hi Stefano,
>
> ok ... so you probably used the STRING type without the limiting feature.
> So if you don't add a "(10)" or whatever max number of elements you want to 
> read, it will still not work.
> The change I applied only lets you limit the number, if you don't is says at 
> 254 unchanged.
>
> But you did find a bug in my code from yesterday, which I just fixed.
>
> So if you update and re-build, it should now fail again like it did before. 
>
> So please try to add the STRING(10) or whatever number you need to the 
> address and it should work.
>
>
> Chris
>
>
>
> Am 21.08.20, 09:51 schrieb "Christofer Dutz" :
>
> Hi Stefano,
>
> ok … if you did it that way, it should have worked …
>
>     I just had another look at your error report and will investigate …
>
> Chris
>
>
>
> Von: Stefano Bossi 
> Datum: Freitag, 21. August 2020 um 09:48
> An: Christofer Dutz 
> Betreff: Re: Error in using new String feature in 0.8.0-SNAPSHOT
>
> ok, I will wait.
>
> let me know.
>
> Anyway, I don't know if this could help, I have downloaded the code from 
> git with git pull and compiled all the modules with ./mvnw install and all 
> went fine
>
> Anyway, I will wait your suggestions.
>
> Many thanks,
> S.
>
>
>
> On 21/08/2020 09:45, Christofer Dutz wrote:
> Hi Stefano,
>
>     I just got an email from our jenkins, complaining that a build failed 
> because of no space left on the agent … I’ll clean it up and re-run the build.
>
>
> Chris
>
>
>
> Von: Stefano Bossi 
> <mailto:stefano.bo...@gmail.com>
> Datum: Freitag, 21. August 2020 um 09:27
> An: "dev@plc4x.apache.org"<mailto:dev@plc4x.apache.org> 
> <mailto:dev@plc4x.apache.org>, Christofer Dutz 
> <mailto:christofer.d...@c-ware.de>
> Betreff: Error in using new String feature in 0.8.0-SNAPSHOT
>
>
> Dear Chris and forum,
>
> I am trying to test your new feature about STRING and DATE_TIME but I 
> have a strange error using HelloPlc4x, it seems I am missing some module…
> Do you spot what am I missing?
>
> I have imported
>
> implementation group: 'org.apache.plc4x', name: 'plc4j-driver-s7', 
> version: '0.8.0-SNAPSHOT'
>
> Here the stack trace
>
> bash-3.2$  /Users/fox/.jenv/versions/openjdk64-13.0.2/bin/java 
> -agentlib:jdwp=transport=dt_socket,server=n,suspend=y,address=localhost:55138 
> -ea -Dfile.encoding=UTF-8 
> @/var/folders/p1/lb5grfpn3tncxdtrptqq9fw4gp/T/cp_7wf4vv0mligcs0a855vuftbrc.argfile
>  it.fox.datapicker.HelloPlc4x --connection-string 
> s7:tcp://192.168.1.192?controller-type=S7_1200 --field-addresses 
> %DB1:6.0:STRING
>
> 2020-08-21 09:23:22,608 main DEBUG Apache Log4j Core 2.13.1 initializing 
> configuration 
> XmlConfiguration[location=/Users/fox/Documents/workspace/2020-06-30 - Data 
> Picker/bin/main/log4j2.xml]
>
> 2020-08-21 09:23:22,615 main DEBUG Installed 1 script engine
>
> Warning: Nashorn engine is planned to be removed from a future JDK release
>
> 2020-08-21 09:23:22,816 main DEBUG Oracle Nashorn version: 13.0.2, 
> language: ECMAScript, threading: Not Thread Safe, compile: true, names: 
> [nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript, ecmascript], 
> factory class: jdk.nashorn.api.scripting.NashornScriptEngineFactory
>
> 2020-08-21 09:23:22,817 main DEBUG PluginManager 'Core' found 122 plugins
>
> 2020-08-21 09:23:22,817 main DEBUG PluginManager 'Level' found 0 plugins
>
> 2020-08-21 09:23:22,821 main DEBUG PluginManager 'Lookup' found 15 plugins
>
> 2020-08-21 09:23:22,823 main DEBUG Building Plugin[name=layout, 
> class=org.apache.logging.log4j.core.layout.PatternLayout].
>
> 2020-08-21 09:23:22,834 main DEBUG PluginManager 'TypeConverter' found 26 
> plugins
>
> 2020-

Error in using new String feature in 0.8.0-SNAPSHOT

2020-08-21 Thread Stefano Bossi

Dear Chris and forum,

I am trying to test your new feature about STRING and DATE_TIME but I
have a strange error using HelloPlc4x, it seems I am missing some module…
Do you spot what am I missing?

I have imported

|implementation group: 'org.apache.plc4x', name: 'plc4j-driver-s7',
version: '0.8.0-SNAPSHOT' |

Here the stack trace

|bash-3.2$ /Users/fox/.jenv/versions/openjdk64-13.0.2/bin/java
-agentlib:jdwp=transport=dt_socket,server=n,suspend=y,address=localhost:55138
-ea -Dfile.encoding=UTF-8
@/var/folders/p1/lb5grfpn3tncxdtrptqq9fw4gp/T/cp_7wf4vv0mligcs0a855vuftbrc.argfile
it.fox.datapicker.HelloPlc4x --connection-string
s7:tcp://192.168.1.192?controller-type=S7_1200 --field-addresses
%DB1:6.0:STRING 2020-08-21 09:23:22,608 main DEBUG Apache Log4j Core
2.13.1 initializing configuration
XmlConfiguration[location=/Users/fox/Documents/workspace/2020-06-30 -
Data Picker/bin/main/log4j2.xml] 2020-08-21 09:23:22,615 main DEBUG
Installed 1 script engine Warning: Nashorn engine is planned to be
removed from a future JDK release 2020-08-21 09:23:22,816 main DEBUG
Oracle Nashorn version: 13.0.2, language: ECMAScript, threading: Not
Thread Safe, compile: true, names: [nashorn, Nashorn, js, JS,
JavaScript, javascript, ECMAScript, ecmascript], factory class:
jdk.nashorn.api.scripting.NashornScriptEngineFactory 2020-08-21
09:23:22,817 main DEBUG PluginManager 'Core' found 122 plugins
2020-08-21 09:23:22,817 main DEBUG PluginManager 'Level' found 0 plugins
2020-08-21 09:23:22,821 main DEBUG PluginManager 'Lookup' found 15
plugins 2020-08-21 09:23:22,823 main DEBUG Building Plugin[name=layout,
class=org.apache.logging.log4j.core.layout.PatternLayout]. 2020-08-21
09:23:22,834 main DEBUG PluginManager 'TypeConverter' found 26 plugins
2020-08-21 09:23:22,846 main DEBUG
PatternLayout$Builder(pattern="[%-5level] %d{HH:mm:ss.SSS}
%logger{36}.%M() - %msg%n", PatternSelector=null,
Configuration(/Users/fox/Documents/workspace/2020-06-30 - Data
Picker/bin/main/log4j2.xml), Replace=null, charset="null",
alwaysWriteExceptions="null", disableAnsi="null",
noConsoleNoAnsi="null", header="null", footer="null") 2020-08-21
09:23:22,846 main DEBUG PluginManager 'Converter' found 44 plugins
2020-08-21 09:23:22,848 main DEBUG Building Plugin[name=appender,
class=org.apache.logging.log4j.core.appender.ConsoleAppender].
2020-08-21 09:23:22,856 main DEBUG
ConsoleAppender$Builder(target="SYSTEM_OUT", follow="null",
direct="null", bufferedIo="null", bufferSize="null",
immediateFlush="null", ignoreExceptions="null", PatternLayout([%-5level]
%d{HH:mm:ss.SSS} %logger{36}.%M() - %msg%n), name="Console",
Configuration(/Users/fox/Documents/workspace/2020-06-30 - Data
Picker/bin/main/log4j2.xml), Filter=null, ={}) 2020-08-21 09:23:22,858
main DEBUG Starting OutputStreamManager SYSTEM_OUT.false.false
2020-08-21 09:23:22,858 main DEBUG Building Plugin[name=appenders,
class=org.apache.logging.log4j.core.config.AppendersPlugin]. 2020-08-21
09:23:22,859 main DEBUG createAppenders(={Console}) 2020-08-21
09:23:22,859 main DEBUG Building Plugin[name=AppenderRef,
class=org.apache.logging.log4j.core.config.AppenderRef]. 2020-08-21
09:23:22,863 main DEBUG createAppenderRef(ref="Console", level="TRACE",
Filter=null) 2020-08-21 09:23:22,864 main DEBUG Building
Plugin[name=root,
class=org.apache.logging.log4j.core.config.LoggerConfig$RootLogger].
2020-08-21 09:23:22,865 main DEBUG createLogger(additivity="false",
level="DEBUG", includeLocation="null", ={Console}, ={},
Configuration(/Users/fox/Documents/workspace/2020-06-30 - Data
Picker/bin/main/log4j2.xml), Filter=null) 2020-08-21 09:23:22,867 main
DEBUG Building Plugin[name=loggers,
class=org.apache.logging.log4j.core.config.LoggersPlugin]. 2020-08-21
09:23:22,868 main DEBUG createLoggers(={root}) 2020-08-21 09:23:22,868
main DEBUG Configuration
XmlConfiguration[location=/Users/fox/Documents/workspace/2020-06-30 -
Data Picker/bin/main/log4j2.xml] initialized 2020-08-21 09:23:22,869
main DEBUG Starting configuration
XmlConfiguration[location=/Users/fox/Documents/workspace/2020-06-30 -
Data Picker/bin/main/log4j2.xml] 2020-08-21 09:23:22,869 main DEBUG
Started configuration
XmlConfiguration[location=/Users/fox/Documents/workspace/2020-06-30 -
Data Picker/bin/main/log4j2.xml] OK. 2020-08-21 09:23:22,872 main DEBUG
Shutting down OutputStreamManager SYSTEM_OUT.false.false-1 2020-08-21
09:23:22,872 main DEBUG OutputStream closed 2020-08-21 09:23:22,873 main
DEBUG Shut down OutputStreamManager SYSTEM_OUT.false.false-1, all
resources released: true 2020-08-21 09:23:22,873 main DEBUG Appender
DefaultConsole-1 stopped with status true 2020-08-21 09:23:22,874 main
DEBUG Stopped
org.apache.logging.log4j.core.config.DefaultConfiguration@234bef66 OK
2020-08-21 09:23:22,948 main DEBUG Registering MBean
org.apache.logging.log4j2:type=55054057 2020-08-21 09:23:22,952 main
DEBUG Registering MBean
org.apache.logging.log4j2:type=55054057,component=StatusLogger
2020-08-21 09:23:22,953 main DEBUG Registering MBean

[jira] [Created] (PLC4X-240) Protocol error in reading string

2020-08-20 Thread Stefano Bossi (Jira)

Stefano Bossi created PLC4X-240:
---

 Summary: Protocol error in reading string
 Key: PLC4X-240
 URL: https://issues.apache.org/jira/browse/PLC4X-240
 Project: Apache PLC4X
  Issue Type: Bug
  Components: Driver-S7
Affects Versions: 0.8.0
Reporter: Stefano Bossi
 Attachments: Screenshot 2020-08-20 at 09.35.58.png, 
captureString_v_0_6_0.pcapng, captureString_v_0_8_0_wrong.pcapng

Dear Christofer,

unfortunately I have found an another issue. 
Via the HelloPlc app I am trying to read a string from my 1200 PLC; here 
attached you could find the screenshot of the DB as configured in the PLC. 
The command line I am using is:

{code:java}
"--connection-string 's7:tcp://192.168.1.192?controller-type=S7_1200' 
--field-addresses '%DB1:6.0:STRING'"
{code}

With the library Version 0.8.0 after the patch Julian introduced here: [Pull 
175|https://github.com/apache/plc4x/pull/175] which fix the reading of Array of 
numbers, the reading of Strings doesn't work any more. 
The error I could read via wireshark is:

{noformat}
[Error code: S7 protocol error: Wrong frames (0x8500)]
{noformat}

With the library version 0.6.0 the string is correctly read.
To help you in your work I have attached a capture with both the library 
version. 
Hope to be useful to fix the bug.

Regards,
Stefano Bossi

P.S. just to let you know, I am trying to read a complex DataBlock and this is 
the reason I am experimenting with a lot of different types of variables. In 
the near future I will try to read some many other and to write some too. 
Unfortunately your code is far too complex for my java knowledge and I am not 
able to fix the bug by myself but I could test the library and send detailed 
report if I found some trouble. Hope this could help anyway.  



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

Re: Reading Array of Int

2020-08-11 Thread Stefano Bossi

HI Julian,

did you have the opportunity to have a look to the regression?

Do you want I open a ticket in jira ?

Regards,
Stefano Bossi



On 07/08/2020 14:23, Stefano Bossi wrote:
>
> Hi Julian,
>
> unfortunately I think I found a regression in your code.
>
> I am using the compiled 0.8.0-SNAPSHOT version of the library which
> fix the reading of INT Arrays, unfortunately this version isn’t no
> more able to real STRING Array !!!
> When I call a sync read of a STRING the
>
> |PlcReadResponse syncResponse = readRequest.execute().get(); |
>
> never come back, it freeze forever.
>
> Here are the captured frame when I ask for |--field-addresses
> '%DB1:6.0:STRING[6]'| via the HelloPlc4x
>
> Request:
>
> |S7 Communication Header: (Job) Parameter: (Read Var) Function: Read
> Var (0x04) Item count: 1 Item [1]: (DB 1.DBX 6.0 CHAR 8) Variable
> specification: 0x12 Length of following address specification: 10
> Syntax Id: S7ANY (0x10) Transport size: CHAR (3) Length: 8 DB number:
> 1 Area: Data blocks (DB) (0x84) Address: 0x30  .000  
> 0011 0... = Byte Address: 6      .000 = Bit
> Address: 0 |
>
> Answer:
>
> |S7 Communication Header: (Ack_Data) Parameter: (Read Var) Function:
> Read Var (0x04) Item count: 1 Data Item [1]: (Success) Return code:
> Success (0xff) Transport size: OCTET STRING (0x09) Length: 8 Data:
> fe0474657374 |
>
> The PLC respond correctly |0474657374| -> |test| STRING.
>
> I have downgraded the library to the 0.7.0 just for testing and it
> works, the answer on the wire is the same and the |get()| call report
> the data correctly.
>
> Is this a regression?
>
> Thanks,
> Stefano Bossi
>
> On 03/08/2020 11:58, Julian Feinauer wrote:
>
>> Thank you Stefano, first for your feedback and second fort he
>> compliments.
>>
>>  
>>
>> We are doing our best and it feels really good if people see our
>> efforts <3
>>
>> Julian
>>
>>  
>>
>> *Von: *Stefano Bossi 
>> *Datum: *Montag, 3. August 2020 um 11:49
>> *An: *, Julian Feinauer
>> , Christofer Dutz
>> 
>> *Betreff: *Re: Reading Array of Int
>>
>>  
>>
>> Thanks you guys 
>>
>> I have downloaded and compiled the develop code and now I cloud read
>> the INT array without any problem!
>>
>> You are managing a great project with a great support !!!
>>
>> Thanks,
>> Stefano
>>
>> On 02/08/2020 21:08, Julian Feinauer wrote:
>>
>> Hi,
>>
>>  
>>
>> sorry for the delayed working on it but I just took a look and think I 
>> fixed the issue.
>>
>>  
>>
>> It seems that arrays where not properly implemented in the S7 Driver (?).
>>
>>  
>>
>> I opened up a PR (https://github.com/apache/plc4x/pull/175) and hope 
>> that @Christofer Dutz finds some time to have a quick look (as he did most 
>> of the work there) and merge it, if he agrees with it.
>>
>>  
>>
>> If you could try out the branch and give your feedback I would be happy.
>>
>>  
>>
>> Thanks for the excellent preparation of work! : )
>>
>>  
>>
>> Julian
>>
>>  
>>
>> Am 02.08.20, 20:40 schrieb "Julian Feinauer" 
>>  <mailto:j.feina...@pragmaticminds.de>:
>>
>>  
>>
>>     Hi,
>>
>>  
>>
>>     I'm looking into it : )
>>
>>  
>>
>>     J
>>
>>  
>>
>>     Am 01.08.20, 16:17 schrieb "Christofer Dutz" 
>>  <mailto:christofer.d...@c-ware.de>:
>>
>>  
>>
>>     Hi Stefano,
>>
>>  
>>
>>     I think such a Jira would be a good idea.
>>
>>  
>>
>>     I’m currently working on the Beckhoff ADS and would try to have 
>> a look as soon as possible.
>>
>>  
>>
>>     Chris
>>
>>  
>>
>>  
>>
>>  
>>
>>     Von: Stefano Bossi  
>> <mailto:stefano.bo...@gmail.com>
>>
>>     Antworten an:  
>> <mailto:dev@plc4x.apache.org>
>>
>>     Datum: Samstag, 1. August 2020 um 11:25
>>
>>     An:  <mailto:dev@plc4x.apache.org>, Julian 
>> Feinauer  <mailto:j.feina...@pragmaticminds.de>
>>
>>     Betreff: Re: Reading Array of Int
>>
>>  
>>
>>     Hi ju

Re: Reading Array of Int

2020-08-07 Thread Stefano Bossi

Hi Julian,

unfortunately I think I found a regression in your code.

I am using the compiled 0.8.0-SNAPSHOT version of the library which fix
the reading of INT Arrays, unfortunately this version isn’t no more able
to real STRING Array !!!
When I call a sync read of a STRING the

|PlcReadResponse syncResponse = readRequest.execute().get(); |

never come back, it freeze forever.

Here are the captured frame when I ask for |--field-addresses
'%DB1:6.0:STRING[6]'| via the HelloPlc4x

Request:

|S7 Communication Header: (Job) Parameter: (Read Var) Function: Read Var
(0x04) Item count: 1 Item [1]: (DB 1.DBX 6.0 CHAR 8) Variable
specification: 0x12 Length of following address specification: 10 Syntax
Id: S7ANY (0x10) Transport size: CHAR (3) Length: 8 DB number: 1 Area:
Data blocks (DB) (0x84) Address: 0x30  .000   0011 0...
= Byte Address: 6      .000 = Bit Address: 0 |

Answer:

|S7 Communication Header: (Ack_Data) Parameter: (Read Var) Function:
Read Var (0x04) Item count: 1 Data Item [1]: (Success) Return code:
Success (0xff) Transport size: OCTET STRING (0x09) Length: 8 Data:
fe0474657374 |

The PLC respond correctly |0474657374| -> |test| STRING.

I have downgraded the library to the 0.7.0 just for testing and it
works, the answer on the wire is the same and the |get()| call report
the data correctly.

Is this a regression?

Thanks,
Stefano Bossi

On 03/08/2020 11:58, Julian Feinauer wrote:

> Thank you Stefano, first for your feedback and second fort he
> compliments.
>
>  
>
> We are doing our best and it feels really good if people see our
> efforts <3
>
> Julian
>
>  
>
> *Von: *Stefano Bossi 
> *Datum: *Montag, 3. August 2020 um 11:49
> *An: *, Julian Feinauer
> , Christofer Dutz
> 
> *Betreff: *Re: Reading Array of Int
>
>  
>
> Thanks you guys 
>
> I have downloaded and compiled the develop code and now I cloud read
> the INT array without any problem!
>
> You are managing a great project with a great support !!!
>
> Thanks,
> Stefano
>
> On 02/08/2020 21:08, Julian Feinauer wrote:
>
> Hi,
>
>  
>
> sorry for the delayed working on it but I just took a look and think I 
> fixed the issue.
>
>  
>
> It seems that arrays where not properly implemented in the S7 Driver (?).
>
>  
>
> I opened up a PR (https://github.com/apache/plc4x/pull/175) and hope that 
> @Christofer Dutz finds some time to have a quick look (as he did most of the 
> work there) and merge it, if he agrees with it.
>
>  
>
> If you could try out the branch and give your feedback I would be happy.
>
>  
>
> Thanks for the excellent preparation of work! : )
>
>  
>
> Julian
>
>  
>
> Am 02.08.20, 20:40 schrieb "Julian Feinauer" 
>  <mailto:j.feina...@pragmaticminds.de>:
>
>  
>
>     Hi,
>
>  
>
>     I'm looking into it : )
>
>  
>
>     J
>
>  
>
>     Am 01.08.20, 16:17 schrieb "Christofer Dutz" 
>  <mailto:christofer.d...@c-ware.de>:
>
>  
>
>     Hi Stefano,
>
>  
>
>     I think such a Jira would be a good idea.
>
>  
>
>     I’m currently working on the Beckhoff ADS and would try to have a 
> look as soon as possible.
>
>  
>
>     Chris
>
>  
>
>  
>
>  
>
>     Von: Stefano Bossi  
> <mailto:stefano.bo...@gmail.com>
>
>     Antworten an:  <mailto:dev@plc4x.apache.org>
>
>     Datum: Samstag, 1. August 2020 um 11:25
>
>     An:  <mailto:dev@plc4x.apache.org>, Julian 
> Feinauer  <mailto:j.feina...@pragmaticminds.de>
>
>     Betreff: Re: Reading Array of Int
>
>  
>
>     Hi julian,
>
>  
>
>     if you need or think could simplify the development I could open 
> a jira ticket and upload a couple of pcap capture for you.
>
>  
>
>     As I wrote I am using the 0.7.0 version from Maven and I am 
> talking with a real Siemens 1200 with firmware 1.2 (pretty old but I didn't 
> find a way to upgrade it ).
>
>  
>
>     Let me know.
>
>  
>
>     Thanks for help.
>
>  
>
>     Regards,
>
>     Stefano
>
>  
>
>     On 30/07/2020 07:49, Julian Feinauer wrote:
>
>      
>
>     Hey Stefano, I will try to have a look later today. Are you using 
> plc4x version 0.6 or 0.7?
>
>  
>
>  
>
>  
>
>     Thank you!
>
>  
>
&g

Re: Reading Array of Int

2020-08-03 Thread Stefano Bossi

Thanks you guys 

I have downloaded and compiled the develop code and now I cloud read the
INT array without any problem!

You are managing a great project with a great support !!!

Thanks,
Stefano


On 02/08/2020 21:08, Julian Feinauer wrote:
> Hi,
>
> sorry for the delayed working on it but I just took a look and think I fixed 
> the issue.
>
> It seems that arrays where not properly implemented in the S7 Driver (?).
>
> I opened up a PR (https://github.com/apache/plc4x/pull/175) and hope that 
> @Christofer Dutz finds some time to have a quick look (as he did most of the 
> work there) and merge it, if he agrees with it.
>
> If you could try out the branch and give your feedback I would be happy.
>
> Thanks for the excellent preparation of work! : )
>
> Julian
>
> Am 02.08.20, 20:40 schrieb "Julian Feinauer" :
>
> Hi,
>
> I'm looking into it : )
>
> J
>
> Am 01.08.20, 16:17 schrieb "Christofer Dutz" :
>
> Hi Stefano,
>
> I think such a Jira would be a good idea.
>
> I’m currently working on the Beckhoff ADS and would try to have a 
> look as soon as possible.
>
> Chris
>
>
>
> Von: Stefano Bossi 
> Antworten an: 
> Datum: Samstag, 1. August 2020 um 11:25
> An: , Julian Feinauer 
> 
> Betreff: Re: Reading Array of Int
>
> Hi julian,
>
> if you need or think could simplify the development I could open a 
> jira ticket and upload a couple of pcap capture for you.
>
> As I wrote I am using the 0.7.0 version from Maven and I am talking 
> with a real Siemens 1200 with firmware 1.2 (pretty old but I didn't find a 
> way to upgrade it ).
>
> Let me know.
>
> Thanks for help.
>
> Regards,
> Stefano
>
> On 30/07/2020 07:49, Julian Feinauer wrote:
>
> Hey Stefano, I will try to have a look later today. Are you using 
> plc4x version 0.6 or 0.7?
>
>
>
> Thank you!
>
>
>
> Julian
>
>
>
> Holen Sie sich Outlook für 
> Android<https://aka.ms/ghei36><https://aka.ms/ghei36>
>
>
>
> 
>
> Von: Stefano Bossi 
> <mailto:stefano.bo...@gmail.com>
>
> Gesendet: Mittwoch, 29. Juli 2020, 12:32
>
> An: dev@plc4x.apache.org<mailto:dev@plc4x.apache.org>; Christofer Dutz
>
> Betreff: Re: Reading Array of Int
>
>
>
> Thanks Chris,
>
>
>
> yes definitely this is a workaround, I am experimenting and learning.
>
>
>
> I really appreciate your time on the investigation of the issue.
>
>
>
> Thanks,
>
> Stefano Bossi
>
>
>
>
>
>
>
> On 29/07/2020 12:08, Christofer Dutz wrote:
>
>
>
> Well that’s a workaround, but not a fix …
>
>
>
> We should focus on fixing this.
>
>
>
> I’ll investigate the issue as soon as I’m done with the Beckhoff 
> ADS/AMS stuff …
>
>
>
> Perhaps Julian could find some time to investigate?
>
>
>
> Chris
>
>
>
>
>
>
>
> Von: Stefano Bossi 
> <mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com><mailto:stefano.bo...@gmail.com>
>
> Antworten an: 
> <mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org>
>
> Datum: Mittwoch, 29. Juli 2020 um 11:41
>
> An: 
> <mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org><mailto:dev@plc4x.apache.org>
>
> Betreff: Re: Reading Array of Int
>
>
>
>
>
> I have adopted a workaround reading all the INT variable separated.
>
>
>
> --connection-string 's7:tcp://192.168.1.192?controller-type=S7_1200' 
> --field-addresses '%DB1:274.0:INT' '%DB1:276.0:INT' '%DB1:278.0:INT' 
> '%DB1:280.0:INT'
>
>
>
> In this way on the wire you have:
>
> the query:
>
>
>
> Frame 296: 111 bytes on wire (888 bits), 111 bytes captured (888 
> bits) on interface utun2, id 0
>
>
>
> Null/Loopback
>
>
>
> Internet Protocol Version 4, Src: 192.168.100.4, Dst: 192.168.1.192
>
>
>
> Transmission Control Protocol, Src Port: 57188, Dst Port: 102, Seq: 
> 48, Ack: 50, Len: 67
>
>
>
> TPKT, Version: 3, Length: 67
>
>
>
> ISO 8073/X.224 COTP Connection-Oriented Transport Protocol
>
>
>
> S7 Communication

Re: Reading Array of Int

2020-08-01 Thread Stefano Bossi

Hi julian,

if you need or think could simplify the development I could open a jira
ticket and upload a couple of pcap capture for you.

As I wrote I am using the 0.7.0 version from Maven and I am talking with
a real Siemens 1200 with firmware 1.2 (pretty old but I didn't find a
way to upgrade it ).

Let me know.

Thanks for help.

Regards,
Stefano


On 30/07/2020 07:49, Julian Feinauer wrote:
> Hey Stefano, I will try to have a look later today. Are you using plc4x 
> version 0.6 or 0.7?
>
> Thank you!
>
> Julian
>
> Holen Sie sich Outlook für Android<https://aka.ms/ghei36>
>
> ________
> Von: Stefano Bossi 
> Gesendet: Mittwoch, 29. Juli 2020, 12:32
> An: dev@plc4x.apache.org; Christofer Dutz
> Betreff: Re: Reading Array of Int
>
> Thanks Chris,
>
> yes definitely this is a workaround, I am experimenting and learning.
>
> I really appreciate your time on the investigation of the issue.
>
> Thanks,
> Stefano Bossi
>
>
>
> On 29/07/2020 12:08, Christofer Dutz wrote:
>
> Well that’s a workaround, but not a fix …
>
> We should focus on fixing this.
>
> I’ll investigate the issue as soon as I’m done with the Beckhoff ADS/AMS 
> stuff …
>
> Perhaps Julian could find some time to investigate?
>
> Chris
>
>
>
> Von: Stefano Bossi <mailto:stefano.bo...@gmail.com>
> Antworten an: <mailto:dev@plc4x.apache.org>
> Datum: Mittwoch, 29. Juli 2020 um 11:41
> An: <mailto:dev@plc4x.apache.org>
> Betreff: Re: Reading Array of Int
>
>
> I have adopted a workaround reading all the INT variable separated.
>
> --connection-string 's7:tcp://192.168.1.192?controller-type=S7_1200' 
> --field-addresses '%DB1:274.0:INT' '%DB1:276.0:INT' '%DB1:278.0:INT' 
> '%DB1:280.0:INT'
>
> In this way on the wire you have:
> the query:
>
> Frame 296: 111 bytes on wire (888 bits), 111 bytes captured (888 bits) on 
> interface utun2, id 0
>
> Null/Loopback
>
> Internet Protocol Version 4, Src: 192.168.100.4, Dst: 192.168.1.192
>
> Transmission Control Protocol, Src Port: 57188, Dst Port: 102, Seq: 48, Ack: 
> 50, Len: 67
>
> TPKT, Version: 3, Length: 67
>
> ISO 8073/X.224 COTP Connection-Oriented Transport Protocol
>
> S7 Communication
>
> Header: (Job)
>
> Parameter: (Read Var)
>
> Function: Read Var (0x04)
>
> Item count: 4
>
> Item [1]: (DB 1.DBX 274.0 INT 1)
>
> Item [2]: (DB 1.DBX 276.0 INT 1)
>
> Item [3]: (DB 1.DBX 278.0 INT 1)
>
> Item [4]: (DB 1.DBX 280.0 INT 1)
>
> the answer:
>
> Frame 297: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) on 
> interface utun2, id 0
>
> Null/Loopback
>
> Internet Protocol Version 4, Src: 192.168.1.192, Dst: 192.168.100.4
>
> Transmission Control Protocol, Src Port: 102, Dst Port: 57188, Seq: 50, Ack: 
> 115, Len: 45
>
> TPKT, Version: 3, Length: 45
>
> ISO 8073/X.224 COTP Connection-Oriented Transport Protocol
>
> S7 Communication
>
> Header: (Ack_Data)
>
> Parameter: (Read Var)
>
> Function: Read Var (0x04)
>
> Item count: 4
>
> Data
>
> Item [1]: (Success)
>
> Item [2]: (Success)
>
> Item [3]: (Success)
>
> Item [4]: (Success)
>
> [INFO ] 10:15:44.727 it.fox.datapicker.HelloPlc4x.printResponse() - 
> Value[value-0]: 10
>
> [INFO ] 10:15:44.733 it.fox.datapicker.HelloPlc4x.printResponse() - 
> Value[value-1]: 11
>
> [INFO ] 10:15:44.737 it.fox.datapicker.HelloPlc4x.printResponse() - 
> Value[value-2]: 12
>
> [INFO ] 10:15:44.741 it.fox.datapicker.HelloPlc4x.printResponse() - 
> Value[value-3]: 13
>
> Unfortunately my java knowledge are not so advanced to fix the bug in reading 
> the array in a single command, anyway there’s a workaround.
>
> Hope this mail help some newbies like me to find the right way to read data 
> from the PLC.
>
> Regards,
> Stefano
>
> On 28/07/2020 11:38, Stefano Bossi wrote:
>
> Dear plc4x forum,
>
> I have found a possible problem in reading an array of INT.
> I am using the HelloPlc4x app for testing and I am trying to read the field 
> address: '%DB1:274.0:INT[3]'
>
> In the request, captured via wireShark I can see the query:
>
> Frame 3: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on 
> interface utun2, id 0
>
> Null/Loopback
>
> Internet Protocol Version 4, Src: 192.168.100.4, Dst: 192.168.1.192
>
> Transmission Control Protocol, Src Port: 54543, Dst Port: 102, Seq: 1, Ack: 
> 1, Len: 31
>
> TPKT, Version: 3, Length: 31
>
> ISO 8073/X.224 COTP Connection-Oriented Transport Protocol
>

Re: Reading Array of Int

2020-07-31 Thread Stefano Bossi

Hi Julian,

sorry for the late reply. I am using the 0.7 version.

Thanks for your help,
Stefano

Il gio 30 lug 2020, 07:49 Julian Feinauer  ha
scritto:

> Hey Stefano, I will try to have a look later today. Are you using plc4x
> version 0.6 or 0.7?
>
> Thank you!
>
> Julian
>
> Holen Sie sich Outlook für Android<https://aka.ms/ghei36>
>
> ________
> Von: Stefano Bossi 
> Gesendet: Mittwoch, 29. Juli 2020, 12:32
> An: dev@plc4x.apache.org; Christofer Dutz
> Betreff: Re: Reading Array of Int
>
> Thanks Chris,
>
> yes definitely this is a workaround, I am experimenting and learning.
>
> I really appreciate your time on the investigation of the issue.
>
> Thanks,
> Stefano Bossi
>
>
>
> On 29/07/2020 12:08, Christofer Dutz wrote:
>
> Well that’s a workaround, but not a fix …
>
> We should focus on fixing this.
>
> I’ll investigate the issue as soon as I’m done with the Beckhoff ADS/AMS
> stuff …
>
> Perhaps Julian could find some time to investigate?
>
> Chris
>
>
>
> Von: Stefano Bossi  stefano.bo...@gmail.com>
> Antworten an: <mailto:dev@plc4x.apache.org>
> Datum: Mittwoch, 29. Juli 2020 um 11:41
> An: <mailto:dev@plc4x.apache.org>
> Betreff: Re: Reading Array of Int
>
>
> I have adopted a workaround reading all the INT variable separated.
>
> --connection-string 's7:tcp://192.168.1.192?controller-type=S7_1200'
> --field-addresses '%DB1:274.0:INT' '%DB1:276.0:INT' '%DB1:278.0:INT'
> '%DB1:280.0:INT'
>
> In this way on the wire you have:
> the query:
>
> Frame 296: 111 bytes on wire (888 bits), 111 bytes captured (888 bits) on
> interface utun2, id 0
>
> Null/Loopback
>
> Internet Protocol Version 4, Src: 192.168.100.4, Dst: 192.168.1.192
>
> Transmission Control Protocol, Src Port: 57188, Dst Port: 102, Seq: 48,
> Ack: 50, Len: 67
>
> TPKT, Version: 3, Length: 67
>
> ISO 8073/X.224 COTP Connection-Oriented Transport Protocol
>
> S7 Communication
>
> Header: (Job)
>
> Parameter: (Read Var)
>
> Function: Read Var (0x04)
>
> Item count: 4
>
> Item [1]: (DB 1.DBX 274.0 INT 1)
>
> Item [2]: (DB 1.DBX 276.0 INT 1)
>
> Item [3]: (DB 1.DBX 278.0 INT 1)
>
> Item [4]: (DB 1.DBX 280.0 INT 1)
>
> the answer:
>
> Frame 297: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) on
> interface utun2, id 0
>
> Null/Loopback
>
> Internet Protocol Version 4, Src: 192.168.1.192, Dst: 192.168.100.4
>
> Transmission Control Protocol, Src Port: 102, Dst Port: 57188, Seq: 50,
> Ack: 115, Len: 45
>
> TPKT, Version: 3, Length: 45
>
> ISO 8073/X.224 COTP Connection-Oriented Transport Protocol
>
> S7 Communication
>
> Header: (Ack_Data)
>
> Parameter: (Read Var)
>
> Function: Read Var (0x04)
>
> Item count: 4
>
> Data
>
> Item [1]: (Success)
>
> Item [2]: (Success)
>
> Item [3]: (Success)
>
> Item [4]: (Success)
>
> [INFO ] 10:15:44.727 it.fox.datapicker.HelloPlc4x.printResponse() -
> Value[value-0]: 10
>
> [INFO ] 10:15:44.733 it.fox.datapicker.HelloPlc4x.printResponse() -
> Value[value-1]: 11
>
> [INFO ] 10:15:44.737 it.fox.datapicker.HelloPlc4x.printResponse() -
> Value[value-2]: 12
>
> [INFO ] 10:15:44.741 it.fox.datapicker.HelloPlc4x.printResponse() -
> Value[value-3]: 13
>
> Unfortunately my java knowledge are not so advanced to fix the bug in
> reading the array in a single command, anyway there’s a workaround.
>
> Hope this mail help some newbies like me to find the right way to read
> data from the PLC.
>
> Regards,
> Stefano
>
> On 28/07/2020 11:38, Stefano Bossi wrote:
>
> Dear plc4x forum,
>
> I have found a possible problem in reading an array of INT.
> I am using the HelloPlc4x app for testing and I am trying to read the
> field address: '%DB1:274.0:INT[3]'
>
> In the request, captured via wireShark I can see the query:
>
> Frame 3: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on
> interface utun2, id 0
>
> Null/Loopback
>
> Internet Protocol Version 4, Src: 192.168.100.4, Dst: 192.168.1.192
>
> Transmission Control Protocol, Src Port: 54543, Dst Port: 102, Seq: 1,
> Ack: 1, Len: 31
>
> TPKT, Version: 3, Length: 31
>
> ISO 8073/X.224 COTP Connection-Oriented Transport Protocol
>
> S7 Communication
>
> Header: (Job)
>
> Parameter: (Read Var)
>
> Function: Read Var (0x04)
>
> Item count: 1
>
> Item [1]: (DB 1.DBX 274.0 INT 3)
>
> Variable specification: 0x12
>
&

Re: Reading Array of Int

2020-07-29 Thread Stefano Bossi

I have adopted a workaround reading all the INT variable separated.

|--connection-string 's7:tcp://192.168.1.192?controller-type=S7_1200'
--field-addresses '%DB1:274.0:INT' '%DB1:276.0:INT' '%DB1:278.0:INT'
'%DB1:280.0:INT' |

In this way on the wire you have:
the query:

|Frame 296: 111 bytes on wire (888 bits), 111 bytes captured (888 bits)
on interface utun2, id 0 Null/Loopback Internet Protocol Version 4, Src:
192.168.100.4, Dst: 192.168.1.192 Transmission Control Protocol, Src
Port: 57188, Dst Port: 102, Seq: 48, Ack: 50, Len: 67 TPKT, Version: 3,
Length: 67 ISO 8073/X.224 COTP Connection-Oriented Transport Protocol S7
Communication Header: (Job) Parameter: (Read Var) Function: Read Var
(0x04) Item count: 4 Item [1]: (DB 1.DBX 274.0 INT 1) Item [2]: (DB
1.DBX 276.0 INT 1) Item [3]: (DB 1.DBX 278.0 INT 1) Item [4]: (DB 1.DBX
280.0 INT 1) |

the answer:

|Frame 297: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) on
interface utun2, id 0 Null/Loopback Internet Protocol Version 4, Src:
192.168.1.192, Dst: 192.168.100.4 Transmission Control Protocol, Src
Port: 102, Dst Port: 57188, Seq: 50, Ack: 115, Len: 45 TPKT, Version: 3,
Length: 45 ISO 8073/X.224 COTP Connection-Oriented Transport Protocol S7
Communication Header: (Ack_Data) Parameter: (Read Var) Function: Read
Var (0x04) Item count: 4 Data Item [1]: (Success) Item [2]: (Success)
Item [3]: (Success) Item [4]: (Success) |

|[INFO ] 10:15:44.727 it.fox.datapicker.HelloPlc4x.printResponse() -
Value[value-0]: 10 [INFO ] 10:15:44.733
it.fox.datapicker.HelloPlc4x.printResponse() - Value[value-1]: 11 [INFO
] 10:15:44.737 it.fox.datapicker.HelloPlc4x.printResponse() -
Value[value-2]: 12 [INFO ] 10:15:44.741
it.fox.datapicker.HelloPlc4x.printResponse() - Value[value-3]: 13 |

Unfortunately my java knowledge are not so advanced to fix the bug in
reading the array in a single command, anyway there’s a workaround.

Hope this mail help some newbies like me to find the right way to read
data from the PLC.

Regards,
Stefano

On 28/07/2020 11:38, Stefano Bossi wrote:

> Dear plc4x forum,
>
> I have found a possible problem in reading an array of INT.
> I am using the HelloPlc4x app for testing and I am trying to read the
> field address: |'%DB1:274.0:INT[3]'|
>
> In the request, captured via wireShark I can see the query:
>
> |Frame 3: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on
> interface utun2, id 0 Null/Loopback Internet Protocol Version 4, Src:
> 192.168.100.4, Dst: 192.168.1.192 Transmission Control Protocol, Src
> Port: 54543, Dst Port: 102, Seq: 1, Ack: 1, Len: 31 TPKT, Version: 3,
> Length: 31 ISO 8073/X.224 COTP Connection-Oriented Transport Protocol
> S7 Communication Header: (Job) Parameter: (Read Var) Function: Read
> Var (0x04) Item count: 1 Item [1]: (DB 1.DBX 274.0 INT 3) Variable
> specification: 0x12 Length of following address specification: 10
> Syntax Id: S7ANY (0x10) Transport size: INT (5) Length: 3 DB number: 1
> Area: Data blocks (DB) (0x84) Address: 0x000890 |
>
> and the response:
>
> |Frame 4: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on
> interface utun2, id 0 Null/Loopback Internet Protocol Version 4, Src:
> 192.168.1.192, Dst: 192.168.100.4 Transmission Control Protocol, Src
> Port: 102, Dst Port: 54543, Seq: 1, Ack: 32, Len: 31 TPKT, Version: 3,
> Length: 31 ISO 8073/X.224 COTP Connection-Oriented Transport Protocol
> S7 Communication Header: (Ack_Data) Parameter: (Read Var) Function:
> Read Var (0x04) Item count: 1 Data Item [1]: (Success) Return code:
> Success (0xff) Transport size: INTEGER (0x05) Length: 6 Data:
> 000a000b000c |
>
> The 3 INT I would like to read are there: |000a|, |000b|, |000c| but
> in the response of:
>
> |PlcReadResponse syncResponse = readRequest.execute().get(); |
>
> only the first one is present.
>
> I read in jira that there was a similar bug here PLC4X-57
> <https://issues.apache.org/jira/browse/PLC4X-57>, is this the same
> problem?
>
> Thanks for your help.
>
> Regards,
> Steafano Bossi
>
> 




signature.asc
Description: OpenPGP digital signature

Reading Array of Int

2020-07-28 Thread Stefano Bossi

Dear plc4x forum,

I have found a possible problem in reading an array of INT.
I am using the HelloPlc4x app for testing and I am trying to read the
field address: |'%DB1:274.0:INT[3]'|

In the request, captured via wireShark I can see the query:

|Frame 3: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on
interface utun2, id 0 Null/Loopback Internet Protocol Version 4, Src:
192.168.100.4, Dst: 192.168.1.192 Transmission Control Protocol, Src
Port: 54543, Dst Port: 102, Seq: 1, Ack: 1, Len: 31 TPKT, Version: 3,
Length: 31 ISO 8073/X.224 COTP Connection-Oriented Transport Protocol S7
Communication Header: (Job) Parameter: (Read Var) Function: Read Var
(0x04) Item count: 1 Item [1]: (DB 1.DBX 274.0 INT 3) Variable
specification: 0x12 Length of following address specification: 10 Syntax
Id: S7ANY (0x10) Transport size: INT (5) Length: 3 DB number: 1 Area:
Data blocks (DB) (0x84) Address: 0x000890 |

and the response:

|Frame 4: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on
interface utun2, id 0 Null/Loopback Internet Protocol Version 4, Src:
192.168.1.192, Dst: 192.168.100.4 Transmission Control Protocol, Src
Port: 102, Dst Port: 54543, Seq: 1, Ack: 32, Len: 31 TPKT, Version: 3,
Length: 31 ISO 8073/X.224 COTP Connection-Oriented Transport Protocol S7
Communication Header: (Ack_Data) Parameter: (Read Var) Function: Read
Var (0x04) Item count: 1 Data Item [1]: (Success) Return code: Success
(0xff) Transport size: INTEGER (0x05) Length: 6 Data: 000a000b000c |

The 3 INT I would like to read are there: |000a|, |000b|, |000c| but in
the response of:

|PlcReadResponse syncResponse = readRequest.execute().get(); |

only the first one is present.

I read in jira that there was a similar bug here PLC4X-57
, is this the same problem?

Thanks for your help.

Regards,
Steafano Bossi




signature.asc
Description: OpenPGP digital signature

Re: Connection died after disconnection

2020-07-27 Thread Stefano Bossi

Hi Chris,

I follow your suggestion and I have opened a Jira ticket with a couple
of capture.

Here is the link:
https://issues.apache.org/jira/browse/PLC4X-220

Regards,
Steafano Bossi


On 25/07/2020 10:33, Christofer Dutz wrote:
> Hi Stefano, 
>
> Connection reset looks like the remote hung up. 
> In general the code looks good. One thing you could do would be to do
> a wireshark recording. Then we can identify what's going wrong. 
>
> In that case ideally create a jira issue and attach that pcapng file
> to that. 
>
> Chris
> --------
> *Von:* Stefano Bossi 
> *Gesendet:* Samstag, 25. Juli 2020 09:06
> *An:* dev@plc4x.apache.org 
> *Betreff:* Re: Connection died after disconnection
>  
>
> Dear Chris,
>
> I tried to follow your suggestions but I still have some problem.
>
> I wrote a test application to show you the problem and ask suggestions.
> Basically my app fire a couple of thread which read a field in a DB
> continuously; the problem is that after some seconds one of the two
> thread fire an untrappable exception and the software dies.
> Here is my code:
>
> |package it.fox; import org.apache.logging.log4j.LogManager; import
> org.apache.logging.log4j.Logger; import
> org.apache.plc4x.java.api.PlcConnection; import
> org.apache.plc4x.java.utils.connectionpool.PooledPlcDriverManager;
> public class App { private static final Logger logger =
> LogManager.getLogger(App.class); public static void main(String[]
> args) { try { PlcConnection plcConnection = new
> PooledPlcDriverManager().getConnection("s7://192.168.1.192?controller-type=S7_1200");
> if (plcConnection.getMetadata().canRead() ) { Poller01 poller01 = new
> Poller01(); poller01.start(plcConnection); Poller02 poller02 = new
> Poller02(); poller02.start(plcConnection); } else { logger.error("This
> connection doesn't support reading."); Thread.sleep(5000); } } catch
> (Exception exception) { logger.error("Error connecting to the PLC",
> exception); } } } |
> |package it.fox; import java.util.concurrent.TimeUnit; import
> org.apache.logging.log4j.LogManager; import
> org.apache.logging.log4j.Logger; import
> org.apache.plc4x.java.api.PlcConnection; import
> org.apache.plc4x.java.api.messages.PlcReadRequest; import
> org.apache.plc4x.java.api.messages.PlcReadResponse; public class
> Poller01 implements Runnable { private static final Logger logger =
> LogManager.getLogger(Poller01.class); private Thread thread; private
> PlcConnection plcConnection; @Override public void run() {
> PlcReadRequest.Builder requestBuilder =
> plcConnection.readRequestBuilder(); requestBuilder.addItem("data",
> "%DB1:262.0:INT"); PlcReadRequest readRequest =
> requestBuilder.build(); while(true){ try { PlcReadResponse response =
> readRequest.execute().get(5000, TimeUnit.MILLISECONDS); if (response
> != null){ logger.info("poller01 = {}", response.getPlcValue("data") );
> Thread.sleep( (int) Math.floor(Math.random() * 100) ); } else {
> logger.error("No response from PLC in reading polling variable");
> break; } } catch (Exception e) { logger.error("Poller01 Exception",
> e); } } } /** * Start the thread */ public void start(PlcConnection
> plcConnection) { this.plcConnection = plcConnection;
> logger.info("Starting poller01 thread"); if (thread == null) { thread
> = new Thread(this, "poller01"); thread.start(); } } } |
> |package it.fox; import java.util.concurrent.TimeUnit; import
> org.apache.logging.log4j.LogManager; import
> org.apache.logging.log4j.Logger; import
> org.apache.plc4x.java.api.PlcConnection; import
> org.apache.plc4x.java.api.messages.PlcReadRequest; import
> org.apache.plc4x.java.api.messages.PlcReadResponse; public class
> Poller02 implements Runnable{ private static final Logger logger =
> LogManager.getLogger(Poller02.class); private Thread thread; private
> PlcConnection plcConnection; @Override public void run() {
> PlcReadRequest.Builder requestBuilder =
> plcConnection.readRequestBuilder(); requestBuilder.addItem("data",
> "%DB1:0.0:DINT"); PlcReadRequest readRequest = requestBuilder.build();
> while(true){ try { PlcReadResponse response =
> readRequest.execute().get(5000, TimeUnit.MILLISECONDS); if (response
> != null){ logger.info("poller02 = {}", response.getPlcValue("data") );
> Thread.sleep( (int) Math.floor(Math.random() * 500) ); } else {
> logger.error("No response from PLC in reading polling variable");
> break; } } catch (Exception e) { logger.error("Poller01 Exception",
> e); } } } /** * Start the thread */ public void start(PlcConnection
> plcConnec

[jira] [Created] (PLC4X-220) Connection die in multithreading

2020-07-27 Thread Stefano Bossi (Jira)

Stefano Bossi created PLC4X-220:
---

 Summary: Connection die in multithreading
 Key: PLC4X-220
 URL: https://issues.apache.org/jira/browse/PLC4X-220
 Project: Apache PLC4X
  Issue Type: Bug
  Components: Driver-S7
Affects Versions: 0.7.0
Reporter: Stefano Bossi
 Attachments: capture01.pcapng, capture02.pcapng

Dear developers,

I wrote a test application to show you the problem as requested.
The test app fire a couple of thread which read a field in a DB (Siemens 1200 
S7) continuously; the problem is that after some seconds one of the two thread 
fire an untrappable exception and the software dies.
Here is my code:
```java
package it.fox;

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.plc4x.java.api.PlcConnection;
import org.apache.plc4x.java.utils.connectionpool.PooledPlcDriverManager;

public class App {

private static final Logger logger = LogManager.getLogger(App.class);
public static void main(String[] args) {

try {
PlcConnection plcConnection = new 
PooledPlcDriverManager().getConnection("s7://192.168.1.192?controller-type=S7_1200");
if (plcConnection.getMetadata().canRead() ) {
Poller01 poller01 = new Poller01();
poller01.start(plcConnection);
Poller02 poller02 = new Poller02();
poller02.start(plcConnection);

} else {
logger.error("This connection doesn't support reading.");
Thread.sleep(5000);
}
} catch (Exception exception) {
logger.error("Error connecting to the PLC", exception);
}
}
}
```
```java
package it.fox;

import java.util.concurrent.TimeUnit;

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.plc4x.java.api.PlcConnection;
import org.apache.plc4x.java.api.messages.PlcReadRequest;
import org.apache.plc4x.java.api.messages.PlcReadResponse;

public class Poller01 implements Runnable {

private static final Logger logger = LogManager.getLogger(Poller01.class);
private Thread thread;
private PlcConnection plcConnection;

@Override
public void run() {
PlcReadRequest.Builder requestBuilder = 
plcConnection.readRequestBuilder();
requestBuilder.addItem("data", "%DB1:262.0:INT");
PlcReadRequest readRequest = requestBuilder.build();
while(true){
try {
PlcReadResponse response = readRequest.execute().get(5000, 
TimeUnit.MILLISECONDS);
if (response != null){
logger.info("poller01 = {}", response.getPlcValue("data") );
Thread.sleep( (int) Math.floor(Math.random() * 100) );
} else {
logger.error("No response from PLC in reading polling 
variable");
break;
}
} catch (Exception e) {
logger.error("Poller01 Exception", e);
}
}
}

/**
 * Start the thread
 */
public void start(PlcConnection plcConnection) {
this.plcConnection = plcConnection;
logger.info("Starting poller01 thread");
if (thread == null) {
thread = new Thread(this, "poller01");
thread.start();
}
}

}
```
```java
package it.fox;

import java.util.concurrent.TimeUnit;

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.plc4x.java.api.PlcConnection;
import org.apache.plc4x.java.api.messages.PlcReadRequest;
import org.apache.plc4x.java.api.messages.PlcReadResponse;

public class Poller02 implements Runnable{

private static final Logger logger = LogManager.getLogger(Poller02.class);
private Thread thread;
private PlcConnection plcConnection;

@Override
public void run() {
PlcReadRequest.Builder requestBuilder = 
plcConnection.readRequestBuilder();
requestBuilder.addItem("data", "%DB1:0.0:DINT");
PlcReadRequest readRequest = requestBuilder.build();
while(true){
try {
PlcReadResponse response = readRequest.execute().get(5000, 
TimeUnit.MILLISECONDS);
if (response != null){
logger.info("poller02 = {}", response.getPlcValue("data") );
Thread.sleep( (int) Math.floor(Math.random() * 500) );
} else {
logger.error("No response from PLC in reading polling 
variable");
break;
}
} catch (Exception e) {
logger.error("Poller01 Exception", e);

Re: Connection died after disconnection

2020-07-25 Thread Stefano Bossi

poller02 = 12139 [INFO ] 22:59:20.347
it.fox.Poller01.run() - poller01 = 7 [INFO ] 22:59:20.400
it.fox.Poller01.run() - poller01 = 7 [INFO ] 22:59:20.530
it.fox.Poller01.run() - poller01 = 7 [INFO ] 22:59:20.661
it.fox.Poller01.run() - poller01 = 7 [INFO ] 22:59:20.726
it.fox.Poller02.run() - poller02 = 12139 [INFO ] 22:59:20.786
it.fox.Poller01.run() - poller01 = 7 [INFO ] 22:59:20.913
it.fox.Poller01.run() - poller01 = 7 [INFO ] 22:59:21.035
it.fox.Poller02.run() - poller02 = 12139 [WARN ] 22:59:21.046
io.netty.channel.DefaultChannelPipeline.onUnhandledInboundException() -
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.net.SocketException: Connection reset at
sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:345)
~[?:?] SocketChannelImpl.java:345 at
sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:376) ~[?:?]
SocketChannelImpl.java:376 at
io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
~[netty-buffer-4.1.47.Final.jar:4.1.47.Final] PooledByteBuf.java:253 at
io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
~[netty-buffer-4.1.47.Final.jar:4.1.47.Final] AbstractByteBuf.java:1133
at
io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
~[netty-transport-4.1.47.Final.jar:4.1.47.Final]
NioSocketChannel.java:350 at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
[netty-transport-4.1.47.Final.jar:4.1.47.Final]
AbstractNioByteChannel.java:148 at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
[netty-transport-4.1.47.Final.jar:4.1.47.Final] NioEventLoop.java:714 |

or in another run:

|[INFO ] 22:58:32.997 org.apache.plc4x.java.PlcDriverManager.() -
Instantiating new PLC Driver Manager with class loader
jdk.internal.loader.ClassLoaders$AppClassLoader@55054057 [INFO ]
22:58:33.000 org.apache.plc4x.java.PlcDriverManager.() -
Registering available drivers... [INFO ] 22:58:33.005
org.apache.plc4x.java.PlcDriverManager.() - Registering driver for
Protocol s7 (Siemens S7 (Basic)) [INFO ] 22:58:33.138
org.apache.plc4x.java.transport.tcp.TcpChannelFactory.configureBootstrap()
- Configuring Bootstrap with Configuration{local-rack=1, local-slot=1,
remote-rack=0, remot-slot=0, pduSize=1024, maxAmqCaller=8,
maxAmqCallee=8, controllerType='S7_1200'} [INFO ] 22:58:33.388
it.fox.Poller01.start() - Starting poller01 thread [INFO ] 22:58:33.389
it.fox.Poller02.start() - Starting poller02 thread [INFO ] 22:58:33.472
it.fox.Poller02.run() - poller02 = 12139 [WARN ] 22:58:33.473
io.netty.channel.DefaultChannelPipeline.onUnhandledInboundException() -
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.net.SocketException: Connection reset at
sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:345)
~[?:?] SocketChannelImpl.java:345 at
sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:376) ~[?:?]
SocketChannelImpl.java:376 at
io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
~[netty-buffer-4.1.47.Final.jar:4.1.47.Final] PooledByteBuf.java:253 at
io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
~[netty-buffer-4.1.47.Final.jar:4.1.47.Final] AbstractByteBuf.java:1133
at
io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
~[netty-transport-4.1.47.Final.jar:4.1.47.Final]
NioSocketChannel.java:350 at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
[netty-transport-4.1.47.Final.jar:4.1.47.Final]
AbstractNioByteChannel.java:148 at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
[netty-transport-4.1.47.Final.jar:4.1.47.Final] NioEventLoop.java:714 at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
[netty-transport-4.1.47.Final.jar:4.1.47.Final] NioEventLoop.java:650 at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
[netty-transport-4.1.47.Final.jar:4.1.47.Final] NioEventLoop.java:576 at
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
[netty-transport-4.1.47.Final.jar:4.1.47.Final] NioEventLoop.java:493 at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
[netty-common-4.1.47.Final.jar:4.1.47.Final]
SingleThreadEventExecutor.java:989 at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
[netty-common-4.1.47.Final.jar:4.1.47.Final] ThreadExecutorMap.java:74
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[netty-common-4.1.47.Final.jar:4.1.47.Final]
FastThreadLocalRunnable.java:30 at java.lang.Thread.run(Thread.java:830)
[?:?] |

Is there some sort of race condition?

Regards,
Stefano Bossi




signature.asc
Description: OpenPGP digital signature

Re: Connection died after disconnection

2020-07-22 Thread Stefano Bossi

Ok,

thanks for the fast reply, I will check the documentation and I will let
you know.

Regards,
S.


On 21/07/2020 19:21, Christofer Dutz wrote:
> Hi Stefano,
>
> First of all, welcome on our list... We'll do our best to help you.
>
> Have you tried using our connection pool? Cause this should handle the 
> connection state if the connection is disturbed. Also the scraper is a tool 
> for collecting data periodically. This in combination with the connection 
> pool should be what you are looking for.
>
> Please find the documentation to using both on our website.
>
> Hope that helps,
> Chris
> ____
> Von: Stefano Bossi 
> Gesendet: Dienstag, 21. Juli 2020 15:56
> An: Apache PLC4X 
> Betreff: Connection died after disconnection
>
>
> Dear forum,
>
> I am trying to develop a simple poller for my S7 PLC ST_1200.
> I need just a simple thread in java which read a value and report it, anyway 
> this must be robust to any problem on the network.
> I mean I would like to cope with these situation:
>
>   *   PLC not responding;
>   *   network issues;
>
> The software should normally read a value from the plc in 200 ms and if 
> something bad happen, wait for 5 second and retry to read in a normal way.
>
> I wrote some code but when I found a problem.
> This is my code:
>
> public void run() {
> ConfigurationDataProvider configurationDataProvider = 
> ConfigurationDataProvider.getInstance();
> try {
> PlcConnection plcConnection = new 
> Client().getClient(configurationDataProvider.getPlcConnectionString()).getPlcConnection();
> PlcReadRequest.Builder requestBuilder = 
> plcConnection.readRequestBuilder();
> requestBuilder.addItem("pollingVariable", 
> configurationDataProvider.getPlcPollingVariable());
> PlcReadRequest readRequest = requestBuilder.build();
> while (true){
> if (plcConnection.isConnected()){
> try {
> PlcReadResponse response = 
> readRequest.execute().get(CONNECTION_TIME_OUT, TimeUnit.MILLISECONDS);
> if (response != null ){
> logger.debug("Polling variable: {}", 
> response.getPlcValue("pollingVariable"));
> } else {
> logger.error("No response from PLC in reading 
> polling variable");
> break;
> }
> } catch (TimeoutException timeoutException){
> logger.error("Time out Exception in polling PLC", 
> timeoutException);
> Thread.sleep(5000);
> }
> 
> Thread.sleep(configurationDataProvider.getPollingInterval());
> }
> }
>
> } catch (Exception e) {
> logger.error("Interrupted Exception", e);
> }
> }
>
>
> When I try to disconnect the cable, netty comply with an internal error and 
> my application dies without a way to recover.
> Here are the logs:
>
> [ERROR] 15:33:38.830 it.fox.plcreader.Poller.run() - Time out Exception in 
> polling PLC
> java.util.concurrent.TimeoutException: null
> at java.util.concurrent.CompletableFuture.timedGet(Unknown Source) ~[?:?]
> at java.util.concurrent.CompletableFuture.get(Unknown Source) ~[?:?]
> at it.fox.plcreader.Poller.run(Poller.java:34) [main/:?]
> Poller.java:34
> at java.lang.Thread.run(Unknown Source) [?:?]
> [ERROR] 15:33:49.333 it.fox.plcreader.Poller.run() - Time out Exception in 
> polling PLC
> java.util.concurrent.TimeoutException: null
> at java.util.concurrent.CompletableFuture.timedGet(Unknown Source) ~[?:?]
> at java.util.concurrent.CompletableFuture.get(Unknown Source) ~[?:?]
> at it.fox.plcreader.Poller.run(Poller.java:34) [main/:?]
> Poller.java:34
> at java.lang.Thread.run(Unknown Source) [?:?]
> [WARN ] 15:33:54.308 
> io.netty.channel.DefaultChannelPipeline.onUnhandledInboundException() - 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: Operation timed out
> at sun.nio.ch.SocketDispatcher.read0(Native Method) ~[?:?]
> at sun.nio.ch.SocketDispatcher.read(Unknown Source) ~[?:?]
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source) ~[?:?]
> at sun.nio.ch.IOUtil.read(Unknown Source) ~[?:?]
> at sun.nio.ch.IOUtil.read(Unknown S

Connection died after disconnection

2020-07-21 Thread Stefano Bossi

Dear forum,

I am trying to develop a simple poller for my S7 PLC ST_1200.
I need just a simple thread in java which read a value and report it,
anyway this must be robust to any problem on the network.
I mean I would like to cope with these situation:

  * PLC not responding;
  * network issues;

The software should normally read a value from the plc in 200 ms and if
something bad happen, wait for 5 second and retry to read in a normal way.

I wrote some code but when I found a problem.
This is my code:

|public void run() { ConfigurationDataProvider configurationDataProvider
= ConfigurationDataProvider.getInstance(); try { PlcConnection
plcConnection = new
Client().getClient(configurationDataProvider.getPlcConnectionString()).getPlcConnection();
PlcReadRequest.Builder requestBuilder =
plcConnection.readRequestBuilder();
requestBuilder.addItem("pollingVariable",
configurationDataProvider.getPlcPollingVariable()); PlcReadRequest
readRequest = requestBuilder.build(); while (true){ if
(plcConnection.isConnected()){ try { PlcReadResponse response =
readRequest.execute().get(CONNECTION_TIME_OUT, TimeUnit.MILLISECONDS);
if (response != null ){ logger.debug("Polling variable: {}",
response.getPlcValue("pollingVariable")); } else { logger.error("No
response from PLC in reading polling variable"); break; } } catch
(TimeoutException timeoutException){ logger.error("Time out Exception in
polling PLC", timeoutException); Thread.sleep(5000); }
Thread.sleep(configurationDataProvider.getPollingInterval()); } } }
catch (Exception e) { logger.error("Interrupted Exception", e); } } |

When I try to disconnect the cable, netty comply with an internal error
and my application dies without a way to recover.
Here are the logs:

|[ERROR] 15:33:38.830 it.fox.plcreader.Poller.run() - Time out Exception
in polling PLC java.util.concurrent.TimeoutException: null at
java.util.concurrent.CompletableFuture.timedGet(Unknown Source) ~[?:?]
at java.util.concurrent.CompletableFuture.get(Unknown Source) ~[?:?] at
it.fox.plcreader.Poller.run(Poller.java:34) [main/:?] Poller.java:34 at
java.lang.Thread.run(Unknown Source) [?:?] [ERROR] 15:33:49.333
it.fox.plcreader.Poller.run() - Time out Exception in polling PLC
java.util.concurrent.TimeoutException: null at
java.util.concurrent.CompletableFuture.timedGet(Unknown Source) ~[?:?]
at java.util.concurrent.CompletableFuture.get(Unknown Source) ~[?:?] at
it.fox.plcreader.Poller.run(Poller.java:34) [main/:?] Poller.java:34 at
java.lang.Thread.run(Unknown Source) [?:?] [WARN ] 15:33:54.308
io.netty.channel.DefaultChannelPipeline.onUnhandledInboundException() -
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: Operation timed out at
sun.nio.ch.SocketDispatcher.read0(Native Method) ~[?:?] at
sun.nio.ch.SocketDispatcher.read(Unknown Source) ~[?:?] at
sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source) ~[?:?] at
sun.nio.ch.IOUtil.read(Unknown Source) ~[?:?] at
sun.nio.ch.IOUtil.read(Unknown Source) ~[?:?] at
sun.nio.ch.SocketChannelImpl.read(Unknown Source) ~[?:?] at
io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
~[netty-buffer-4.1.47.Final.jar:4.1.47.Final] PooledByteBuf.java:253 at
io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133)
~[netty-buffer-4.1.47.Final.jar:4.1.47.Final] AbstractByteBuf.java:1133
at
io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
~[netty-transport-4.1.47.Final.jar:4.1.47.Final]
NioSocketChannel.java:350 at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
[netty-transport-4.1.47.Final.jar:4.1.47.Final]
AbstractNioByteChannel.java:148 at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
[netty-transport-4.1.47.Final.jar:4.1.47.Final] NioEventLoop.java:714 at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
[netty-transport-4.1.47.Final.jar:4.1.47.Final] NioEventLoop.java:650 at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
[netty-transport-4.1.47.Final.jar:4.1.47.Final] NioEventLoop.java:576 at
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
[netty-transport-4.1.47.Final.jar:4.1.47.Final] NioEventLoop.java:493 at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
[netty-common-4.1.47.Final.jar:4.1.47.Final]
SingleThreadEventExecutor.java:989 at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
[netty-common-4.1.47.Final.jar:4.1.47.Final] ThreadExecutorMap.java:74
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[netty-common-4.1.47.Final.jar:4.1.47.Final]
FastThreadLocalRunnable.java:30 at java.lang.Thread.run(Unknown Source)
[?:?] |

Googling I found this Stack Overflow

Re: More Details regarding Scraper, Lack of Documentation

2020-07-07 Thread Stefano Bossi

Thanks Christofer,

for your help and time.

I will read the documentation and I will let you know.

Regards,
Stefano



Il lun 6 lug 2020, 11:47 Christofer Dutz  ha
scritto:

> Hi all,
>
> so I just wrote some documentation on the Scraper … it’s now available
> from here:
> https://plc4x.apache.org/users/tools/scraper.html
>
> I hope it helps and I hope even more that it’s accurate. If you happen to
> find some issues with it, please tell me about it.
>
> Chris
>
>
>
> Von: Stefano Bossi 
> Antworten an: 
> Datum: Freitag, 3. Juli 2020 um 17:56
> An: 
> Betreff: Re: More Details regarding Scraper, Lack of Documentation
>
> Thanks for your effort.
>
> I would be interest too in the documentation of the scraper; I will be
> stay tuned too.
>
> Regards,
> Stefano Bossi
>
> On 03/07/2020 14:34, Christofer Dutz wrote:
>
> Hi Wolfgang,
>
>
>
> As the exact same question has come up multiple times In the last few
> days, I'll start writing it.
>
>
>
> I was hoping the folks who wrote it would take care of this, but I
> understand there's a need for more documentation and we haven't been doing
> an extremely good job with that.
>
>
>
> So please stay tuned.
>
>
>
> Chris
>
>
>
> 
>
> Von: Wolfgang Huse  wolfgang.h...@nutanix.com>
>
> Gesendet: Freitag, 3. Juli 2020 09:30
>
> An: dev@plc4x.apache.org<mailto:dev@plc4x.apache.org> <
> dev@plc4x.apache.org><mailto:dev@plc4x.apache.org>
>
> Betreff: More Details regarding Scraper, Lack of Documentation
>
>
>
> Hello!
>
> I have read a lot of Scraper-Functionality, as example in the
> Logstash-Plugin but I don’t find any high level Documentation.
>
>
>
> How do I leverage scraper and what are the benefits compared to cyclic
> subscription of several values ?
>
>
>
> In my use-case I need to fetch 16 Values from a S7-300 every 1second. What
> Is the best approach to do this ?
>
>
>
> Mit freundlichen Grüßen – With kind regards
>
>
>
> Wolfgang Huse
>
>
>
>
>
>
>

Re: AW: Reading compress Data Block

2020-07-05 Thread Stefano Bossi

Dear Julian,

thanks for your kind reply, I will study the video you post me and I
will try to understand with the PLC expert if using "plain" block will
be an issue or not.

Thanks,
Stefano Bossi


On 04/07/2020 23:13, Julian Feinauer wrote:
> Dear Stefano,
>
> first, welcome to this list and thank you for your kind words!
>
> I, and many others here on the list would love to be able to read "optimized 
> Data Blocks" from Siemens.
> There are technical as well as legal reasons why we do not provide such a 
> driver as of now.
> I (and others as well) hope that we will be able to do it one day but so far 
> we cant.
>
> In our industrial applications we usually copy the block over to another 
> unoptimized Block which we use as "exchange block".
> Tim talks a little bit about that in the video we did together on PLC4X: 
> https://www.youtube.com/watch?v=MIp_0OcDTr4
> [https://i.ytimg.com/vi/MIp_0OcDTr4/maxresdefault.jpg]<https://www.youtube.com/watch?v=MIp_0OcDTr4>
> "Hands On": Reading Siemens S7 with 
> PLC4X<https://www.youtube.com/watch?v=MIp_0OcDTr4>
> In our first (technical) webinar Julian Feinauer and Tim Mitsch as members of 
> the Project Management Committee (PMC) of PLC4X will introduce the Apache 
> PLC4X...
> www.youtube.com
>
>
> If you have more questions we will try to help you with that or give you 
> enough advice what to tell the PLC programmer guy : )
>
> Best!
> Julian
>
>
> 
> Von: Stefano Bossi
> Gesendet: Samstag, 04. Juli 2020 15:31
> Bis: dev@plc4x.apache.org
> Betreff: Reading compress Data Block
>
> Dear plc4x developer,
>
> my name is Stefano and I am dealing with a project which is briefly reading 
> data from a Siemens 1200 or 1500 and use these data to make some statistics.
> I am writing a software in Java with your wonderful library but I didn't 
> written the PLC software (some automation expert guy wrote that)
> The PLC software has some DB I need to read but the PLC use "optimized Data 
> Block".
> Is there a way to read with PLC4X library an optimized Data Block ?
>
> Many thanks for your work!
>
> Regards,
> Stefano Bossi
>
>



signature.asc
Description: OpenPGP digital signature

Reading compress Data Block

2020-07-04 Thread Stefano Bossi

Dear plc4x developer,

my name is Stefano and I am dealing with a project which is briefly
reading data from a Siemens 1200 or 1500 and use these data to make some
statistics.
I am writing a software in Java with your wonderful library but I didn't
written the PLC software (some automation expert guy wrote that)
The PLC software has some DB I need to read but the PLC use "optimized
Data Block".
Is there a way to read with PLC4X library an optimized Data Block ?

Many thanks for your work!

Regards,
Stefano Bossi



signature.asc
Description: OpenPGP digital signature

Re: More Details regarding Scraper, Lack of Documentation

2020-07-03 Thread Stefano Bossi

Thanks for your effort.

I would be interest too in the documentation of the scraper; I will be
stay tuned too.

Regards,
Stefano Bossi


On 03/07/2020 14:34, Christofer Dutz wrote:
> Hi Wolfgang,
>
> As the exact same question has come up multiple times In the last few days, 
> I'll start writing it.
>
> I was hoping the folks who wrote it would take care of this, but I understand 
> there's a need for more documentation and we haven't been doing an extremely 
> good job with that.
>
> So please stay tuned.
>
> Chris
>
> 
> Von: Wolfgang Huse 
> Gesendet: Freitag, 3. Juli 2020 09:30
> An: dev@plc4x.apache.org 
> Betreff: More Details regarding Scraper, Lack of Documentation
>
> Hello!
> I have read a lot of Scraper-Functionality, as example in the Logstash-Plugin 
> but I don’t find any high level Documentation.
>
> How do I leverage scraper and what are the benefits compared to cyclic 
> subscription of several values ?
>
> In my use-case I need to fetch 16 Values from a S7-300 every 1second. What Is 
> the best approach to do this ?
>
> Mit freundlichen Grüßen – With kind regards
>
> Wolfgang Huse
>
>



signature.asc
Description: OpenPGP digital signature

48 matches

Mail list logo