S7-1200 PLC-to-PLC Communication Configuring PUT/GET on TIA

Overview

Establishing direct S7 communication between two SIMATIC S7-1200 controllers (for example, an S7-1214C DC/DC/DC and an S7-1212C DC/DC/DC) is one of the most common commissioning tasks in the S7-1200 family. The data-exchange mechanism uses the standardized PUT and GET instructions, which are mapped onto an S7 single connection over the integrated PROFINET interface of each CPU.

The most frequent symptom reported by field engineers (and the original symptom described in the source) is a status output of ERROR = 0 and BUSY = 1 with no data actually transferred. This pattern almost always indicates that the local SFB/SFC has not yet received a response from the partner, and the root cause is normally found in one of three layers:

1. The PROFINET connection configuration inside TIA Portal (IP, subnet, TSAP, access point).
2. The protection/access level of the remote CPU blocking PUT/GET from a partner.
3. CPU firmware version, where the original V1.0 S7-1200 firmware (shipped 2009) has known PROFINET communication limitations corrected in V2.x, V3.x, and V4.x updates.

This guide covers the complete PUT/GET implementation, the required TIA Portal configuration, the firmware caveats that historically cause exactly the 0/1 status pattern, and the verification steps for a working data exchange.

Prerequisites

Before configuring the S7 connection, confirm that the following hardware and software is available. Substituting any of these without verification is the most common cause of a silent failure with BUSY = 1.

Firmware Considerations and the V1.0 Symptom

• PUT/GET with more than 160 bytes of payload was not always stable across PROFINET.
• Connection resource counts were lower (max 8 S7 connections, vs. 16 in V4.x).
• Watchdog timing for the PUT/GET status machine was longer; BUSY = 1 can persist for several seconds before DONE or ERROR latches.
• The "Permit access with PUT/GET from remote partner" option was not yet exposed in the same UI location.

Siemens released subsequent firmware updates specifically addressing PROFINET communication issues. The recommended path is to update both CPUs to at least V4.2, ideally the latest V4.4 or V4.5 currently listed in the Siemens Online Support delivery release. The CPU retains the user program and IP configuration through firmware updates performed from TIA Portal, but a power cycle is required after the update.

To read the current firmware of each CPU in TIA Portal:

1. Go online with the CPU (Online → Go online).
2. Right-click the device in the project tree and select "Online & diagnostics".
3. Under "Diagnostics", expand "General" and view the "Firmware version" field.

Network and IP Configuration

Two S7-1200 CPUs communicating directly over PROFINET must share a single IP subnet. The default addresses shipped from the factory (169.254.x.x) can be used for a first test, but production installations should use fixed addresses from a planned range.

Configure the IP on each CPU from the device view:

1. Select the CPU in the project tree.
2. Open "Properties → PROFINET interface [X1] → Ethernet addresses".
3. Uncheck "Set IP address using a different method" and enter:
   • IP address: 192.168.0.1 (CPU 1214C) / 192.168.0.2 (CPU 1212C)
   • Subnet mask: 255.255.255.0
   • Router: leave blank (no router required for direct link)
4. Confirm that both CPUs are placed in the same PROFINET subnet in the network view. A red bar between the devices means the subnet is not assigned; double-click the green PROFINET line to verify.

Physical verification before configuring the TIA connection:

If the ping fails, the PROFINET link LED on the CPU X1 port is the first diagnostic. A solid green LED on each port indicates the physical link is up.

Creating the S7 Connection in TIA Portal

The PUT and GET instructions operate over an S7 connection. The connection is configured from the network view and tied to a connection ID used by the program.

1. Open the "Network view" in TIA Portal.
2. Click the "Connections" icon at the top of the toolbar to enter connection mode.
3. Click the local CPU (S7-1214C), drag the connection line to the partner CPU (S7-1212C).
4. TIA Portal prompts to choose the connection type. Select S7 connection.
5. Open the new connection in the inspector window under "Properties → General".

The connection properties that must be set are:

Enabling PUT/GET on the Partner CPU

This is the single most common cause of the symptom ERROR = 0, BUSY = 1 with no data transfer. The remote CPU must explicitly allow PUT/GET access from a partner.

1. Select the partner CPU (S7-1212C) in the project tree.
2. Open "Properties → General → Protection & Security".
3. Find the option "Permit access with PUT/GET from remote partner (PLC, HMI, OPC, ...)".
4. Check the option.
5. Download the configuration to the partner CPU.

On firmware V4.x, the same option is reached via the same path. On V1.0 firmware, the option is in a different location: "Properties → Communication" and is labeled "Allow PUT/GET access". If this option is left disabled, the partner CPU rejects PUT/GET jobs at the connection layer, the local PUT/GET stays in BUSY = 1 indefinitely, and the error output eventually latches with status word W#16#8183 (partnership not established) or W#16#80C4 (connection aborted) depending on the timeout configuration.

Programming the PUT and GET Blocks

PUT and GET are found in TIA Portal under "Instructions → Communication → S7 Communication". They are interchangeable between V1.0 and V4.x firmware, but the FB block number is different:

Example call in a program block (OB1) on the local CPU (S7-1214C). All parameters must be assigned an input; unassigned inputs are treated as zero and cause silent failures.

// PUT: write 10 bytes from local MB100 to partner DB1 starting at byte 0
"iPUT_DB"(REQ   := "startPut",          // BOOL, edge-triggered
          ID    := 100,                  // INT, matches the connection ID
          DONE  => "putDone",            // BOOL, pulse on success
          ERROR => "putError",           // BOOL, sticky on error
          STATUS=> "putStatus",          // WORD, 0 = no error, 8 = error
          ADDR_1:= P#DB1.DBX0.0 BYTE 10, // POINTER, remote area
          ADDR_2:= P#M100.0 BYTE 10,     // POINTER, local area
          SD_1  := "sendBuffer");        // VARIANT, local source data

For the GET, mirror the parameters:

// GET: read 10 bytes from partner DB2 byte 0 into local MB200
"iGET_DB"(REQ   := "startGet",
          ID    := 100,
          DONE  => "getDone",
          ERROR => "getError",
          STATUS=> "getStatus",
          ADDR_1:= P#M200.0 BYTE 10,     // local destination
          ADDR_2:= P#DB2.DBX0.0 BYTE 10, // remote source
          RD_1  := "recvBuffer");

Key constraints for valid pointer operands:

• The byte offset on the partner must be aligned to the data type boundary; for BYTE arrays the alignment is free, but for WORD and DWORD the offset must be even / divisible by 4 respectively.
• The total payload size must be ≤ 160 bytes for a single PUT/GET call on V1.0 firmware. V4.x supports up to 400 bytes for PUT and 400 bytes for GET.
• The remote area (ADDR_1 in PUT, ADDR_2 in GET) must exist on the partner CPU. If the partner does not have DB1, PUT returns W#16#80A1 (DB does not exist).

Status Word Decoding

The STATUS output of PUT/GET is a WORD containing either an internal communication status (when ERROR = 0) or an error code (when ERROR = 1). The most common values seen during commissioning are:

Cross-Reference: S7-1200 to S7-1500 PUT/GET

The same mechanism extends to S7-1200 to S7-1500 communication. The S7 connection is created in the active partner's configuration (the one that issues the PUT/GET). The procedure is documented in the official Siemens application document:

• Reference: S7 communication between SIMATIC S7-1200 and SIMATIC S7-1500 (PDF, Siemens ID 82212115)
• Manual: SIMATIC S7-1200 Manual Collection — PLC-to-PLC communication (TIA Portal cloud docs)

Key differences when the partner is an S7-1500 instead of a second S7-1200:

Verification

After downloading to both CPUs, perform the verification in this order. Any failure step identifies the layer at fault.

1. Online status: both CPUs should show "Connected" with a green dot in the TIA project tree.
2. Watch table on the local CPU: monitor the PUT/GET DONE, ERROR, and STATUS tags. DONE should pulse for one cycle on each REQ edge, ERROR should remain 0, and STATUS should read W#16#0003 on success.
3. Data verification: write a known constant to the local source area (e.g. MB100 := 16#AA55AA55), trigger a PUT, then read the partner DB on a watch table opened against the remote CPU. Bytes should match exactly.
4. Cyclical test: leave the PUT/GET in a slow cycler (e.g. trigger from a 1 s clock) and verify the data is updated cyclically. If BUSY never clears, return to the status-word table.
5. Connection diagnostics: in the online diagnostics of the local CPU, "Diagnostics → Communication → Connection information" shows the S7 connection state and statistics (sent/received packets, errors). Connection state should be ESTABLISHED.

Troubleshooting Matrix

Best Practices

1. Always update both CPUs to the same firmware major version (both V4.4 or both V4.5). Mismatched major firmware versions can lead to silent connection drops after hours of operation.
2. Use a consistent connection ID convention across the project (e.g. 100 for CPU1 → CPU2, 101 for CPU2 → CPU1). Avoid ID 0 or 1, which are reserved for PG/OP communication.
3. On the partner CPU, leave the access level at "Full access (no protection)" for the commissioning phase, then tighten it back to "Read access" or "HMI access" after verification. Remember that "No access (complete protection)" blocks PUT/GET entirely.
4. Use absolute symbolic names for the data areas (e.g. "HMI_Interface".HMI_Word1) rather than raw pointers. TIA Portal can then validate the area size at compile time.
5. For payloads larger than 160 bytes on V4.x, split the PUT/GET into multiple jobs rather than increasing the byte count; this reduces the chance of a single timeout aborting the entire transfer.
6. Document the TSAP numbers used in the project's communication plan; future engineers can otherwise change them during a TIA upgrade, breaking the connection silently.

FAQ