[
https://issues.apache.org/jira/browse/PLC4X-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249292#comment-17249292
]
Stefano Bossi commented on PLC4X-132:
-------------------------------------
Hi,
I will be in the position to perform some long term stability test with a S7
1200.
Basically the test will be to read data from the PLC every x seconds and keep
the code to run forever.
The amount of data will be collected in a DataBase an in the PLC I have
inserted some counter and timestamp that will allow me to verify the data read.
The code will log in a file too to complete the analysis too.
I will perform the test with the develop version and pool2 library.
If you give me some days I will report the results here to help
[~julian.feinauer] to decide if this ticket could be closed or not.
Regards,
S.
> [S7] Communication to S7 PLC dies in some situations
> ----------------------------------------------------
>
> Key: PLC4X-132
> URL: https://issues.apache.org/jira/browse/PLC4X-132
> Project: Apache PLC4X
> Issue Type: Bug
> Components: Driver-S7
> Affects Versions: 0.4.0
> Reporter: Julian Feinauer
> Priority: Blocker
>
> The following is from the Mailing Thread [1]:
> In the last weeks we observed multiple times strange behavior when connecting
> to Siemens S7 devices.
> We have not yet been able to trace it down entirely but I have the assumption
> that it is an issue with the PooledPlcDriverManager.
> Whats the issue?
> When doing requests (either via OPM or the “regular” API) we come at a point
> where all subsequent requests simply fail (and in some cases we were no
> longer able to send requests to the PLC from other instances, so it looks
> like the internal server went down).
> Whats the setup?
> When I remember correctly, all situations where this occurred used the Pool
> as Basis.
> We had it both with OPM and the normal API but NOT with the Scraper.
> I remember that I spent like a hole day at the Hackathon in Mallorca to get
> all timeout things to work correctly, as the S7 does not like when you simply
> cancel your request futures.
> Currently there are two “suspects” from my side.
> First, the pool calls the “.connect()” method on a now Connection it
> establishes but by API convention you also have to do that in your code so it
> gets called multiple times, which could fuck up stuff.
> Second, connection can also time out (but its no future in our API) so in the
> Scraper I implemented it as Future with timeout (as I’m unsure how everything
> behaes if the pool starts to initialize a connection but then the “waitTime”
> times out and it abandons this).
> [1]
> https://lists.apache.org/thread.html/328a6780b34b4fd2e3298e9e70340293ebb397b1978a7b631030067e@%3Cdev.plc4x.apache.org%3E
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
