Fixing S7-1500 to S7-300 PUT/GET Error 16#0001 Connection Failure

Problem Overview

A S7-1500 controller is configured as a PUT/GET client or server with an S7-300 partner over a PROFINET/Industrial Ethernet subnet. The PUT and GET instructions in the S7-1500 user program (or the equivalent FBs FB 15 PUT / FB 14 GET in the S7-300) immediately return status code 16#0001. The status word STATUS on the instruction instance reports the same value on every call. The TIA Portal Online & Diagnostics view for the S7-1500 shows the S7 connection in the project tree marked with a red bar, and the connection inspector reports:

"Not available, only exists offline"

Physical diagnostics are clean: PING between both CPUs succeeds, the PROFINET port LEDs show link, and the S7-300 is reachable from the S7-1500 by every other means. The PUT/GET data exchange, however, never takes place because the S7 connection that the S7-1500 expects has never been established in the partner CPU.

This is one of the most common error conditions when a SIMATIC S7-1500 and a SIMATIC S7-300 are integrated into a single TIA Portal project (or paired through an unspecified S7 connection) and the engineer assumes that compiling and loading the program is sufficient to activate the connection. It is not: the connection is a project-wide resource, and it must be downloaded to both controllers in a specific way.

Affected Systems and Firmware

Root Cause Analysis

There are five distinct root causes for the symptom pair 16#0001 + "only exists offline". They must be ruled out in order from the most common to the rarest.

Cause 1 – S7 Connection Was Never Downloaded

TIA Portal keeps the S7 connection definition in the Devices & Networks editor. Compiling the project writes the configuration into the offline project database, but the connection record is not part of the program blocks (OB/FB/FC/DB). It is part of the system data that is generated from the device configuration. If the engineer performs a Program download only (blocks), the S7 connection object never reaches the CPU. The CPU therefore has no idea that the connection ID referenced by PUT/GET exists, the local connection table is empty, and PUT/GET reports 16#0001.

Cause 2 – The S7-300 Was Added as an Unspecified Partner

When the S7-300 is added to the TIA Portal project as an unspecified CPU (because it is programmed in STEP 7 V5, or because it lives in a different TIA Portal project), the S7-1500 side has a connection record in the system data, but the S7-300 side has no matching record in its online project. The S7-300 firmware only accepts the connection if it has a corresponding local connection in its own configuration, with the same connection ID and IP partner reference. If that record is missing on the S7-300 side, the S7-1500 will report the connection as offline.

Cause 3 – S7-300 Connection Resource Exhaustion

S7-300 CPUs have a small, fixed S7 connection resource table. The first connection slot is occupied by the programming device (PG) connection; each additional PUT/GET, HMI, OPC, routing, or open communication partner consumes another. Once the table is full, the CPU silently drops the S7-1500 partner's connection request. PUT/GET on the S7-1500 reports 16#0001 because no S7 connection was ever accepted by the S7-300.

Cause 4 – CP Card Routing / IP-VLAN / ISO Transport Mismatch

If the S7-300 uses a CP (Communications Processor, e.g. CP 343-1 Lean, CP 343-1 Advanced, CP 343-1 ERPC) for the S7-1500 traffic while the PG, HMI, and routing use the integrated PROFINET interface, the CP must be configured with the same IP subnet and the S7 connection must target the CP's IP address, not the CPU's PN port. If the CP runs the S7 protocol on a different VLAN or is left at its factory ISO-on-TCP setting while the S7-1500 uses plain TCP, the connection will appear to be established on the link layer but fail at the S7 connection establishment. The S7-1500 reports 16#0001 because the S7-300 never completes the connection.

Cause 5 – Asymmetric Connection ID / DB Pointer

The ID input of PUT/GET must match the connection ID of the configured S7 connection object, and the remote ID on the S7-300 side must mirror it. A mismatch is reported as 16#0001 because the S7-300 cannot dispatch the request to the right local partner. Similarly, a malformed SD_1/RD_1 pointer (for example, a DB that has not been loaded, a DB whose optimized block access is enabled on the S7-1500, or a pointer that crosses the 16-bit word boundary when an area-of-bits length is used) can also surface as 16#0001 on the S7-1500 because the request never gets a positive response.

Diagnostic Procedure

Run the following checks in order. Each step is non-destructive and can be executed while the process is running, provided the S7-1500 has a buffered status display or a connected HMI.

1. Confirm the network path. Use the S7-1500's Web server or HMI to run a ping to the S7-300 PROFINET interface IP and to the CP IP (if used). Document round-trip time. A 0% loss is required.
2. Read the online connection table on the S7-1500. In TIA Portal, right-click the S7-1500 device → Online & Diagnostics → Connections. Every configured S7 connection is listed. The failing connection shows the red bar with the message "Not available, only exists offline". This confirms that the S7-1500 has the connection record loaded but cannot establish the S7 session.
3. Read the online connection table on the S7-300. In STEP 7 V5, use PLC → Module Information → Communication or, in TIA Portal, the equivalent Online & Diagnostics > Connections view. Confirm that the S7-1500 appears as an active or passive connection partner. If the S7-1500 is not in the list, the S7-300 has not received the connection configuration.
4. Count active connections on the S7-300. In the same dialog, the S7-300 reports the number of currently used connections out of the maximum for the CPU. If the value is at the maximum, the cause is resource exhaustion.
5. Capture the S7-1500 diagnostics buffer. In Online & Diagnostics > Diagnostics Buffer, search for entries containing the failing connection ID and the S7-300 IP. Typical messages: "Connection request rejected", "Partner resource exhausted", "No resources for new connection".
6. Check the S7-300 diagnostics buffer. When the S7-300 is online, the diagnostics buffer will show a communication entry that pinpoints the partner IP and the reason. The two entries of interest are "Connection aborted: partner not reachable" (network) and "No free connection resources" (exhaustion).

Solution 1 – Load the Hardware Configuration (System Data)

The most common fix is to load the system data (the S7 connection record) instead of the program blocks alone.

1. In the TIA Portal project tree, right-click the S7-1500 device.
2. Choose Download to device → Hardware configuration (or Software and hardware configuration on TIA Portal V17 and later). The dialog expands to show the connection establishment status; the failing connection is now reported as "Established" immediately after the download.
3. Repeat the same step for the S7-300 if it is part of the same TIA Portal project. If the S7-300 lives in a STEP 7 V5 project, use PLC → Download → Connection Configuration in NETPRO, not Download Blocks.
4. Go online and confirm with the Online & Diagnostics → Connections view that the red bar is gone.
5. Trigger a PUT/GET cycle and verify the status word is no longer 16#0001.

Solution 2 – Configure the Unspecified S7 Connection

If the S7-300 is an unspecified CPU in the TIA Portal project, TIA Portal does not know the S7-300's connection resources. The S7-1500 side configuration must be paired with a manual configuration on the S7-300 side.

1. On the S7-1500 side: Devices & Networks → Network view → click the S7-1500 PROFINET interface → Properties → Connections → add an S7 connection. Select the S7-300 partner as Unspecified and enter the S7-300 IP address, the rack/slot, and the connection ID. Note the connection ID (e.g. W#16#0100) and the local TSAP / remote TSAP.
2. Compile the S7-1500 station and load the hardware configuration as described in Solution 1.
3. On the S7-300 side (STEP 7 V5): open NETPRO → right-click the CPU → Insert New Connection → choose S7 Connection → Unspecified. Enter the S7-1500 IP, the rack/slot, and the same connection ID that was used on the S7-1500 side. The local and remote TSAP must mirror.
4. Download the connection configuration from NETPRO to the S7-300. Do not download blocks; download Connections only.
5. Verify on both sides that the connection is listed as Established in the online view.

For cross-vendor consistency, refer to the Siemens KB article on S7-1500 / S7-300 PUT/GET configuration, SIMATIC S7-1500 / S7-300 communication via PUT/GET. The KB explicitly documents the asymmetric connection configuration when the S7-300 is an unspecified partner.

Solution 3 – Free S7-300 Connection Resources

If the diagnostic from step 4 above shows the S7-300 at its connection limit, reduce the number of simultaneous partners. The S7-300 connection budget depends on the CPU type; the values below are taken from the SIMATIC S7-300 system manual and should be cross-checked against the specific CPU order number (MLFB) in Siemens Industry Online Support.

To consolidate, do the following:

1. List every active partner: PG, HMIs, OPC server, S7-1500, S7-1200, S7-400, S7 routing partners, open communication partners.
2. Eliminate redundant PG connections by setting "One PG connection per CPU" in the S7-300 configuration.
3. Combine HMI panels behind a single S7 routing path where possible.
4. Move the S7-1500 PUT/GET traffic to a CP 343-1 if the integrated PN interface is saturated. The CP opens its own S7 connection table (typically 16 – 48 connections depending on the CP type and firmware), which keeps the S7-300 CPU table free for the higher-priority partners.

Solution 4 – CP Card / VLAN / IP Addressing

When the S7-300 uses a CP card for the S7-1500 PUT/GET link, the CP must be a properly configured member of the same IP subnet as the S7-1500 PROFINET interface, and the S7 connection on the S7-1500 side must target the CP IP address, not the CPU's integrated PROFINET IP.

1. On the S7-300 side (STEP 7 V5 or TIA Portal), open the CP's hardware configuration and confirm the IP address, subnet mask, and the S7 connection partner. The CP's S7 connection must mirror the S7-1500 connection exactly.
2. If the CP supports VLAN tagging (CP 343-1 Advanced, CP 343-1 ERPC), assign the S7-1500 traffic to a dedicated VLAN and tag the S7-1500 PROFINET interface port accordingly. Keep the PG / HMI traffic on a separate VLAN to isolate broadcast domains.
3. If the S7-300 was previously using the CP for ISO transport (e.g. legacy S7-400 partner) and the S7-1500 expects ISO-on-TCP, reconfigure the CP connection type to ISO-on-TCP (port 102). The mismatch is the most common reason for an S7-1500 reporting 16#0001 when the CP link is green.
4. If the CP's IP address is in the same subnet as the integrated PROFINET interface, the S7-300 will accept connections on the integrated interface and also try to accept them on the CP. Disable the integrated PROFINET interface's S7 connection (or the CP's S7 connection) to remove the ambiguity. The most reliable pattern is: S7-1500 PUT/GET → CP 343-1; PG and HMI → integrated PROFINET interface.

The CP's connection partner is configured in HW Config under the CP's S7 connections tab. The CP is loaded independently of the CPU's program blocks: right-click the CP in NETPRO → Download. Re-verify by opening the CP's Online & Diagnostics view and confirming that the S7-1500 appears in the CP's connection list as Established.

Solution 5 – Connection ID, DB Pointer, and Optimized Block Access

If the S7-1500 reports 16#0001 and the connection is shown as Established in the Online & Diagnostics view, the connection itself is healthy and the issue is in the PUT/GET data path.

• Connection ID. The ID input of PUT/GET must be the connection ID of the configured S7 connection object in TIA Portal. A common mistake is to enter the connection ID of a different S7 connection (e.g. an HMI connection) that happens to point at the same IP. Verify the connection ID under Properties → General → Connection ID in the connection editor.
• DB pointer on the S7-1500 side. The SD_i / RD_i pointer references an area in a DB. If the DB is optimized (the default for S7-1500), a pointer of type P#DB100.DBX0.0 BYTE 100 still works, but a pointer of type P#M0.0 BYTE 100 works only if the S7-1500 has the Enable PUT/GET access from remote partner attribute set on the CPU's Protection & Security properties. This attribute is off by default on firmware V2.6 and later. Enable it under CPU Properties → Connection mechanisms → Permit access with PUT/GET from remote partner.
• DB pointer on the S7-300 side. The S7-300 receives the data with FB 15 PUT / FB 14 GET. The remote ADDR_i pointer must reference a DB that exists in the offline project and has been loaded. A DB that was added in the offline program but not yet downloaded is invisible to the S7-1500 partner, and PUT/GET reports 16#0001 because the S7-300 cannot return a positive response.
• Length boundary. PUT/GET can transfer up to 462 bytes per call. If a length of WORD n is used with an odd number of bytes (e.g. 5 bytes of bits), the S7-300 rejects the request and the S7-1500 reports 16#0001 or 16#8085. Round up to an even byte count or use a separate call for the trailing bits.

PUT/GET Error Code Reference

The following status values are the most common codes returned by the S7-1500 PUT/GET instruction. They are derived from the S7-1500 system manual, volume 1, and from the TIA Portal help for the instruction. Use this table to triage 16#0001 and adjacent values.

Verification

After applying any of the solutions above, run the following sequence to confirm the PUT/GET link is healthy.

1. Open the S7-1500 Online & Diagnostics view. The S7 connection to the S7-300 must show the green bar with the message Established.
2. Open the S7-300 Module Information (or Online & Diagnostics if both are in TIA Portal). The S7-1500 must be listed as an active connection partner.
3. Force a PUT/GET cycle from the S7-1500 user program. The STATUS word of the instruction must read 16#0000 on success.
4. Read the S7-300 diagnostics buffer for any communication errors. A clean buffer over a 10-minute window is the strongest single indicator.
5. Check the S7-1500 connection counter under Online & Diagnostics → Connections → Statistics (TIA Portal V17 and later). The failed connection attempts counter must not increment during a continuous PUT/GET test.

Preventive Measures

• Always perform a full station download (software and hardware configuration) on both controllers after any change in Devices & Networks. A Program blocks only download does not propagate S7 connection records.
• Enable PUT/GET access on the S7-1500 CPU under Protection & Security → Connection mechanisms → Permit access with PUT/GET from remote partner. The option is disabled by default on firmware V2.6 and later.
• Document every S7 connection with its connection ID in the project documentation. A centralized table of (local ID, partner IP, partner ID, partner TSAP, partner slot) reduces the time to triage 16#0001 from hours to minutes.
• Reserve one connection slot on the S7-300 for diagnostics. The first slot is occupied by the PG; reserve the second for the S7-1500 PUT/GET link. If a fourth HMI is later added, the diagnostic slot is the one to free.
• Use a CP for PUT/GET traffic if the S7-300 has more than 12 active partners or if the integrated PROFINET interface is shared with HMI and routing traffic. The CP isolates the S7-1500 traffic and provides a separate connection resource table.
• Validate after every firmware update. Siemens occasionally changes the S7 connection resource table in firmware releases for the S7-300 CPUs and the CP 343-1 family. Check the firmware release notes on Siemens Industry Online Support before applying firmware in production.

Field Notes and Edge Cases

The following are field-confirmed variations of the same symptom that the official documentation does not always call out:

• Multiple TIA Portal projects, one S7-300. When the S7-1500 and the S7-300 each live in their own TIA Portal project, both projects must be loaded for the S7 connection to be established from both sides. Loading only one of the two projects will produce a 16#0001 even though the network path is fine.
• S7-300 firmware on the very first release of a CPU MLFB. Early firmware releases for the CPU 315-2 PN/DP (6ES7 315-2EH14-0AB0) and the CPU 317-2 PN/DP (6ES7 317-2EK14-0AB0) had smaller connection tables than the current release. Updating to the latest firmware on the same MLFB enlarges the table without a hardware change.
• CP 343-1 Lean versus CP 343-1 Advanced. The Lean variant has a smaller connection table (typically 8 S7 connections) and does not support VLAN tagging. The Advanced variant supports up to 48 S7 connections and VLAN. Mixing the two on the same S7-300 with multiple S7-1500 partners can produce intermittent 16#0001 errors that look like network issues but are in fact connection table saturation on the Lean CP.
• Routing through a SCALANCE switch. If the S7-300 and S7-1500 are on different VLANs separated by a managed SCALANCE XC/XB/XR switch, the switch must allow the S7 protocol (TCP port 102) between the VLANs. A default-deny ACL on the switch will produce a 16#0001 that is invisible in the CPU diagnostics buffer but visible in the switch's Information > Security > Log Table.
• Time-out on the very first call. The first PUT/GET call after a CPU restart can return 16#0001 for one cycle while the S7 connection is being established. The instruction does not buffer the call. If the application code cannot tolerate a one-cycle glitch, wrap the call in a retry loop with a 100 ms wait between attempts.