S7 connections used to exchange information between devices of the S7-300, 400, 1200, 1500 series are configurable. This means that you must explicitly tell the devices who is communicating with whom. In general, these connections are bidirectional (two-way or bilaterally), i.e. adding a configurable connection occurs for both PLCs, which results in the need to download both PLCs. This does not cause any particular problems if both PLCs are in the department of the process control system of the enterprise, and for both PLCs there is an actual application software on hand. But there are also special cases - it is necessary to establish an exchange between the "old" S7-300 and the "new" S7-1500, moreover, the source code of the old program has been lost. Well, or the operation is simply afraid to touch the PLC. Or there is simply no operation, the task of organizing the exchange "hangs" on the integrator of the "new" system,which leads to the previous condition - nobody really wants to touch the software of an unknown system.
In such cases, the existing ability to configure a unilaterally connection, make it active (that is, “our” PLC will initiate the connection), add PUG / GET communication program blocks (this method does not work with other blocks, all other blocks are two-way ) and download only one PLC. We will assume that we have somehow preserved the information on the contents of the data blocks - either from the documentation for the system, or from the description of tags of the SCADA system.
Briefly about one- and two-way connections is written in the knowledge base at the link .
Herr Berger writes a lot of interesting things on the topic:
Hans Berger "Automating with SIMATIC S7-1500", p. 761
: S7- CPU, «» (active side), PUT/GET « », connection resource 03. , 03 , S7-.
«» ET200S CPU, S7-300 din-. ip- , .
ip-: 192.168.43.4
: DB1.DBD0, DB1.DBD4, DB1.DBD8
«» S7-1516, .
, . DB13. , PUT/GET «» .
Devices & networks.
Connections S7 connection
CPU Add new connection
S7-1516 , , . X1. Local ID (0x100) — , GET.
Add, Connections
ip-
Address details rack/slot , Connection resource 03. Rack — «», slot — «», «» CPU Simatic. ( «» ) 0/2.
OB1 GET .
GET , Properties ( ), . .
Req — , .
ID — , 0x100
ADDR_1 — , ANY
RD_1 — , , ANY. , .
DB1.DBD0.
ADDR_1. — ANY, Simatic. P#DB1.DBX0.0 BYTE 4
DB1 — 1
DBX0.0 — 0 ( 0 )
BYTE 4 — 4
P#DB1.DBX0.0 BYTE 4 DB1.DBD0. , , TIA Portal .
R0 "xEchangeDB".R0 ( ANY , P#DB13.DBX0.0 BYTE 4).
( Tag_1) , . , REQ , / .
Tag_1 :
, , 666. CPU S7-300 , . , 4 . , R1 R2 — .
3 ANY :
:
. , GET: NDR — , ERROR — STATUS — , . , «» , , . .
ANY, . GET ( ), PUT ( ). , PUT STATUS. .
GET . () PUT. , . R0 DB13. PUT .
Then we will write data by setting the value of the Tag_7 variable equal to "1". Well, now, to be honest, let's look at the value of this variable in the "black box".
Data writing was successful. Thus, even without having the original controller program on hand, we can both read information from it and write it. The amount of data is limited and depends on the type of CPU. EMNIP, for the "three hundredth series" the package is limited to 160 bytes, you can find out more in the documentation. The absence of the need to make changes to the application software is valid only for the 300th and 400th series, for thousands of units it is required to allow access to the CPU using the PUT / GET method by checking the corresponding box in the system settings.