TIA Portal PUT Instruction: S7-1200 to S7-1500 Data Transfer

1. Overview: S7 Communication with the PUT Instruction

The PUT instruction is part of the S7 communication base block set in TIA Portal and is used to write data from one SIMATIC CPU to a partner CPU on the same Industrial Ethernet subnet. In the typical scenario covered here, an S7-1200 acts as the active (client) side and writes 11 REAL values from a local data block into a matching data block on a remote S7-1500 server. The reverse direction is normally handled with the GET instruction.

Per the official Siemens TIA Portal help, PUT writes data to a remote CPU and is started on a positive edge at the REQ control input (PUT: Write data to a remote CPU). The function block resides in the Instructions > Communication > S7 Communication palette and ships with every CPU firmware that supports S7 communication. The PUT block was carried forward into the S7-1200 G2 line, so the same parameterization applies to S7-1200, S7-1500, and S7-1200 G2 CPUs that all run on a unified TIA Portal project platform.

For 11 REAL values the data footprint is fixed:

• 1 REAL = 32 bits = 4 bytes
• 11 REAL = 11 × 4 = 44 bytes
• Pointer length field on ADDR_1 = 44 (Byte)

The 44-byte payload is well below the maximum S7 PUT/GET payload of 462 bytes per call on a single ADDR_x reference, so no segmentation is required.

2. Prerequisites

Before programming the PUT block, validate the following hardware and software prerequisites. Missing any of these items is the most common cause of an apparently correct configuration that still produces an error on STATUS.

3. Establishing the S7 Connection

An S7 connection is the dedicated transport channel used by PUT/GET. There are two valid ways to create one in TIA Portal.

3.1 Single-project setup (both CPUs in the same project)

1. Open Devices & networks in the S7-1200 station.
2. Drag the S7-1500 from the project tree into the network view if it is not already present.
3. Click the PROFINET port of the S7-1200, drag a connection line to the PROFINET port of the S7-1500, and select S7 connection from the drop-down list. TIA Portal creates an unconfigured S7 connection.
4. Right-click the connection > Properties > General. Verify the local ID (e.g. 100), the partner IP, and the partner rack/slot.

3.2 Two-project setup (CPUs in separate projects)

1. On the S7-1200 side, open Devices & networks > Connections.
2. Choose Add new connection > S7 connection. Set the partner to Unspecified.
3. Enter the remote IP, the remote rack/slot, and leave Establish an active connection enabled (default for the client).
4. Note the connection ID (e.g. ID = 100). This value is what the PUT block's ID input must reference.

4. Adding the PUT Instruction

Open the S7-1200 program block where the data transfer should be triggered (OB1 is acceptable for a periodic trigger; an event-driven OB is preferred for production).

1. Right-click in the program editor > Insert new instruction.
2. Navigate to Communication > S7 Communication > PUT.
3. Drop the PUT block into a network.
4. TIA Portal will auto-generate a background DB (e.g. PUT_DB) for the instance.

The PUT block exposes the following standard interface per the official TIA Portal help (PUT: Set parameters for write and send area):

5. ADDR_1 Pointer Format Explained

The ADDR_1 parameter is the single most misconfigured element in the PUT call. It is a pointer to a remote data area, expressed with the Any-pointer syntax P#DB<number>.DBX<byte>.<bit> BYTE <length>. It does not specify the local source — that is the job of SD_1.

5.1 Pointer syntax table

5.2 Worked example for the 11-REAL transfer

To send 11 REAL from S7-1200 DB100 starting at byte offset 0 to S7-1500 DB300 starting at byte offset 0:

// ADDR_1 (remote destination)
P#DB300.DBX0.0 BYTE 44

// SD_1 (local source)
P#DB100.DBX0.0 BYTE 44

// LEN_1
WORD#16#002C   // 0x002C = 44 decimal

// ID (S7 connection ID)
WORD#16#0064   // 0x0064 = 100 decimal, must match the connection in the network view

If the 11 REAL values start at byte offset 16 in DB100 and must land at offset 32 in DB300:

// SD_1
P#DB100.DBX16.0 BYTE 44

// ADDR_1
P#DB300.DBX32.0 BYTE 44

The length stays at 44 because the payload size is fixed by the data type, not the offsets.

5.3 Why the pointer is required even for DBs

The PUT block transfers raw bytes. It does not interpret symbolic names, so the destination area must be described by its absolute memory address. TIA Portal will accept a symbolic reference in ADDR_1 only if the symbol is fully resolved at compile time; using the explicit P#DB300... form avoids any symbol resolution edge case and is the recommended method.

6. Configuring the Data Blocks for Standard Access

PUT/GET access on an S7-1500 requires that the destination data block is not an optimized block. On an S7-1200, the source DB may be optimized if and only if the call uses a fully qualified symbolic reference that the compiler can resolve. For maximum portability, configure both DBs as standard.

1. Open the DB in the project tree.
2. Right-click Properties > Attributes.
3. Uncheck Optimized block access.
4. Confirm with OK and recompile the project.

After this change, the DB shows a strict byte layout in the Offset column. Use the offsets shown in the Offset column of the DB editor as the basis for the ADDR_1 byte offset.

7. Permitting PUT/GET Access on the S7-1500

This is the configuration that the source author initially missed and the reason the remote DB did not receive any data.

1. Open the S7-1500 device configuration.
2. Select the CPU > Properties > Protection & Security.
3. Scroll to Connection mechanisms.
4. Check Permit access with PUT/GET communication partner.
5. Compile and download the new hardware configuration to the S7-1500.

Repeat the same on the S7-1200. Without this flag the S7-1500 rejects incoming PUT jobs at the communication layer and the client receives a non-zero STATUS value.

8. Triggering the PUT Job and Evaluating Status

The PUT job executes once per rising edge of REQ. The output flags DONE, ERROR, and STATUS are valid for exactly one cycle after the call completes. The STATUS output follows the standard SFB/FB return-code convention:

A typical ladder-style implementation that latches REQ until the job finishes:

// SCL example in OB1
IF "StartTransfer" THEN
    "PUT_DB".REQ := TRUE;
    IF "PUT_DB".DONE OR "PUT_DB".ERROR THEN
        "PUT_DB".REQ := FALSE;
        // copy STATUS somewhere visible if needed
    END_IF;
END_IF;

"PUT_DB".ID   := WORD#16#0064;   // connection ID 100
"PUT_DB".SD_1 := P#DB100.DBX0.0 BYTE 44;
"PUT_DB".ADDR_1 := P#DB300.DBX0.0 BYTE 44;
"PUT_DB".LEN_1 := WORD#16#002C;  // 44 bytes
"PUT_DB"();

9. Troubleshooting Matrix

10. Verification Procedure

1. Compile both stations with Compile > Hardware and software (rebuild all). Resolve all errors and warnings.
2. Download the S7-1200 project first, then the S7-1500 project.
3. Open a watch table on the S7-1200 containing PUT_DB.REQ, PUT_DB.DONE, PUT_DB.ERROR, PUT_DB.STATUS.
4. Force PUT_DB.REQ = TRUE and observe STATUS = 0x0000 within one cycle.
5. Open a watch table on the S7-1500 against DB300 and confirm the 11 REAL values match the source.
6. Use Online & diagnostics > Connections on the S7-1500 to confirm an active S7 connection from the S7-1200 IP.
7. If any values are wrong, repeat the cycle but set PUT_DB.Monitor = TRUE to read the actual SD_1/ADDR_1 pointers in the instance DB and compare to the configuration.

11. Performance and Design Notes

The PUT call is non-blocking. The job is dispatched on the edge of REQ and DONE/ERROR/STATUS report the result on the next call cycle. Typical cycle for a 44-byte PUT on a 100 Mbit/s PROFINET segment is 5 to 15 ms. The block does not consume CPU execution time while waiting — it relies on the S7 communication scheduler.

For repeated periodic transfers, a cyclic OB (e.g. OB35) is preferred over OB1 to keep the trigger deterministic. For event-driven transfers (e.g. after a measurement), latch the trigger in a flag and reset it on DONE.

If the S7-1200 needs to receive data from the S7-1500 in addition, add a second S7 connection (or reuse the same connection) and call GET on the S7-1200 with a similar pointer configuration pointing at the remote source.

FAQ