Configuring PUT/GET Communication Between S7-300 and S7-400

S7 communication using PUT and GET instructions is the most common method for exchanging data between two SIMATIC controllers over Industrial Ethernet. This reference documents the complete configuration path for a mixed-tool setup: an S7-300 CPU programmed in TIA Portal V15 acting as the active partner (client), and an S7-400 CPU programmed in SIMATIC Manager (STEP 7 V5.x) acting as the passive partner (server). The procedures also apply to S7-1500 servers with the firmware and protection caveats noted in the relevant Siemens documentation.

The configuration described here is based on the official Siemens application example "S7 communication with PUT/GET between TIA Portal and SIMATIC Manager" (entry ID 92269951) and the S7-1500 communication manual available from the Siemens Industry Online Support file 82212115.

1. Overview of the S7 Communication Model

S7 communication is a Siemens proprietary protocol that runs on top of ISO-on-TCP (RFC 1006), ISO, TCP, or MPI/PROFIBUS depending on the configured connection type. For Industrial Ethernet between an S7-300 and an S7-400, the standard bearer is ISO-on-TCP (port 102).

The PUT/GET model is a unilateral (client-driven) data exchange. Only one CPU initiates reads and writes; the partner CPU simply makes its data blocks available as a server. The server does not require PUT/GET block code at all. The server CPU is configured once in the hardware/networking tool to allow access; the client CPU does the rest of the work through FB14 (GET) and FB15 (PUT) on S7-300, or SFB14/SFB15 on S7-400 if it is also acting as a client.

2. Prerequisites

Verify the following before you begin configuration:

1. CPU firmware – S7-300 CPUs with PROFINET interface (CPU 31x PN/DP) or with a CP 343-1 Lean/Standard/Advanced support S7 communication. Older CPU 31x-2 DP without Ethernet require a CP 343-1.
2. S7-400 CPU – All standard S7-400 CPUs (CPU 412, 414, 416, 417) with PN interface or CP 443-1 support S7 communication. Firmware V5.x or V6.x is sufficient; V7+ adds extra diagnostics.
3. TIA Portal V15 – S7-300 CPU support in TIA V15 requires the appropriate HSP (Hardware Support Package) if the CPU is older than a 31x PN/DP. Confirm the exact order number appears in the hardware catalog.
4. STEP 7 V5.5 SP4+ (or V5.6/V5.7) – required on the SIMATIC Manager side.
5. Ethernet connectivity – managed switches or a direct crossover cable; both CPUs must be reachable via ping from a Windows engineering station before any S7 blocks are placed.
6. IP addresses – assign a unique IPv4 address to each PROFINET interface or CP. Document the subnet mask and gateway (if any).

3. Hardware Configuration and Network Setup

Open the S7-300 project in TIA Portal V15 and the S7-400 project in SIMATIC Manager. The two projects remain independent – the S7 connection is created in each project separately and uses an unspecified partner.

3.1 Assigning IP addresses

For the S7-300 (TIA Portal):

1. Open Devices & Networks and select the PROFINET interface or CP 343-1.
2. In Properties > General > Ethernet addresses, assign the IP address, subnet mask, and (optionally) the router address.
3. Compile and download the hardware configuration. Perform a CPU restart (STOP → RUN) to activate the new IP stack.

For the S7-400 (SIMATIC Manager):

1. In HW Config, open the properties of the CPU or CP 443-1.
2. Set the IP address, subnet mask, and MAC address. Enable Use IP parameters directly from the configuration.
3. Save, compile, and download the station. Restart the CPU to apply.

Verify connectivity from a Windows command prompt on the engineering station:

ping 192.168.0.10   (S7-300)
ping 192.168.0.20   (S7-400)

Both pings must succeed before continuing. If either ping fails, do not proceed to S7 block configuration – you will waste time chasing status codes that originate from the IP layer.

4. S7 Connection Configuration in TIA Portal V15 (S7-300 Client)

The connection is created on the client side. The S7-300 in this scenario is the client; you do not need to create a matching connection inside the S7-400 project for the S7-400 to act as server. The S7-400 simply needs to be reachable on the network with its PUT/GET access enabled.

1. In TIA Portal, switch to Devices & Networks > Network view.
2. Click the Connections button at the top of the editor.
3. Select S7 connection.
4. Click the PROFINET interface of the S7-300 CPU – it is highlighted in color.
5. Drag a connection line to the S7-300 CPU itself (self-connection to a partner) and select Unspecified as the partner.
6. Open the connection properties and enter:
   • Partner IP address: the S7-400 IP, e.g. 192.168.0.20
   • Partner TSAP: leave at the default 03.01 (rack 0, slot 2) or set per the S7-400 configuration. For CP 443-1, the TSAP must match the configured connection endpoint on the CP.
   • Local TSAP: 03.01 by default for the CPU's integrated PROFINET interface.
   • Connection ID: note this value – it must be entered in the PUT/GET block parameter ID.
7. Compile and download the connection configuration. The S7-300 is now ready to make S7 calls to the S7-400.

5. S7 Connection Configuration in SIMATIC Manager (S7-400 Server)

For the S7-400 to act as a server, the partner connection must be created in NetPro of the SIMATIC Manager project. The CPU does not execute any PUT/GET blocks – it only holds the connection endpoint and the data block.

1. Open the S7-400 project and start NetPro (button in the toolbar or Options > NetPro).
2. Right-click the CPU row and select Insert New Connection.
3. Choose Unspecified as the partner and S7 connection as the type.
4. In the connection properties, enter the partner IP address (the S7-300's IP), set the connection name, and accept the default TSAP unless your CPU is in a different rack/slot.
5. Confirm with OK and download the connection to the S7-400 CPU.

The S7-400 is now passively listening on TSAP 03.01 (rack 0, slot 2) for S7 communication calls.

6. Programming PUT/GET on the S7-300 Client

6.1 Inserting the blocks

In TIA Portal V15 the FBs are in the Standard Library > Communication Blocks:

• FB14 — GET – reads data from the partner
• FB15 — PUT – writes data to the partner

Add both FBs to the S7-300 program (typically inside OB1 or a cyclic OB). Create a shared instance DB for each FB so the static parameters (ID, ADDR_1, RD_1/SD_1, etc.) are retained across scans.

6.2 Parameter mapping

Sample call from OB1 of the S7-300 (structured text style — equivalent LAD contact network is shown in the official Siemens application example 92269951):

// Instantiate once as a multi-instance or shared DB
CALL  FB15, DB15      // PUT
REQ    := M10.0       // rising edge from clock generator
ID     := W#16#0001   // connection ID from NetPro
DONE   := M20.0
ERROR  := M20.1
STATUS := MW22
ADDR_1 := P#DB200.DBX0.0 BYTE 20   // partner (S7-400) target DB200
SD_1   := P#DB100.DBX0.0 BYTE 20   // local source DB100
LEN    := 20

Use the same ID value that TIA Portal assigned when you created the S7 connection. If STATUS reports W#16#8090 or W#16#80B0 after a download, the ID almost always does not match what is downloaded in the connection configuration; recompile the project and re-download the connection.

7. Data Block Sizing and Memory Layout

A common failure mode observed in commissioning is STATUS = W#16#1 with ERROR = 1 immediately after the first download. The source thread documents this exact symptom: the issue resolved after the user resized the data blocks on the server side. The same symptom can be reproduced on a fresh project by deliberately mismatching LEN with the partner DB size.

Rules that must be observed:

1. The local DB referenced by SD_1 (PUT) or RD_1 (GET) must be at least LEN bytes long.
2. The partner DB referenced by ADDR_1 on the S7-400 must also be at least LEN bytes long.
3. The partner DB must be not write-protected when used as a PUT target, and must be loaded in work memory (not only in load memory).
4. For PUT, do not use a DB that has been generated with the Optimized block access attribute – the S7-400 side of the link is a non-optimized S7 communication, which requires the Standard (non-optimized) access attribute on the partner DB. TIA Portal V15 marks all new DBs as optimized by default; clear the checkbox in DB properties > Attributes on the S7-400 DB, then recompile and re-download.

8. REQ Trigger Logic and Edge Detection

The single most frequent cause of silent PUT/GET failure is a level-triggered REQ. The S7 PUT/GET blocks execute exactly once per rising edge of REQ. If REQ is wired to a constant TRUE or to a bit that stays high, the block still only fires once on the first scan, then the next job has no rising edge to start.

Use a periodic clock bit or HMI-triggered pulse. The standard Siemens pattern is:

// Clock generator: 0.5 s on, 0.5 s off
M_clock   :=  T1 (T1 := TRUE, PT := 500 ms)  // S7-300/400 timer
M_req_put :=  M_clock XOR M_clock_old  // rising edge detector

Wire M_req_put into the REQ input of the PUT block. Repeat for the GET block using a second clock with a different phase, e.g. M_req_get, to avoid the two blocks contending for the same connection resources.

For the S7-400 SFB14/15, the behavior is identical: REQ requires a rising edge.

9. Protection Settings and Access Permissions

The S7-400 CPU (and any S7-1500 in the loop) must explicitly permit remote PUT/GET access. In SIMATIC Manager, this is in the CPU properties:

1. Open HW Config and double-click the CPU.
2. Go to the Protection tab.
3. Select Operating mode: Process mode (with access authorization via the password) or no password (full access).
4. Check the box Permit access with PUT/GET communication from remote partner (PLC, HMI, OPC, …).
5. Save, compile, and download the hardware configuration to the CPU.

The same setting in TIA Portal V15 (for an S7-1500 server) is at:

CPU properties > Protection & Security > Connection mechanisms > Permit access with PUT/GET communication from remote partner — see the Siemens PDF application note (file 82212115) for screenshots.

10. Error Codes and STATUS Diagnostics

The ERROR and STATUS outputs of FB14/FB15 (and SFB14/SFB15) follow the standard S7 communication error model. STATUS is meaningful only when ERROR = 1; otherwise it carries transient job state codes (e.g. W#16#7000 idle, W#16#7001 first execution, W#16#7002 consecutive execution).

The thread reported "error and status = 1", which is the classic pattern of either a non-pulsed REQ (status = 0x0001 = first execution in progress) or, more often when the user reports it as a hard error, an ERROR = 1 with the bit-level STATUS = 0x0001 reflecting a partner-cannot-be-reached condition. Treat any persistent STATUS = 1 as a connection-establishment issue before assuming a programming bug.

11. Troubleshooting Matrix

Use this matrix as a commissioning checklist when PUT/GET fails.

12. Verification and Commissioning Procedure

After programming and downloading, walk through the following verification steps in order:

1. Layer 3 reachability: ping both CPUs from the engineering station. Both must respond.
2. Online connection status: In TIA Portal, go online with the S7-300 and open Online & Diagnostics > Communication > S7 connections. The connection should show Established. In SIMATIC Manager, use PLC > Monitor/Modify > Communication (or open NetPro and view the connection state).
3. Force a single job: Set the REQ trigger bit once and observe ERROR / STATUS in a VAT table.
4. Verify data movement: With the S7-300 in STOP and a known pattern in the local DB, force a PUT. Switch the S7-300 to RUN and confirm the partner DB on the S7-400 has changed. With a GET, read the partner DB and confirm the local DB updates.
5. Sustained operation: Enable the periodic trigger and monitor DONE and NDR for at least one full cycle. Verify that ERROR remains 0.
6. Diagnostic buffer: On both CPUs, review the diagnostic buffer for SF entries related to S7 communication. Clear and re-run to confirm clean state.

13. Performance and Timing Considerations

PUT/GET is suitable for cyclic, non-time-critical exchanges. Practical numbers from Siemens documentation and field measurements:

• One PUT/GET cycle: 20 ms to 80 ms on a 100 Mbit/s Industrial Ethernet link, depending on the LEN.
• Maximum payload per call: 160 bytes for FB14/FB15 (S7-300), 462 bytes for SFB14/15 (S7-400), 462 bytes for S7-1500 PUT/GET.
• Connection resources: each configured S7 connection consumes one connection resource on the client CPU. S7-300 has 4–16 connection resources; S7-400 has up to 64; S7-1500 has 64–128 depending on CPU.

For high-frequency, deterministic, or large-payload data, use ISO-on-TCP (T-block version: TCON, TSEND, TRCV) or, on S7-1500, OPC UA published data blocks.

14. Mixed-Tool Field Reference

This reference applies generally to any S7-300 (TIA) ↔ S7-400 (SIMATIC Manager) PUT/GET link. The following substitutions also work:

For the most current block behavior, error codes, and security notes, always cross-check the version of the TIA Portal help installed locally (Help > Show Help) against the official Siemens TIA Portal v20 documentation on PUT/GET instructions.