This is an automated email from the ASF dual-hosted git repository.
cdutz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-plc4x.git
The following commit(s) were added to refs/heads/master by this push:
new 0c19a73 - Added some more information on PDU sizes and Splitting of
large requests in the S7 protocol
0c19a73 is described below
commit 0c19a73cb40c58165771d57f335b7e42f2bd1f71
Author: Christofer Dutz <[email protected]>
AuthorDate: Tue Mar 13 13:47:58 2018 +0100
- Added some more information on PDU sizes and Splitting of large requests
in the S7 protocol
---
src/site/asciidoc/protocols/s7/s7comm.adoc | 31 ++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/src/site/asciidoc/protocols/s7/s7comm.adoc
b/src/site/asciidoc/protocols/s7/s7comm.adoc
index bb011f2..7b7bcde 100644
--- a/src/site/asciidoc/protocols/s7/s7comm.adoc
+++ b/src/site/asciidoc/protocols/s7/s7comm.adoc
@@ -88,6 +88,37 @@ The values might be lower than in the request, but never
higher.
TIP: One thing about `Setup Communication Responses` which is kind of strange,
is that usually S7 response messages have additional `error class` and `error
code` fields, which this type of response doesn't seem to have.
+=== Sizes of requests
+
+During the connection to a S7 PLC the client and PLC agree on 3 important
parameters:
+
+- PDU Size
+- Max AMQ Caller
+- Max AMQ Callee
+
+The PDU Size is the size of a data packet the PLC is willing to accept.
+Here note, that in reality there are two PDU sizes involved: On `ISO TP/COTP`
protocol level and a second time on the `S7` protocol level.
+Most implementations treat them as somewhat equal, but this doesn't have to be
the case.
+A PLC could accept a higher PDU size on `ISO TP` level than on `S7` level.
+
+The `Max AMQ` parameters define how many unacknowledged requests a PLC
(Callee) is able to accept from a client (Caller).
+
+If the `ISO TP` PDU size is bigger than the `S7` one, then theoretically
multiple `S7` PDUs can be contained in one `ISO TP` packet.
+But at max `Max AMQ` packets.
+Most drivers don't utilize this option however.
+
+When issuing a read request there are other things that have to be taken into
consideration:
+
+The data retrieved by a read request has to fit into a PDU.
+So if a block of data requested in a read request, that would read a big block
of data that would exceed the agreed upon PDU size, the PLC will respond with
an `Access Violation` and not return any data.
+
+Another example would be if you read different memory blocks, each smaller
than the max PDU size, the read PDU could be quite small, but if these blocks
are quite large, the read response could exceed the max PDU size.
+In this case the item responses that exceed the size will simply be responded
with an `Access violation` by the PLC.
+
+When communicating with a `S7 1200` for example the `ISO TP` PDU size is set
to 256 bytes, then the maximum size of the `S7` is , this limits the maximum
amount of separate blocks accessible in the read request to 18.
+The typical `Max AMQ` of `8` further complicates things as we can't simply
split up the one message into multiple ones.
+If the number of messages exceeds this number, we have to queue these PDUs and
wait till the PLC confirmed these and can then continue sending further
fragments.
+
=== Links
Providing some additional information without directly being used:
--
To stop receiving notification emails like this one, please contact
[email protected].
