Hi Chris and hi Sebastian,
thank both of you for the happy welcoming.
@Chris
Thank you for your hints, I went a bit into the code but the thing I'm
currently missing (is there a central documentation) is how one can request a
larger portion of memory (possible even multiple PDUs).
As my understanding of the API is that I can only request single Values?
Where is the best place to get a good insight into the API (docu or code)?
Thanks!
Julian
PS.: I'm also mathematician but went more for statistics and number theory
(beautiful but mostly unusable) but we have done some stochastic optimization
(which is especially strong for high dimensional problems) so I can
definitively try to assist in solving the problem
Am 26.07.18, 14:51 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi Julian,
welcome to our list ( ... reading your post definitely made my day (Even if
I thought it couldn't get better)
Regarding your first Idea ... this is definitely on my mind and was taken
into consideration when implementing the S7 driver.
Right now the S7MessageProcessor interface provides an extension point for
things like this. Currently there is only one implementation. The
DefaultS7MessageProcessor is used to automatically split up large reads and
writes into multiple requests depending on the negotiated max PDU size. This
would be the place to re-write the S7Message requests to do what you are
planning on doing. I was planning on getting a friend of mine on board to
address this sort of thing (She's a mathematician, specialized on packing and
optimization problems), but if you are interested and want to work on this, I
would be glad to help you with this. I think the only thing currently not
supported, is to read information which would exceed the PDU size if sent in a
single PDU.
Regarding batch reads and writes ... I think such a thing would be a great
extension. However we would need to be able to configure this sort of thing. As
this could be something that might confuse people, manually turning batch
reads/writes on and configuring this in the connection string would be a good
way to go. The way PLC4X is built up, it shouldn't be a problem to implement
something like this. The Plc4XS7Protocol class could simply queue all
read/write items and have a separate worker drain that queue. This could be
similar to the queuing implemented in the S7Protocol class, just the trigger
would be a different one (Eventually the driver could send some sort of Batch
operation heartbeat event). Here too I would be more than happy to help
implementing this.
Chris
Am 26.07.18, 13:59 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>:
Hey everybody,
first, a great compliment for starting this excellent project and
bringing it this far forward.
I am on the dev mailing list since some months and was following the
development very interested but was not able to give any input due to other
duties.
We are a small german start-up doing (at least some of) the IoT and
Industry 4.0 stuff everybody is talking about. Currently, we have our own
home-build implementation of the S7 protocol as we do a lot of communication
with Siemens PLCs.
We also had some discussions and ideas of a more general interface as
we start to incorporate other devices and protokolls in our stack. And from my
perspective PLC4J is the “ideal” approach and fits nearly perfect with our
ideas and thus, we are currently thinking about replacing our own code with
PLC4J and in turn, try to bring this project forward in the directions we aim
to go.
Thus, from my side a warm welcome to the community and all contributors
and I’m really looking forward for the discussions with you!
And let me start with a first idea of a feature, I think we would need.
For a short background, we are doing a lot of interaction with PLCs and
usually read a lot of data (many variables) from the PLC with high frequencies.
Thus, our approach is not to read single addresses and cast them in one
step but to read one connected memory region (datablock) and extract all
variables of interest from the block and cast them to the respective types.
The main reason for this is to reduce the communication load on the PLC
side.
I hope that I’m not duplicating existing ideas or concepts but I didn’t
find anything specific to this problem.
To be able to switch to PLC4J my idea was to have a concept of “Batch”
Reads or Writes, kind of like the JDBCs batch mode.
This could have two variants. One would be the possibility to give the
driver a list of variables to read and the driver batches them as it makes
sense and then performs the read opaque and returns all the result.
The other option, especially in the async case could be that the reader
internally batches subsequent calls until certain thresholds (number of
commands, time limit) are met and then performs batched reads of consecutive
memory regions.
What do you think of this approach?
Best!
Julian
pragmatic industries
