Configuring GET/PUT Communication Between Siemens S7 CPUs

Engineer field notes for CPU-to-CPU data exchange across SIMATIC S7-300, S7-400, and S7-1200 controllers. This reference covers S7 connections, single-sided GET/PUT blocks, both-sided Send/Receive blocks, configuration-only Global Data (GD) over MPI, and PROFINET I-Device data exchange, including connection resource budgets, NetPro / TIA Portal configuration steps, and verification procedures. All examples reference official Siemens documentation: the SIMATIC Communication Function Manual, the S7-1200 manual collection, and the SiePortal topic pages Make communication between two S7-1200 and Connect two PC to S7-300 via MPI.

Overview of Siemens CPU-to-CPU Communication

CPU-to-CPU communication in SIMATIC is performed over a logical S7 connection. An S7 connection defines the endpoints (local and partner CPU), the transport medium (MPI, PROFIBUS, PROFINET/Industrial Ethernet), and the communication blocks that the CPUs use to read or write partner data. The connection must be configured in NetPro (STEP 7 V5.x) or in Devices & Networks (TIA Portal) and downloaded to both endpoints. Once the connection is established at runtime, the program blocks exchange data using the connection ID assigned at configuration time.

Siemens supports four primary methods for exchanging data between S7 CPUs:

1. GET / PUT – single-sided communication; only the initiating CPU is programmed.
2. Send / Receive (USEND / URCV, BSEND / BRCV) – both-sided communication with explicit partner programming.
3. Global Data (GD) – configuration-only broadcast of selected tags over MPI, with no program code required on participating CPUs.
4. PROFINET I-Device / PN/PN coupler – process-data exchange between two PROFINET devices with deterministic cycle times.

The method selected depends on the network topology, the data volume and direction, the project phase (legacy STEP 7 vs TIA Portal), and the connection resources available on each CPU.

S7 Connection Fundamentals

An S7 connection is the unit of transport between two SIMATIC stations. Each S7 connection is identified by a local connection ID (1 to 65,535) and a partner connection ID; the local ID is what block calls reference with the ID input. Resources on a CPU are finite and must be budgeted against HMI panels, programming devices, and other controllers that also need connections.

To plan a project, subtract the connections required for HMI panels, PG/PC, OPC servers, and any third-party S7 client from the total. A 12-connection CPU with three HMI panels and a PG leaves only eight connections for peer-to-peer CPU traffic.

Communication Methods Compared

GET / PUT Single-Sided Communication

GET / PUT is the simplest method for one CPU to read or write a partner CPU's memory. Only the initiating CPU executes the block; the partner requires no code. This makes GET / PUT the recommended first step for brownfield migration and is supported on every SIMATIC generation that exposes an S7 connection endpoint.

Block Selection per CPU Family

The blocks are asynchronous. They are placed in OB 1 (or a cyclic OB), given a positive-edge trigger on REQ, and write the result of the last call to DONE (PUT) or NDR (GET) along with ERROR and STATUS.

Block Parameters in Detail

The S7-300/400 SFB 14 (GET) and SFB 15 (PUT) expose the same input structure. A PUT call has the following signal interface:

• REQ – rising edge triggers the job.
• ID – the local connection ID from NetPro (e.g. W#16#0003 for the third active connection).
• ADDR_i – ANY pointer to the partner area to be written (e.g. P#DB101.DBX0.0 BYTE 20).
• SD_i – ANY pointer to the local source area (PUT only).
• DONE – one-shot pulse on successful completion.
• ERROR – TRUE if the call terminated with an error.
• STATUS – detailed error code (see diagnostic table below).

For GET, the partner data is written to the local area referenced by RD_i (4 max).

Implementation Pattern

A common pattern is to drive a 1 s clock pulse from the system clock byte (e.g. "CPU_1_Scratch".Clock_1Hz) into a flag edge-detection bit and feed that as REQ. Multiple GET / PUT calls can share the same ID as long as the partner permits it, but only one job can be in flight on a connection at a time. To overlap data streams, use multiple S7 connections (one ID per direction or per data group).

STL Skeleton for S7-300/400 PUT

// OB 1 - cyclic 100 ms
A     M     10.0          // 1 Hz clock from system byte
FP    M    100.0          // edge flag
=     "inst_PUT".REQ     // drive REQ

CALL  "PUT" , "inst_PUT"
REQ   := "inst_PUT".REQ
ID    := W#16#0003        // NetPro connection ID
ADDR_1:= P#DB101.DBX0.0 BYTE 20
SD_1  := P#DB100.DBX0.0 BYTE 20
DONE  := "inst_PUT".DONE
ERROR := "inst_PUT".ERROR
STATUS:= "inst_PUT".STATUS

SCL Skeleton for S7-1200 PUT

// SCL - Function Block "fb_PutToLine2"
IF "Clock_1Hz" THEN
  "iDB_Put".REQ := TRUE;
END_IF;

"iDB_Put"(REQ := "iDB_Put".REQ,
         ID  := 16#0003,
         ADDR_1 := P#"DB_Line2".Status,
         SD_1   := P#"DB_Line1".StatusOut,
         DONE   => "iDB_Put".DONE,
         ERROR  => "iDB_Put".ERROR,
         STATUS => "iDB_Put".STATUS);

IF "iDB_Put".DONE THEN
  "iDB_Put".REQ := FALSE;
END_IF;

GET / PUT Status Codes (S7-300/400 SFB 14/15)

When a GET / PUT call fails immediately, zero out the local receive DB (e.g. fill with 0 on a one-shot) so that stale data does not masquerade as live values after a connection break.

Send / Receive (BSEND / BRCV, USEND / URCV)

Send / Receive blocks are used when both CPUs must participate in the exchange — for example, a job handshake with positive acknowledgement. The S7-300/400 library exposes two pairs:

• USEND / URCV – uncoordinated, up to 440 bytes per call, no implicit acknowledgement from the receiver (data is delivered, but not necessarily read yet).
• BSEND / BRCV – coordinated, segmented transfer with an explicit DONE on the receiver side confirming consumption. Suitable for bulk data.

On the partner side, URCV / BRCV is called unconditionally; it is non-blocking and just stores the latest message. The block is typically placed in OB 1 of the receiver and the local data is then read by the application program.

S7-1200/1500 do not expose USEND/URCV in the system library. Use BSEND/BRCV (TSEND_C / TRCV_C in some scenarios) instead, or drop down to PUT/GET for simpler cases.

BSEND / BRCV Sequence

1. Sender sets REQ with ID, R_ID, LEN, SD_i populated.
2. BSEND segments the data and waits for the receiver to acknowledge each segment.
3. Receiver's BRCV consumes the segments; on full transfer DONE rises for one scan.
4. Application reads the receive DB; it must finish before the next job with the same R_ID arrives.

Global Data (GD) Communication on MPI

Global Data is a broadcast-style service that runs over the MPI subnet and is configured entirely in STEP 7 V5.x. There is no code to write: you select which tags each CPU contributes to a GD circle, and STEP 7 manages the sending and receiving at the configured scan rate. GD is limited to SIMATIC stations with an MPI or PROFIBUS interface and is rarely used on new PROFINET-only projects, but remains useful when retrofitting an existing line where the topology is fixed.

GD Configuration in Simatic Manager

1. Open the project and double-click Global Data in the MPI subnet object.
2. Drag the source tags from each CPU into the GD table; STEP 7 builds the senders and receivers automatically.
3. Set the scan rate for each GD circle (1 to 255 multiples of the CPU cycle). Slower cycles reduce bus load.
4. Compile and download the GD configuration to all participating CPUs.

GD does not require code in OB 1, but the receiving CPU must allocate the matching DBs or M areas before download. If a tag is not present in the partner, the GD circle fails at startup with a SF LED and a diagnostic buffer entry referencing the missing address.

PROFINET I-Device and PN/PN Coupler

PROFINET exposes two deterministic mechanisms for CPU-to-CPU exchange:

• I-Device – a PROFINET device that provides an upper-level interface to a PROFINET controller, so two S7 CPUs can exchange process data over Ethernet. No proprietary S7 connection is needed; the data is part of the IO image.
• PN/PN coupler – a hardware module that bridges two PROFINET subnets, translating IO data between them. Useful when the two CPUs are on physically separate networks.

Configuring an I-Device in TIA Portal

1. Select the CPU in the device tree and enable the I-Device mode in the PROFINET interface properties.
2. Add the slots to be exposed (inputs and outputs) to the transfer area.
3. Compile and download the I-Device project to the lower-level CPU.
4. Import the I-Device GSD file into the upper-level controller's project and add it as a PROFINET device.
5. Map the slots in the upper-level CPU's IO image; access them with the standard %IW / %QW syntax.

PROFINET I-Device transfers are deterministic and cyclic, so they are preferred for motion, interlock, and safety-related exchange. A typical update time is 1 to 4 ms; the configured value appears in the device properties of the upper controller.

NetPro and TIA Portal Configuration Walk-Through

STEP 7 V5.x / NetPro

1. Insert the two S7 stations and the network (MPI or PROFIBUS).
2. Open NetPro. Select the CPU on the first station and right-click the partner; choose Insert New Connection.
3. Pick S7 Connection and confirm the partner. The local connection ID is auto-assigned; record it for the block call.
4. Set Active connection establishment on the partner if GET / PUT are only run from one side.
5. Compile and download the hardware configuration to both CPUs.
6. Insert the GET / PUT / BSEND / BRCV blocks in OB 1 of the active CPU; enter the connection ID at the ID input.

TIA Portal / Devices & Networks

1. Add both S7-1200/1500 devices and connect their PROFINET interfaces to the same subnet.
2. On Device A, open the Connections editor and add a new S7 connection to Device B.
3. Accept the auto-assigned local connection ID. Set the partner as server if the partner is not actively initiating.
4. Compile both devices and download the hardware configuration to both CPUs.
5. Insert PUT / GET blocks in the program of Device A; enter the connection ID at the ID input.

Connection Resources and Capacity Planning

Before adding a fourth or fifth peer-to-peer exchange, review the connection budget of every CPU in the network. The CPU's technical data sheet states the maximum number of S7 connections; each open connection (PG, HMI, OPC UA server, peer CPU) consumes one slot. The relationship is:

Free connections = Max connections − (HMI panels) − (PG/PC) − (other S7 connections) − (OPC UA / Open User Communication endpoints)

When the budget is exhausted, the CPU rejects new connections with a diagnostic buffer entry "No resources for connection" and the new GET / PUT call returns STATUS W#16#8090. The fix is to either upgrade the CPU to a higher-spec variant, consolidate multiple HMI panels behind a router panel, or migrate to PROFINET I-Device and reduce the number of S7 connections used.

Watchdog and Timeout Recommendations

Each S7 connection has a keep-alive and a connection-monitoring timer. If the partner CPU does not respond within the configured time, the connection is torn down and the next GET / PUT returns STATUS W#16#80F0. Recommended values for a 1 Hz polling cycle:

• Keep-alive: 30 s (default; leave at default unless bus load is high).
• Connection monitoring: 100 s (default).
• Block watchdog: implement in the application by validating NDR / DONE against a time-stamp; if the data is older than 3 × the polling period, mark the value as "stale" in the HMI.

To avoid losing the first few polls after a CPU restart, the receiving side should clear its local copy of the data on an OB 100 / startup pass and only mark it as "valid" after the first successful NDR arrives.

Diagnostics and Verification

1. Online » Accessible Nodes – confirm both CPUs are visible from the PG and that the network interface is the expected one (MPI / PROFIBUS / PROFINET).
2. Online » Diagnostics » Connection – NetPro and TIA Portal both expose a connection table that shows the configured S7 connections, their state, and the last error.
3. Watch the block instance – open the instance DB of the GET / PUT block in online view; check STATUS on the rising edge of the next call.
4. Forcing a controlled fault – stop the partner CPU to confirm the call returns STATUS W#16#80A0 (negative acknowledgement) rather than hanging the application.
5. Data age tag – in the receiver, expose the timestamp of the last successful NDR as an HMI tag; a stale value indicates a silent communication break.

Troubleshooting Matrix

Selecting the Right Method for a New Project

For a greenfield PROFINET-only system, default to PROFINET I-Device between S7-1500 / S7-1200 controllers where determinism matters, and reserve PUT / GET for commissioning and non-critical diagnostics. For a brownfield S7-300 / S7-400 line with an existing MPI ring, GD is the lowest-cost option for low-rate broadcasting between stations. For point-to-point exchange with one side initiating, GET / PUT is the lowest-code path and is portable across generations. For event-driven or large-block transfer, BSEND / BRCV remains the most robust both-sided handshake.

Field-Commissioning Checklist

• Download the S7 connection (NetPro / TIA) to both endpoints.
• Verify the connection in the online diagnostics view: state should be "established".
• Place PUT / GET (or BSEND / BRCV) blocks in the right OB and assign a unique instance DB to each call.
• Drive REQ from a controlled edge detector to avoid flooding the connection.
• Wire a status watch on the HMI to expose ERROR, STATUS, and a data-age tag.
• Force a controlled fault: stop the partner, confirm STATUS W#16#80A0, restart, confirm NDR resumes.
• Document the connection IDs and partner roles in the project header block.

FAQ