Enabling PUT/GET Access on S7-1200 for S7-400 SFB14 Communication

1. Problem Statement and Symptom Description

Cross-family PUT/GET communication between a classic S7-400 (configured with STEP 7 / SIMATIC Manager) and a TIA Portal-programmed S7-1200 frequently fails with a single, easy-to-miss error: the S7-400 reports STATUS = W#16#0002 at the STATUS output of SFB14 "GET" and SFB15 "PUT". The STEP 7 online help translates this value verbatim as:

"Negative acknowledgement from the partner device. The function cannot be executed."

The wording looks like a TCP handshake failure, but in practice every other layer is healthy:

• The PROFINET port on the S7-400 and the S7-1200 both show link and activity LEDs.
• Ping between 192.168.201.165 (S7-400) and 192.168.201.168 (S7-1200) succeeds with sub-millisecond RTT.
• An S7 connection has been configured on the S7-400 (NetPro / S7-Connection configured with the S7-1200's IP address and matching TSAPs).
• Target DBs on the S7-1200 (e.g., DB200 used for GET, DB201 used for PUT) exist, are non-optimized, and "Accessible from HMI/OPC UA"-equivalent access flags are not blocking the read.

The S7-400 CPU is online in RUN, the instance DB of SFB14 has valid values for ID, ADDR_1..ADDR_4, and RD_1..RD_4 (or SD_1..SD_4 for SFB15), but every call returns STATUS = 2 within one scan cycle. The error does not toggle, does not time out, and never self-heals. This pattern is the fingerprint of an S7-1200 protection setting, not a wiring or routing problem.

2. Affected Hardware and Firmware Versions

The behavior is independent of the S7-400 model and firmware. The trigger sits entirely on the S7-1200 side and is bound to a specific firmware feature introduced in V4.0 of the S7-1200 CPU family.

3. Root Cause: PUT/GET Is Disabled by Default Since V4.0

Prior to firmware V4.0, every S7-1200 CPU accepted inbound PUT/GET requests from any S7 partner that could reach it on the PROFINET interface. With V4.0, Siemens tightened the default security posture: an S7-1200 now refuses every PUT, GET, and (with V4.2+) unsolicited communication request until an explicit allow-flag is set. The flag lives under the CPU's Protection properties and is not visible without scrolling the dialog - which is exactly why engineers who search for it often assume the option does not exist.

Mechanically, what the S7-1200 returns to the S7-400 is a TDOPDU negative acknowledgement with cause "object access not allowed in current operating mode / access protection active." The S7-400 translates this into STATUS = 2 on SFB14/SFB15. There is no alarm or diagnostic buffer entry on the S7-1200 for this rejection - it is treated as a normal access check failure - so the S7-1200's online diagnostics appear empty even while the S7-400 is being rejected every cycle.

4. Resolution: Enable PUT/GET Permission in TIA Portal

The fix is performed on the S7-1200 project in TIA Portal and takes effect immediately after the project is downloaded to the CPU. No S7-400 change is required.

1. Open the S7-1200 project in TIA Portal and select the S7-1200 CPU in the project tree (device view).
2. Open the Inspector window (right pane) or right-click the CPU and choose Properties.
3. In the Properties dialog, navigate to Protection > Access level (the exact path is "Properties > General > Protection" in newer TIA Portal releases; the toggle is on the same tab in all versions since V13 SP1).
4. Set the access level to "Full access" or "Read access" as required for your project. This step alone is not enough. Setting the access level to "Full access" controls read/write access from HMI and OPC UA but does NOT enable PUT/GET by itself.
5. Scroll down inside the Protection / Access level tab. There is a separate section titled Connection mechanisms (or "Permit access with PUT/GET communication from remote partner," depending on TIA Portal version).
6. Tick the checkbox "Permit access with PUT/GET communication from remote partner".
7. Click OK, translate (compile) the project, and download the hardware configuration to the S7-1200. The CPU will go to STOP briefly during download.

After the S7-1200 returns to RUN, the next SFB14 / SFB15 call from the S7-400 returns STATUS = W#16#0000 (no error) and the data area is updated on the very next scan.

5. S7-400 Side Configuration: SFB14 and SFB15

Once the S7-1200 is unlocked, the S7-400 calls need to be correct. The S7-400 always uses SFB14 (GET, FDL-free read) and SFB15 (PUT, FDL-free write) for partner-agnostic S7 communication, with an instance DB per call direction. The "SFB14 version 1.0" mentioned in the source is correct for any S7-300/S7-400 CPU with firmware V3.0 or higher.

Sample call configuration for SFB14 (GET) on the S7-400:

SFB15 (PUT) uses the symmetric parameters: SD_1..SD_4 as the local source, ADDR_1..ADDR_4 as the partner destination. SFB15 does NOT have an NDR output; it has DONE which becomes TRUE for one scan when the write completes successfully.

Constraints specific to PUT/GET against an S7-1200:

• The total payload per call is limited to a combined 160 bytes (sum of all ADDR_x / RD_x / SD_x byte lengths). Larger transfers must be split across multiple calls.
• Only standard-access (non-optimized) DBs are reachable on the S7-1200. S7-1200 DBs default to optimized block access; the toggle "Optimized block access" must be cleared under DB Properties > Attributes.
• Bit memory (M), inputs (I), and outputs (Q) areas are also reachable; they are always non-optimized on S7-1200.

6. S7-1200 Side: DB Attribute Requirements

The S7-1200 DBs the S7-400 reads or writes must be reachable through absolute addressing, which means the DB must be non-optimized. This is independent of the PUT/GET toggle - even with the toggle enabled, an optimized DB cannot be reached by SFB14/SFB15 because the absolute byte offsets inside the DB are not fixed.

Procedure for the S7-1200 DBs used as communication buffers:

1. Open DB200 (used as the GET source) and DB201 (used as the PUT destination) in the S7-1200 project.
2. Right-click the DB header > Properties > Attributes.
3. Clear the checkbox "Optimized block access".
4. Confirm with OK. The DB must be recompiled and downloaded to the S7-1200.
5. Verify in the S7-1200 online view that the DB shows standard access (no "S7-1200 optimized" icon).

If you must keep an optimized DB, use a separate non-optimized DB as a mirror: have the S7-1200 program copy the optimized DB's contents into the non-optimized DB on each scan, then point the S7-400 SFB14 to the non-optimized mirror.

7. S7 Connection Configuration

The S7 connection from the S7-400 to the S7-1200 is established by the S7-400 side. The S7-1200 does not require any configured connection - it accepts PUT/GET once the toggle is enabled and the partner sends a connection request to its PROFINET interface.

S7-400 configuration procedure (STEP 7 V5.5 / V5.6 / NetPro):

1. Open NetPro, right-click the S7-400 CPU > Insert New Connection.
2. Connection type: S7 connection. Partner: Unspecified (because the S7-1200 is configured in TIA Portal and not visible in STEP 7 NetPro).
3. Open the connection properties and enter the partner address: IP = 192.168.201.168 (S7-1200).
4. Set the partner's TSAP. Default for an S7-1200 PUT/GET partner is 03.01 (rack 0, slot 1 for the PROFINET interface). Set the local TSAP to any unused value, e.g., 10.00.
5. Save and compile (NetPro > Save and Compile). The download to the S7-400 will push the connection configuration.

If you are using TIA Portal on the S7-400 side as well, configure the connection with Configure S7 connection > Unspecified partner instead and enter the same IP and TSAP values.

8. Verification and Online Diagnostics

After enabling the PUT/GET toggle on the S7-1200 and downloading both projects:

1. Go online to the S7-400 (STEP 7) and open the instance DB of SFB14 in monitor mode.
2. Force REQ = TRUE. Within one to two OB1 cycles, NDR should pulse TRUE and STATUS should read W#16#0000.
3. Monitor RD_1 in the S7-400 - it should now contain the integer value the S7-1200 program is incrementing in DB200.
4. Open the S7-1200 online diagnostics buffer. There should be NO new entries - the rejection messages are not logged because they are access-control rejections, not communication errors.
5. Repeat for SFB15 (PUT). DONE should pulse TRUE and the value you wrote from the S7-400 should appear in DB201 on the S7-1200.

If STATUS remains 2, see Section 9.

9. Troubleshooting Matrix for SFB14 / SFB15 STATUS Codes

10. Best Practices and Field-Proven Notes

From real commissioning environments, the following rules eliminate 95% of PUT/GET issues between S7-400 and S7-1200:

• Treat the PUT/GET toggle as a required checkbox in every S7-1200 project that talks to a non-S7-1200 partner. Document it in your project template so it is never forgotten.
• Always use dedicated, non-optimized DBs (e.g., DB200..DB299) as communication buffers. Never put application logic tags in those DBs - keep them strictly as data exchange areas.
• Reserve TSAP 03.01 for S7-1200 PUT/GET partners - that is the default PROFINET interface slot. Avoid using 03.00 or higher slot numbers unless you are addressing a CP in the S7-1200 rack.
• Limit each PUT/GET call to < 100 bytes. Split large datasets across multiple calls triggered by a sequencer on the S7-400 to avoid congestion if the S7-1200 momentarily pauses for an interrupt OB.
• On the S7-400 side, watch ERROR / STATUS every cycle and trigger a single retry after a configurable backoff (50-200 ms) before escalating to a system fault. SFB14/SFB15 STATUS 2 may briefly occur during S7-1200 RUN-STOP-RUN transitions.
• Do not mix PUT/GET with OPC UA on the same S7-1200 DB without verifying byte offsets. OPC UA uses symbolic addressing, PUT/GET uses absolute - both can coexist on a non-optimized DB but the offsets must be planned.
• For higher throughput or larger payloads, migrate from PUT/GET to S7 communication via TIA Portal on both sides (where possible) - this unlocks the full S7-1500 / S7-1200 PUT/GET capabilities with up to 462 bytes per call.

11. Frequently Asked Questions