Configuring S7-1500 to S7-300 Communication via PUT/GET Blocks

1. Overview: Cross-Generation SIMATIC S7 Communication

Linking a SIMATIC S7-1500 controller (programmed in TIA Portal) with a SIMATIC S7-300 controller (programmed in STEP 7 Classic / SIMATIC Manager) is a routine retrofit and migration task. Because the two CPUs are engineered in different project environments, the link is configured as an unspecific S7 connection in which one CPU owns the connection and references the other as an "Unknown" partner. Data exchange is then performed with the S7 Communication service using PUT and GET blocks.

The reference topology in this article uses a CPU 1515-2 PN (article number 6ES7515-2AM02-0AB0) on the S7-1500 side and a CPU 315-2 DP (6ES7315-2AH14-0AB0) with a CP 343-1 (6GK7343-1EX30-0XE0) on the S7-300 side, communicating over PROFINET/Ethernet.

The configuration shown above can be completed in roughly twenty minutes per station when the IP plan and DB layout are agreed in advance. The full Siemens application example is documented in the official entry: S7 Communication between SIMATIC S7-1500 and SIMATIC S7-300.

2. Prerequisites

3. S7 Connection vs. TCP Connection - Which One to Use

For the use case described here, the S7-1500 ↔ S7-300 link must be implemented as an S7 connection, not a raw TCP connection. The reasons are operational, not merely conventional:

• S7 connection uses the SIMATIC S7 Communication protocol on top of ISO-on-TCP (RFC 1006, port 102). It is connection-oriented, password-protected, and supported natively by the PUT/GET blocks of every S7-300/400/1500 CPU.
• TCP connection (T-block family: TSEND/TRCV on S7-1500, FB186/FB187-style on S7-300) requires custom packaging of every payload. It is the right tool only when the partner is a non-Siemens device or when explicit message framing is required.
• The official Siemens catalog of communication instructions is described in Instructions for communication tasks (S7-300, S7-400, S7-1500).

PUT/GET is the lower-overhead option for cyclic DB-to-DB mirroring and does not require a configured connection on the partner side - it is sufficient to configure the S7 connection on the CPU that issues the request (the "active" partner) and declare the remote as unspecific on that one station.

4. TIA Portal Configuration on the S7-1500 Side

4.1 Create the S7 connection

1. Open the S7-1500 project in TIA Portal.
2. Select the CPU 1515-2 PN in the project tree, then open Properties → Communication → S7 connections.
3. Click Add new S7 connection. The partner type defaults to "Unspecific"; leave it on that value because the S7-300 is not part of this TIA project.
4. Set the Local ID (e.g. 1). This is the connection handle you will pass to the PUT/GET block.
5. Enter the partner IP address (192.168.0.20) and the partner's Rack/Slot for the S7-300 side. For a CPU 315-2 DP with CP 343-1, the S7 partner address is the CP's Ethernet interface: rack 0, slot 0 is conventional for the CP, or the configured slot from the S7-300 project's hardware configuration. The CP 343-1 is normally projected in slot 4 of the S7-300 rack when set as the default.
6. Enable Active connection establishment on the local (S7-1500) side if this CPU will own the connection, or leave it passive if the S7-300 will own it.
7. Compile the project and download the connection configuration to the CPU 1515-2 PN.

4.2 Connection ID handling

The Local ID configured above is the value that the S7-1500 PUT/GET instruction expects on its ID input. It must match the ID parameter the S7-300 will use on its PUT/GET block when it owns the connection. Adopt a project-wide convention: S7-1500 always uses odd local IDs (1, 3, 5…) and S7-300 always uses the mirrored even IDs (2, 4, 6…).

5. STEP 7 Classic Configuration on the S7-300 Side

5.1 Create the S7 connection in NetPro

1. Open the S7-300 project in SIMATIC Manager.
2. Launch NetPro from the project view.
3. Right-click the CP 343-1 in the S7-300 station and choose Insert New Connection.
4. In the connection partner dialog select "Unspecified" / "S7 Connection (unspecific)" from the partner dropdown. The partner's IP is then entered manually.
5. Choose S7 connection as the connection type, then enter the partner IP 192.168.0.10 and the S7-1500 rack/slot (rack 0, slot 1 for CPU 1515-2 PN).
6. Set the Local ID on this side (e.g. 2 if the TIA project uses 1).
7. Save, compile, and download NetPro to the CP 343-1.

5.2 Cross-check

When correctly configured, opening Monitor/Modify on the S7 connection in NetPro will show the connection in ESTABLISHED state after a few seconds of CPU run time, even before the PUT/GET blocks are loaded. If the status is PARTNER-ABORT or OWN-ABORT, jump to the troubleshooting matrix at the end of this article.

6. Enabling PUT/GET Access on the S7-1500 CPU

1. In TIA Portal select the CPU 1515-2 PN and open Properties → Protection & Security → Access level.
2. Scroll to the Connection mechanisms section.
3. Tick the checkbox "Permit access with PUT/GET communication from remote partner".
4. Confirm with OK, recompile, and download the hardware configuration to the S7-1500.

The S7-300 does not have an equivalent global access toggle - the connection in NetPro, combined with the S7 user program using PUT/GET, is sufficient. The CP 343-1 firmware V3.x and higher are required for S7 communication as a server.

7. Programming PUT/GET on the S7-300 Side (FB14 / FB15)

7.1 Block sources

Insert FB14 "GET" and FB15 "PUT" into the S7-300 program from the standard library path Communication Blocks → Blocks. A dedicated instance DB is created for each call (e.g. DB100 for the GET instance and DB101 for the PUT instance). The official Siemens FAQ for these blocks is the entry "Sample Program: S7 Communication with blocks FB14 (GET) and FB15 (PUT) of the CPU 317-2PN/DP".

7.2 GET interface (S7-300 reads from S7-1500)

// FB14 "GET" - read data from the S7-1500 partner
CALL  "GET" , "DB_GET_Inst"
  REQ    :=M0.0                // 1 = start read
  ID      :=W#16#2              // Local ID of the S7 connection (NetPro)
  NDR     :=M10.0               // 1 = new data received
  ERROR   :=M10.1               // 1 = error, see STATUS
  STATUS  :=MW12                // Detailed status word
  ADDR_1  :=P#DB200.DBX0.0 BYTE 100   // Source area in S7-1500 partner
  RD_1    :=P#DB50.DBX0.0 BYTE 100    // Destination in this S7-300 CPU

7.3 PUT interface (S7-300 writes into S7-1500)

// FB15 "PUT" - write data to the S7-1500 partner
CALL  "PUT" , "DB_PUT_Inst"
  REQ    :=M0.1                // 1 = start write
  ID      :=W#16#2              // Same Local ID
  DONE    :=M10.2               // 1 = write completed without error
  ERROR   :=M10.3               // 1 = error, see STATUS
  STATUS  :=MW14
  ADDR_1  :=P#DB201.DBX0.0 BYTE 50    // Destination area in S7-1500
  SD_1    :=P#DB60.DBX0.0 BYTE 50     // Source in this S7-300 CPU

7.4 Multi-area variants

FB14 and FB15 support up to four address pairs (ADDR_1..ADDR_4, RD_1..RD_4, SD_1..SD_4). For each pair the length must be a multiple of one byte and a maximum of 160 bytes; total payload per call is bounded by the partner's connection resources. If more than 160 bytes must be transferred, segment the transfer into multiple calls or use a single ANY pointer of up to 462 bytes - both block variants are valid; segmenting is more portable across firmware versions.

8. Programming PUT/GET on the S7-1500 Side

The S7-1500 provides the same service via the instructions GET and PUT from the Instructions → Communication → S7 Communication palette. Drop the instruction into a cyclically executed OB (typically OB1 or OB35).

8.1 GET instance on S7-1500 (reads from S7-300)

// S7-1500 GET - read 80 bytes from S7-300 DB20
%I0.0  "Trigger_GET"  // positive edge = start
"Inst_GET"(
  REQ    :=  "Trigger_GET",
  ID     :=  1,                       // Local ID from TIA connection
  NDR    =>  "GET_Done",
  ERROR  =>  "GET_Error",
  STATUS =>  "GET_Status",
  ADDR_1 :=  P#DB20.DBX0.0 BYTE 80,   // Area in the S7-300 partner
  RD_1   :=  P#DB120.DBX0.0 BYTE 80   // Destination in this CPU
);

8.2 PUT instance on S7-1500 (writes to S7-300)

// S7-1500 PUT - write 32 bytes to S7-300 DB21
%I0.1  "Trigger_PUT"
"Inst_PUT"(
  REQ    :=  "Trigger_PUT",
  ID     :=  1,
  DONE   =>  "PUT_Done",
  ERROR  =>  "PUT_Error",
  STATUS =>  "PUT_Status",
  ADDR_1 :=  P#DB21.DBX0.0 BYTE 32,   // Destination in S7-300
  SD_1   :=  P#DB130.DBX0.0 BYTE 32   // Source in S7-1500
);

8.3 Data limits on S7-1500 PUT/GET

9. Common STATUS Codes

10. Verification and Online Diagnostics

1. Open the S7-1500 online view in TIA Portal. Navigate to Online & Diagnostics → Communication → S7 connections. The new connection should display state ESTABLISHED with the partner IP shown.
2. On the S7-300 side open NetPro, select the CP 343-1, and use PLC → Monitor/Modify on the S7 connection. State should read ESTABLISHED as well.
3. Force the trigger tag on one side and observe the destination area on the other using a watch table. Update time is typically 50-150 ms for a 100-byte payload on PROFINET, depending on connection scan cycle and partner CPU load.
4. Use the S7-1500 web server (CPU properties → Web server → Activate) for a browser-based cross-check of the connection state and DB contents without installing TIA Portal on every service laptop.
5. For a structured status display, instantiate DIAG_INF (S7-300) or read the S7 connection's STATUS from the SZL partial list 0x0132 in OB82/OB100.

11. Troubleshooting Matrix

12. Field-Proven Best Practices

• Configure on one side only. Whether TIA or STEP 7 Classic owns the connection is a project decision - pick the side where the engineer is more likely to maintain the project and keep the partner "Unspecific" everywhere else.
• Match access levels. If the S7-1500 project uses password-protected access levels, store the password in the TIA project; otherwise the S7-300 PUT/GET will be denied even with the security flag enabled.
• Watch DB block consistency. Mark both source and destination DBs as non-optimized to avoid byte-alignment gaps in S7-300. Optimized DBs on the S7-1500 must be addressed using symbolic names, but the partner still receives raw byte data.
• Plan the connection count. Each S7-1500 and each CP 343-1 has a finite S7 connection pool. Reserve at least 4 free S7 connections for online, HMI, and one future expansion.
• Use a single trigger source. A Clock_Byte or a slow OB35 task is a more reliable trigger than every-cycle OB1, especially for larger payloads.
• Document the Local ID map. Mirror the Local ID in a project header comment so a future engineer can correlate the TIA connection ID with the STEP 7 NetPro ID.
• Validate endianness and length. Both CPUs are little-endian, but mixing INT and WORD views of the same bytes will produce misleading values; agree on a "byte layout table" before commissioning.

FAQ