Configuring S7-1200 to S7-1500 PUT/GET Communication in TIA Portal

S7 Communication between an S7-1200 and an S7-1500 using the PUT and GET instructions is one of the most common data exchange patterns in SIMATIC automation cells. Despite the simplicity of the instruction interface, engineers frequently report a working Ethernet connection yet zero data movement, often accompanied by STATUS = 0 and a clear ERROR bit. This guide consolidates the official Siemens configuration path, the protection flags that block remote access, the data block accessibility rules, and the diagnostic workflow that isolates the root cause in the field.

1. Overview of S7 PUT/GET Communication

The PUT instruction writes data from a local source area to a partner CPU. The GET instruction reads data from a partner CPU into a local destination area. Both instructions operate on top of the S7 Communication protocol, which is transported over ISO-on-TCP (port 102) on the PROFINET interface. No additional hardware is required beyond the onboard Ethernet port of each CPU; no CP is necessary unless the application requires routing through a different subnet or a media converter.

Because the protocol is connection-oriented, every PUT or GET call must be bound to an S7 connection that has been engineered in TIA Portal. The CPU that owns the instruction is the active end of the connection; the partner CPU only has to allow the connection. This is the architectural reason the "Permit access with PUT/GET" flag exists in the S7-1500 protection properties — it is a one-way permission that turns the S7-1500 into an S7 server capable of accepting PUT and GET requests from any reachable active partner.

Refer to the official Siemens documentation for the full instruction semantics and the supported data types:

• PUT and GET (Write and read from a remote CPU) — TIA Portal Manual Collection
• S7 Communication with PUT/GET — Siemens Industry Online Support (PDF application example)

2. Prerequisites and Component Selection

Confirm the following before opening TIA Portal:

3. Step 1 — Configure Static IP Addresses

Assign a unique IP address to each CPU on the same subnet. The PROFINET interface of the S7-1200 is configured under Device view > PROFINET interface > Ethernet addresses. The S7-1500 uses the same dialog in its Device configuration.

Recommended addressing for the example referenced in the field reports:

• S7-1200: 192.168.0.1 — subnet mask 255.255.255.0
• S7-1500: 192.168.0.2 — subnet mask 255.255.255.0
• Engineering PG/PC: 192.168.0.100 (do not place on the same address as either PLC)

A common commissioning defect is leaving the PG on the default subnet and accidentally forcing an address collision with one of the PLCs. When TIA Portal reports "Online — different IP, accessible," the IP of the CPU itself has been overwritten; reset the CPU to factory defaults and re-assign the intended address.

4. Step 2 — Enable PUT/GET Access on the S7-1500

The S7-1500 CPU ships with remote PUT/GET access disabled. Without this flag, the CPU will accept the S7 connection establishment but will return a negative acknowledgment to every PUT / GET request, leaving the active partner reporting STATUS = 0x80A0 or 0x8188 depending on the firmware.

Enable the flag at:

1. Open the S7-1500 device in the project tree.
2. Select Properties > Protection & Security in the Inspector window.
3. Expand Connection mechanisms.
4. Tick Permit access with PUT/GET communication from remote partner (PLC, HMI, OPC, ...).
5. Compile and download the hardware configuration to the S7-1500.

Refer to the protection dialog in the TIA Portal help: Properties > Protection & Security > Connection mechanisms > Permit access with PUT/GET communication from remote partner. The same checkbox exists on the S7-1200 when it plays the server role in a different project topology.

5. Step 3 — Engineer the S7 Connection

The S7 connection is the runtime object that binds the local instruction to the partner CPU. Without it, the PUT/GET block has no valid ID to use.

1. In the project tree, select the local CPU (e.g. the S7-1200) and open Devices & Networks.
2. Switch to the Connections tab at the top of the network view.
3. Choose S7 Connection from the drop-down, then click the local PROFINET interface.
4. Drag the connection line to the partner PROFINET interface.
5. Open the connection properties and confirm the partner IP address matches the S7-1500 192.168.0.2.
6. Note the Connection ID — by convention this is 1 for the first connection but TIA Portal may assign any free ID. The active CPU's instruction must use this exact ID.

Compile the project and download the connection configuration to both CPUs. A connection that exists only in the project tree of the active CPU will not work because the S7 server side must also know the local TSAPs.

6. Step 4 — Create Non-Optimized Data Blocks

On a CPU with optimized block access (the default for newly created DBs in S7-1500 firmware V2.0+), the PUT/GET request can read or write the data only if the block properties allow it. For absolute addressing from a partner, two conditions must be met:

1. Open the DB in the project tree.
2. Open Properties > Attributes.
3. Uncheck Optimized block access (this is the S7-1500 default only when the block is created from an S7-1200 template; S7-1500 always defaults to optimized).
4. Confirm the Accessible from HMI/OPC UA checkbox under Attributes > Accessibility is enabled if the block must remain optimized but reachable by S7 Communication — on S7-1500 firmware V2.0+, this single checkbox is sufficient and the block can stay optimized.

The simplest, most portable configuration is: disable optimized access, then reference the data by absolute address in the PUT/GET instruction. Define the data as a plain structure, for example DB20.DataToSend : ARRAY[0..9] OF BYTE, and let the compiler assign it to DB20.DBX0.0 (byte 0) onwards.

7. Step 5 — Program the PUT/GET Blocks

The blocks live in Instructions > Communication > S7 Communication. In the local CPU's main OB (typically OB1 or a cyclic OB), add a PUT and a GET instance, and assign them a multi-instance data block so they retain their static parameters across scans.

PUT block parameters

GET block parameters

A robust cyclic pattern is to use a 1 Hz clock from the local CPU's system clock (e.g. Clock_1Hz in the S7-1200/1500 system DB) to drive REQ, so the transfer runs on a fixed cadence without any code from the user. Avoid calling the block in OB1 on every scan — the connection is busy and the REQ edge is ignored; calling it more frequently than the cycle can mask legitimate error events.

8. Step 6 — Download and Go Online

1. Select the local CPU in the project tree, click Download to device, and choose Hardware and software (only changes).
2. After the local CPU is updated, right-click the partner CPU and choose Download to device > Hardware configuration so the connection is registered on the server side as well.
3. Go online with the local CPU and open the Watch table that contains the instruction status tags.
4. Force REQ by toggling the trigger tag, or wait for the clock pulse.

9. Diagnosing "Communication Established but No Data"

The most reported field failure is: TIA Portal's Online & Diagnostics > Connections shows the S7 connection as Established, yet PUT.DONE never sets and PUT.STATUS returns 0, or PUT.ERROR sets immediately with a non-zero STATUS. The STATUS = 0 symptom with ERROR = FALSE is the signature of a never-issued job — the trigger tag never produced a rising edge, or the connection ID is wrong. The ERROR = TRUE symptom with a non-zero STATUS is the signature of an issued job that the partner rejected.

Use the following decision tree before changing code:

1. Confirm the trigger. Place a watch on REQ. If the bit never goes high, the instruction is not being called with a rising edge. Add a set/reset latch or use a clock bit.
2. Confirm the connection ID. Open the connection in Connections, read the ID, and compare it byte-for-byte to the constant in the block. The most common mistake is to specify W#16#1 in the block but leave the connection at the auto-assigned ID W#16#100.
3. Confirm the partner IP. In the connection properties, expand Addresses and check the Partner IP address. An IP that points at the engineering PC rather than the partner CPU will not return a clear error — TIA Portal simply shows the connection as established to the local CPU's loopback.
4. Confirm PUT/GET access on the server. On the S7-1500, open Properties > Protection & Security > Connection mechanisms and verify the flag is still set. A subsequent download of a different configuration can silently overwrite the protection flags.
5. Confirm the data block accessibility. If the partner DB is optimized and "Accessible from HMI/OPC UA" is off, the server returns a resource error. The active partner sees STATUS = 0x80B1 or 0x80A0 depending on firmware.
6. Confirm the length and pointer types. SD_1/RD_1 and ADDR_1 must use the same length unit. A common mistake is BYTE 10 on the local side and WORD 5 on the remote side — the instruction uses the partner length for the actual read, but TIA Portal warns only at compile time.

10. PUT/GET Status Code Reference

The STATUS word uses two 8-bit fields: the high byte is a general class, the low byte is a detailed code. The most frequently observed values during PUT/GET commissioning are:

11. Verification Procedure

After completing the configuration, perform the following checks to certify the data path:

1. Online > Connections. The S7 connection state should be Established and remain stable for at least 60 s.
2. Watch table on active side. Force a known pattern into the local source DB, trigger REQ, and verify DONE / NDR pulses for one scan and that STATUS reads 16#7002 followed by 16#0000.
3. Watch table on partner side. Open an online watch on the partner DB and confirm the value matches the local source after the next REQ pulse.
4. Reverse direction. Repeat the test with the GET block by writing a value into the partner DB and confirming the local destination DB updates.
5. Sustained load. Drive REQ with a 100 ms clock and let the cell run for at least 10 minutes. If ERROR ever sets, capture the STATUS and resolve before declaring the path production-ready.

12. Troubleshooting Matrix

13. Performance and Sizing Notes

PUT/GET uses a single S7 connection for all PUT and GET instances bound to the same ID. Each instruction call sends a single PDU; the wire time for a 240-byte PDU on a 100 Mbit/s PROFINET segment is dominated by the S7 handshake and is typically 8 ms to 15 ms per job. A 1 Hz update rate is therefore well within the budget; do not exceed 10 Hz for non-critical data to avoid saturating the connection.

For larger payloads (above 480 bytes) or higher update rates, consider migrating to the BSEND/BRCV or USEND/URCV instruction pair, which use the same S7 connection but allow segmented transfer. For multi-partner scenarios, each partner requires its own S7 connection and a unique ID. The S7-1200 supports up to 8 S7 connections; the S7-1500 supports 16 or more depending on firmware and CPU type.

14. Common Field Misconfigurations

Five configuration errors account for the majority of field calls about PUT/GET:

1. Forgetting the PUT/GET flag on the S7-1500. Most common — fixed in step 2.
2. Connection downloaded to the active CPU only. The partner CPU never knows the S7 connection exists and rejects every request. Always download the hardware configuration to both CPUs.
3. Using a fresh, optimized DB on the S7-1500 without enabling HMI/OPC UA accessibility. The CPU answers with a resource error.
4. Forcing the REQ input to a constant TRUE. The instruction requires a rising edge; a level does not start a job.
5. Storing a word array in one DB and reading it as a byte array in the partner. The data is sent but the partner interprets the high/low bytes swapped, producing values that are nonsense on a human-machine interface.

15. Quick-Reference Checklist

• [ ] Both CPUs have unique static IPs in the same subnet.
• [ ] S7-1500 has Permit access with PUT/GET communication from remote partner enabled.
• [ ] S7 connection engineered in Devices & Networks > Connections and downloaded to both CPUs.
• [ ] Partner DB is non-optimized or optimized with Accessible from HMI/OPC UA on.
• [ ] Block ID matches the connection ID exactly.
• [ ] REQ is driven by a clock bit or a rising-edge detector.
• [ ] Local and remote pointer types and lengths match.
• [ ] Watch table confirms DONE/NDR and correct STATUS on success.

FAQ