S7-1200 PUT/GET: Configuring DB Exchange Between Two CPUs

Overview

Two S7-1200 CPUs can exchange Data Block (DB) contents without any additional hardware by using the integrated S7 Communication protocol carried over Profinet. The mechanism is implemented by the PUT and GET instructions, which Siemens documents in the S7-1200 system manual and the CPU-to-CPU communication compendium. A single CPU initiates the exchange, the partner CPU acts as the server, and Profinet transport handles the framed payload.

Typical applications include:

• Distributed machine cells sharing hand-off state, recipe, or counter data.
• Coordinated traffic, conveyor, or process systems where a vehicle or part must cross a boundary controlled by a second PLC.
• Redundant supervisory structures where a master CPU mirrors status DBs from a satellite CPU.

The constraint that drives most of the engineering effort is the 160-byte per call ceiling on user data. Once a project exceeds that, the calls must be sequenced by the application program. Siemens publishes a dedicated FAQ that defines a multi-call sequencing pattern, referenced in the Verification section below.

Prerequisites

Network and IP Configuration

Each CPU occupies a Profinet interface X1 (port 1) with a single IP address. Assign fixed IP addresses; do not rely on DHCP for deterministic CPU-to-CPU traffic.

1. Open the project in TIA Portal and select the first CPU in Devices & Networks.
2. Open Device view → PROFINET interface → Ethernet addresses.
3. Set IP address = 192.168.0.10, Subnet mask = 255.255.255.0.
4. Repeat for the second CPU with IP address = 192.168.0.11 on the same subnet.
5. Connect X1 P1 of CPU 1 to X1 P1 of CPU 2 with a Profinet patch cable, or through a managed switch.

Once the CPUs are online, ping each one from the programming PG to confirm Layer 3 reachability before any PUT/GET configuration is added.

S7 Connection Configuration in TIA Portal

S7 Communication requires an explicit S7 connection object. The object is local to the initiating CPU and references the partner CPU by IP address.

1. In Devices & Networks, switch to the Connections tab at the top of the editor.
2. Click the connection type dropdown and select S7 connection.
3. Drag from the PROFINET port of CPU 1 to the PROFINET port of CPU 2. TIA Portal creates a connection object under CPU 1's Connections node.
4. Open the connection object and confirm:
   • Local ID = 1 (decimal). This ID is the value the user program must pass to PUT/GET.
   • Partner address = 192.168.0.11.
   • Active connection establishment = enabled on the local (initiating) CPU only.
5. Compile and download hardware configuration to both CPUs.

Data Block Design

Both CPUs must declare a DB that mirrors the data being exchanged. For PUT/GET, two important rules apply:

• Blocks must be non-optimized (i.e., "Standard" access) on firmware older than V4.2. Firmware V4.2+ allows optimized blocks when accessed by absolute address.
• The DB must be large enough to hold the largest single PUT/GET payload (160 bytes by default; up to 960 bytes for large PUT/GET variants on S7-1500; 160 bytes remains the limit for S7-1200).

For a traffic-light hand-off application, design a small shared structure such as:

// DB "Shared_Handoff" on CPU 1 and CPU 2 (mirrored)
TYPE "tHandoff"
  STRUCT
    VehicleID     : INT;       // 0..32767
    Direction     : INT;       // 0=N, 1=E, 2=S, 3=W
    ETA_ms        : DINT;      // millisecond timestamp
    ApproachLane  : BYTE;      // bitmask of lanes approaching
    GoRequest     : BOOL;      // request to enter partner's zone
    HandshakeAck  : BOOL;      // partner acknowledged
    Padding       : ARRAY[0..149] OF BYTE;  // pad to 160 bytes
  END_STRUCT;
END_TYPE

Total payload is 160 bytes, matching the single-call limit. For larger hand-off tables, define a ARRAY[0..N] OF "tHandoff" and partition reads/writes into 160-byte slices using offsets.

PUT and GET Instruction Basics

Both instructions live in the Instructions → Communication → S7 Communication task card. Their interface blocks differ slightly.

For PUT and GET, REQ must be held TRUE for exactly one cycle after the call returns BUSY = 1 (or ERROR = 1). The simplest pattern is to drive REQ with a clock bit and let BUSY/DONE gate subsequent calls.

Programming the User Program

The following SCL snippet shows a coordinated exchange: CPU 1 reads CPU 2's hand-off DB (GET) and writes its own hand-off DB to CPU 2 (PUT). Both calls are triggered by a 200 ms clock so the application is paced and predictable.

// FB "HandoffExchange" in CPU 1 - SCL
VAR
  Clock_200ms    : BOOL;       // from TON / clock generator
  PutBusy        : BOOL;
  PutDone        : BOOL;
  PutError       : BOOL;
  PutStatus      : WORD;
  GetBusy        : BOOL;
  GetDone        : BOOL;
  GetError       : BOOL;
  GetStatus      : WORD;
  LocalBuf       : "tHandoff"; // local DB area
  RemoteBuf      : "tHandoff"; // partner DB area
END_VAR

// GET: read partner's hand-off DB into local buffer
"GET_DB".REQ  := Clock_200ms AND NOT GetBusy AND NOT GetError;
"GET_DB".ID   := W#16#1;                                  // local S7 connection ID
"GET_DB".ADDR_1 := P#DB20.DBX0.0 BYTE 160;                // partner's shared DB
"GET_DB".RD_1   := "Shared_Handoff".RemoteBuf;            // local destination
"GET_DB".NDR    ;  // rising edge on success
"GET_DB".ERROR  := GetError;
"GET_DB".STATUS := GetStatus;

// PUT: write local buffer to partner's hand-off DB
"PUT_DB".REQ   := Clock_200ms AND NOT PutBusy AND NOT PutError;
"PUT_DB".ID    := W#16#1;
"PUT_DB".ADDR_1 := P#DB20.DBX0.0 BYTE 160;                // partner's shared DB
"PUT_DB".SD_1   := "Shared_Handoff".LocalBuf;             // local source
"PUT_DB".LEN_1  := 160;
"PUT_DB".DONE   ;  // rising edge on success
"PUT_DB".ERROR  := PutError;
"PUT_DB".STATUS := PutStatus;

The same FB is dropped into CPU 2 with the local and remote roles swapped. From CPU 2's perspective, its own Shared_Handoff is the local buffer and CPU 1's is the remote buffer. The ID is the local connection ID on CPU 2's S7 connection object, which can also be W#16#1 independently.

Sequencing for More Than 160 Bytes

When a DB is larger than 160 bytes, the application must issue multiple GET or PUT calls with advancing offsets and wait for each to complete before triggering the next. Siemens documents the standard pattern in FAQ 65975617 ("How do you program the GET and PUT instructions ... in order to transfer more than 160 bytes").

1. Define a constant SLC_COUNT := CEIL(TotalBytes / 160.0).
2. Maintain an integer SliceIndex from 0 to SLC_COUNT - 1.
3. For each slice, compute Offset := SliceIndex * 160 and Len := MIN(160, TotalBytes - Offset).
4. Build the ADDR_1 pointer dynamically: P#DB20.DBX{Offset} BYTE {Len}.
5. Trigger PUT/GET only when the previous slice returned DONE (or NDR for GET) and increment SliceIndex.
6. After the final slice, reset SliceIndex := 0 to keep the transfer cyclic.

The full pattern with state machine and cycle timing is described in the linked Siemens FAQ. Engineers should add a watch-dog timer: if no slice completes within 5 seconds, raise a "PUT/GET comms fault" alarm and stop the application from acting on stale data.

HMI Integration for the Traffic Application

Each HMI in the original project is bound to a single CPU, which is the standard pattern for distributed visualization. The HMIs do not need to know the S7 Communication link exists; they simply read their own CPU's Shared_Handoff DB. The inter-CPU exchange happens invisibly in the background.

• Bind HMI 1 to CPU 1 only, displaying vehicles whose VehicleID is in CPU 1's domain.
• Bind HMI 2 to CPU 2 only.
• When a vehicle reaches the boundary lane, the controlling CPU sets GoRequest = TRUE in the shared DB. The partner CPU reads the request via GET, takes ownership, sets HandshakeAck = TRUE, and updates its own HMI with the new vehicle's position.

Verification

1. Online diagnostics: In TIA Portal, go to Online & Diagnostics → Connection diagnostics on the initiating CPU. The S7 connection must show status Established.
2. Status bit monitoring: Add a watch table to the initiating CPU and observe PUT_DB.DONE, GET_DB.NDR, and the STATUS words. A healthy exchange shows alternating rising edges on DONE and NDR.
3. Payload check: Set a known value (e.g., VehicleID := 12345) in the local DB on CPU 1. After one clock cycle, CPU 2's RemoteBuf.VehicleID should read 12345.
4. Cycle time impact: Check the OB1 scan time before and after enabling PUT/GET. A 160-byte PUT/GET pair over Profinet typically adds 5-15 ms per call depending on CPU utilization.
5. Error capture: Latch any non-zero STATUS value into a diagnostics DB and surface it on the HMI alarm log.

Troubleshooting Matrix

Common Status Codes

Performance and Timing

PUT/GET on S7-1200 is not deterministic in the sense of Profinet IRT; it uses standard S7 Communication on TCP/UDP over Profinet. Typical observed round-trip times for a 160-byte exchange between two S7-1214C CPUs on a direct cable:

For a traffic-light application with 200 ms cycle time, a single 160-byte PUT/GET pair leaves plenty of margin. For larger structures, plan the slice budget so the full exchange completes in under half the application cycle.

Field-Proven Caveats

• Always call PUT and GET from separate FB instances, even if they target the same connection. Sharing a single instance corrupts the internal state machine.
• Do not call PUT/GET from OB1 directly. Wrap them in an FB called from a cyclic OB30 or a clocked OB35 so a long-running exchange cannot stall the main scan.
• When changing the partner's IP, the S7 connection on the initiating CPU must be re-downloaded. The active partner IP is stored in the connection object, not resolved at runtime.
• PUT/GET over Profinet is not secure; the payload is not encrypted. If the network is shared with untrusted devices, segment the CPUs behind a managed switch or use a Profinet security module.
• For firmware V4.0 to V4.1, the partner DB must be non-optimized and the pointer must be in the form P#DBxx.DBX0.0 BYTE n. Symbolic access was not supported in this range.

FAQ