Configuring Siemens S7 PUT/GET: ANY Pointer Syntax for S7-300/400

1. Overview: PUT/GET in S7 Communication

Siemens S7 PLCs exchange data between CPUs over Industrial Ethernet using the S7 communication protocol. Two fundamental function blocks handle this exchange:

• SFB14 "GET" – reads data from a remote CPU into the local CPU.
• SFB15 "PUT" – writes data from the local CPU to a remote CPU.

For the classic S7-300 and S7-400 families, SFB14/15 are the standard implementation. For S7-1200 and S7-1500, the functionally equivalent instructions are the extended PUT and GET instructions available in TIA Portal under "Communication → S7 Communication." Both implement the same ANY-pointer data layout, the same connection model, and the same R_ID matching concept, so the syntax described here applies to both generations. See the TIA Portal reference at GET and PUT (Read and write from a remote CPU) for the S7-1200 implementation.

The most common reason a PUT/GET call compiles without errors but fails to write data is an incorrectly formatted ANY pointer on parameters SD_1 (source) or ADDR_1 (destination). The block validates the structure internally and may even accept a malformed pointer in some firmware versions, but the partner CPU rejects the telegram with status code W#16#0001 or W#16#0007.

2. Prerequisites

Before any PUT call can move data, the following must be in place:

1. Hardware: Two S7 CPUs equipped with an Ethernet interface (CP343-1 / CP443-1 for S7-300/400; integrated PROFINET port on S7-1200/1500) connected to the same subnet.
2. IP addressing: Both CPUs must have unique IP addresses in the same subnet mask. Put/Get does not require a router.
3. Connection configuration: An S7 connection must be defined in NetPro (STEP 7 V5.x) or in the "Devices & Networks" editor (TIA Portal). The local CPU is the active partner for PUT/GET, the partner CPU is the passive partner.
4. Access rights: On the passive CPU, "Permit access with PUT/GET communication from remote partner" must be enabled (S7-1200/1500: Properties → Protection; S7-300/400: enable the "S7 communication" checkbox in the CPU properties).
5. Data blocks: Source and destination DBs must exist on their respective CPUs, with sufficient length declared in the DB structure.

3. SFB15 "PUT" Block Parameters

SFB15 occupies DB space (instance DB) and has the following interface:

Note: The instance DB is created automatically by STEP 7/TIA when SFB15 is dropped into an OB. A user-defined DB with the same number is not permitted.

4. ANY Pointer Syntax: The Core of the Problem

The ANY pointer is a 10-byte Siemens-specific data type that identifies a memory area, its starting offset, and its length. The literal notation in STL/SCL is:

P#[Area][Byte address][.Bit offset] [Data type] [Length]

Format components in detail:

4.1 Sending 10 Bytes (the Original Question)

The original syntax P#DB1.DBX0.0 BYTE 10 is structurally valid: 10 bytes starting at byte 0 of DB1, bit offset 0. The matching destination on the partner CPU is identical:

SD_1   := P#DB1.DBX0.0 BYTE 10;   // local source: 10 bytes from DB1
ADDR_1 := P#DB4.DBX0.0 BYTE 10;   // remote dest: 10 bytes into DB4
LEN    := 10;                     // total bytes

If no syntax error is reported by the editor but no data is written, the cause is not the pointer itself — see Section 6 for the actual reasons.

4.2 Sending 5 Words (16-bit elements)

The element type changes from BYTE to WORD. A word is 2 bytes, so 5 words = 10 bytes. The address tag must be DBW and the bit offset must be 0:

SD_1   := P#DB1.DBW0 WORD 5;     // CORRECT: 5 words from DBW0 of DB1
ADDR_1 := P#DB4.DBW0 WORD 5;     // 5 words into DBW0 of DB4

Why P#DB1.DBW0.0 WORD 5 fails: in Siemens ANY-pointer syntax, the bit offset is appended to the address token, and the data-type token follows. The bit offset must be specified when the type is BOOL. For BYTE/WORD/DWORD the syntax DBW0 (no bit) or DBW0.0 are both valid, but they cannot be combined with a type token in a single literal the way the original author attempted. The compiler is strict: WORD is a width token, not a part of the address.

4.3 Sending 2 Double Words (32-bit elements)

SD_1   := P#DB1.DBD0 DWORD 2;     // CORRECT: 2 DWords from DBD0 of DB1
ADDR_1 := P#DB4.DBD0 DWORD 2;     // 2 DWords into DBD0 of DB4

2 DWORD = 8 bytes. The starting address is byte-aligned (.0 implied or explicit).

4.4 Mixed Type Summary Table

5. Step-by-Step Configuration

5.1 STEP 7 V5.x (S7-300/400)

1. Open NetPro and double-click the CPU on the Ethernet subnet to add a new S7 connection. Set the local CPU as the active partner, the remote CPU as the passive partner, and enter the partner IP address.
2. Note the local connection ID (e.g., 1) shown in the connection table — this is the value to wire to ID on SFB15.
3. On the partner CPU, in CPU Properties → Communication, enable the S7 communication checkbox and the PUT/GET access option (F-CPU and newer S7-300 CPUs require this).
4. Create the source and destination DBs in each project's S7 program, declaring the full data length you will transfer.
5. Drop SFB15 (PUT) into OB1. STEP 7 will offer to create the instance DB automatically — accept.
6. Wire the inputs as shown in Section 4. Latch the REQ input with a rising-edge bit if you want a one-shot trigger.
7. Compile, download to both CPUs (including the connection configuration), and run.

5.2 TIA Portal (S7-1200/1500)

1. Open Devices & Networks, select the Ethernet interface of the local CPU, and create an S7 connection to the partner.
2. In the CPU properties of the partner, open Protection & Security → Connection mechanisms and enable Permit access with PUT/GET communication from remote partner.
3. Open the program block (e.g., OB1) and insert PUT from the "Communication → S7 Communication" palette. TIA generates the instance DB.
4. Fill the REQ, ID (select from the dropdown of configured connections), SD_1, and ADDR_1 fields using the exact pointer syntax from Section 4.
5. Compile and download both stations.

6. Why the Original Program Did Not Write Data

With a structurally valid pointer and a clean STEP 7 compile, the remaining failure modes are almost always one of the following:

To localise the cause, monitor the STATUS output of SFB15. A full STATUS code table is in the online help of STEP 7 under "SFB15 PUT — STATUS parameter." See also the TIA Portal reference at GET and PUT (Read and write from a remote CPU).

7. Status Code Quick Reference

8. Commissioning Verification

1. From the partner CPU's online view, open DB4 and confirm the data appears in the first 10 bytes after the first successful PUT call.
2. Force a one-shot REQ from the active PLC, watch DONE pulse for one cycle, and confirm ERROR=0 and STATUS=W#16#0000.
3. Set a watch table on the active CPU at the source DB. Toggle a few bytes; verify on the partner that the same bytes change within a single scan cycle of the SFB call.
4. Repeat with the partner in STOP and confirm that the PUT still completes (PUT can write to a partner in RUN or STOP).
5. For cyclic operation, drive REQ with a low-frequency timer (e.g., 100 ms) to avoid flooding the connection.

9. Common Pitfalls and Field Notes

• Bit offset on word/dword addresses: P#DB1.DBW0.0 WORD 5 may compile in some TIA versions but is rejected in STEP 7 V5.x. Use P#DB1.DBW0 WORD 5 for portability.
• Symbolic pointers: In TIA Portal, the SD_1/ADDR_1 input can be wired with a fully qualified DB tag. The compiler then synthesises the ANY pointer — no literal required.
• Multiple SD_/ADDR_ pairs: SFB15 supports up to four disjoint source ranges per call. The combined byte count across all SD_i must equal LEN, and each pair must match in length.
• Optimised DBs on S7-1200/1500: When PUT/GET is used on an S7-1200/1500 partner, the destination DB must be non-optimised (i.e., "Standard" or "Accessible from HMI/OPC UA") with the "Disable optimised block access" attribute. Optimised block access is not addressable by absolute byte offsets.
• CPU firmware ≥ V4.x on S7-1200: PUT/GET with optimized DBs is supported only on S7-1200 V4.0 and higher; older firmware requires the same non-optimised layout.
• Maximum payload: 160 bytes per PUT/GET call. For larger transfers, use multiple calls or switch to BSEND/BRCV.
• Connection resources: Each configured S7 connection consumes one connection resource on both CPUs. S7-300 has a small pool (typically 4–16); S7-400 and S7-1500 are more generous.

10. Ladder-Logic Example (STEP 7 V5.x)

// One-shot trigger for PUT
NETWORK 1
      A     "StartPutTrigger"      // Boolean from HMI or logic
      FP    "PUT_OneShot"          // Edge memory bit
      =     "PUT_REQ"

NETWORK 2
      CALL  "PUT" , "PUT_DB"
         REQ   := "PUT_REQ"
         ID    := W#16#1          // Connection ID from NetPro
         SD_1  := P#DB1.DBX0.0 BYTE 10
         ADDR_1:= P#DB4.DBX0.0 BYTE 10
         LEN   := 10
         DONE  := "PUT_DONE"
         ERROR := "PUT_ERROR"
         STATUS:= "PUT_STATUS"

11. FAQ