S7-315-2PN/DP PUT/GET Connection Limits: Resource Type 03

S7-315-2PN/DP PUT/GET Connection Limits: Resource Type 03

The Siemens SIMATIC S7-300 CPU 315-2PN/DP (order number 6ES7315-2EH14-0AB0) remains a widely deployed controller in mid-range automation systems worldwide. One persistent commissioning question concerns the maximum number of one-way S7 connections—those used for PUT/GET data exchange—specifically those identified as connection resource type 03 in STEP 7 and TIA Portal. This reference documents the connection resource architecture of the S7-300 platform, the specific limit values for the CPU 315-2PN/DP, and the diagnostic steps required when configured one-way connections fail to come active even though free connection slots are still visible in the online diagnostics. The same principles apply to other S7-300 CPUs in the 31x family, but the absolute numbers differ; consult the device manual for your specific MLFB.

Connection Resource Architecture on the S7-300

The S7-300 CPU maintains a fixed pool of connection resources shared between every communication partner and protocol. The total number of resources is a hardware/firmware constant for each CPU model. For the S7-300 family, the absolute ceiling is 32 connection resources per CPU, but not every CPU exposes all 32. The S7-315-2PN/DP supports a maximum of 16 S7 connections simultaneously, which is the S7-connection cap, not the total connection-resource cap. The remainder of the 32-resource pool is consumed by internal services, CP-to-CPU backplane slots, and reserved channels that the firmware does not expose to user configuration.

Siemens subdivides the user-visible 16 connection resources into the following groups:

• PG connections (programming device) — 1 reserved by default, used for STEP 7 / TIA Portal online access
• OP connections (operator panel / HMI) — 1 reserved by default, used for WinCC flexible, TIA WinCC, and PROFINET panels
• S7 Basic Communication — uses the BSEND, BRCV, USEND, URCV function blocks (SFC 72/73/74/75) and SFC 67/68 for ad-hoc GET/PUT
• S7 Communication — uses PUT/GET (one-way, resource 03) and bi-directional S7 functions (resource 10 and above) over configured S7 connections

The number of connection resources reserved for S7 Communication—including one-way PUT/GET connections—is the variable that drives the symptom described in the original problem report. On the S7-315-2PN/DP, up to 14 connection resources may be allocated to S7 Communication when the project is compiled. The remaining 2 resources are distributed across the PG (1) and OP (1) defaults, with no slack left over for S7 Basic Communication once PG and OP are both in use.

Connection Resource Types in STEP 7 / TIA Portal

Each configured S7 connection in the STEP 7 NetPro / TIA Portal "Devices & Networks" editor is assigned a numeric connection resource ID. The most common IDs are:

Although PUT/GET can be carried over both resource type 03 and resource type 10+, type 03 is the canonical "one-way" connection that is initiated by a single partner and consumes only one local connection resource. Resource type 10 is a full two-way connection in which both partners maintain an active endpoint and can initiate PUT/GET calls in either direction. The choice between the two is not always obvious; the following matrix summarises the trade-offs.

Configuration Limits in STEP 7 and TIA Portal

Modern TIA Portal editors (V15 and later) and STEP 7 V5.x enforce a project-wide compilation warning when S7-connection counts exceed 64. From the official Siemens TIA Portal documentation:

If the user configures more than 64 S7-connections and SEND/RECEIVE connections, a warning appears during the compiling of the configuration. The warning ...

Source: Configuration limits in the connection configuration – TIA Portal V21.

This 64-connection warning is a project-wide soft limit; it does not block the download. The hard limit remains the per-CPU maximum specified in the device manual. For the S7-315-2PN/DP, the hard limit is 16 simultaneous S7 connections and 14 S7-communication resources. When planning a project that uses both S7-300 and S7-1500 stations, the warning threshold of 64 still applies to the project as a whole, even though no single S7-300 CPU can host that many connections.

Why Configured One-Way Connections Do Not Come Active

When the online diagnostics show "Not used" connection resources but a configured one-way (type 03) connection refuses to come active, the root cause is almost always one of the following conditions.

Cause 1: The S7-communication resource pool is exhausted

Although the connection overview shows free slots, those free slots may be reserved for the PG or OP channels. The CPU only allows 14 S7-communication connections to be opened at runtime; once that ceiling is hit, no new type-03 or type-10 connection will establish, even if the connection table is technically larger. This is the single most common cause of "free slots but no connection" symptoms on the S7-315-2PN/DP.

Cause 2: Type-03 collisions on the same local endpoint

A one-way connection (resource 03) is initiated from a single endpoint. If two different partners both try to register a type-03 connection to the same remote TSAP on the S7-315-2PN/DP, the second request will be rejected silently or with a connection-establishment error (0x80E0 – resource exhausted, or 0x80E1 – resource unavailable). The CPU does not display a useful alarm string for these errors in the diagnostic buffer; they appear only in the online connection list as "not used". To diagnose, check the online connection list on the partner PLC; if the same local ID is shown twice, a collision is in progress.

Cause 3: Rack/slot mismatch on the partner PLC

Type-03 connections store the partner's rack and slot. If the rack/slot parameters in the local project do not match the physical position of the partner CPU, the connection will compile and download but will never come active. The CPU 315-2PN/DP in a central rack is almost always at rack 0, slot 2. In a multi-CPU rack (S7-300 supports up to four CPUs in one central rack), slot 2 and slot 3 are the typical CPU positions. Verify the partner's slot in HW Config before troubleshooting anything else.

Cause 4: Asymmetric configuration on partner PLC

A type-03 connection is unidirectional, so the partner CPU does not strictly need a matching connection entry. However, the partner must permit PUT/GET access (see Cause 5). The partner side may also have its own type-03 connection pointing in the opposite direction, in which case the partner's connection table must include the local CPU as a remote endpoint. If the partner's NetPro does not contain the matching entry, the connection establishment may stall with a TSAP negotiation failure.

Cause 5: Security / access protection on the partner CPU

From CPU firmware V3.x onward, the S7-300 supports connection-level access protection. If the partner CPU has "PUT/GET access only" disabled (or a CPU password is in effect), one-way connections may be rejected even when the connection itself is correctly configured. Enable the "Permit access with PUT/GET" bit in the CPU properties (under Protection in TIA Portal, or in STEP 7 V5.x under CPU Properties > Protection > Operating Mode). Without this flag, the partner CPU silently drops incoming PUT/GET requests, and the local CPU shows the connection as "not used" without a useful diagnostic event.

Cause 6: IP address or subnet mismatch

The S7-315-2PN/DP has two PROFINET interfaces (X1 P1 and X1 P2) on the integrated PN port. If the configured IP address of the partner does not match the actual IP address, or if the subnet mask is wrong, the TCP connection will not establish. The connection list will show the entry as "not used" without an explicit error code. A simple ping from the engineering station to the partner's PN interface is the fastest first check.

Cause 7: Duplicate IP address on the network

If two devices on the same PROFINET subnet share an IP address, the duplicate-address detection (DAD) protocol will leave one device offline. The S7-315-2PN/DP performs DAD on power-up. A duplicate IP will manifest as "not used" connections, intermittent timeouts, and a non-green link LED on the affected port. Resolve with the network administration tools or a temporary disconnect of the suspected duplicate device.

Troubleshooting Matrix

Diagnostic Procedure

Follow this procedure when one-way (type-03) connections fail to establish on the S7-315-2PN/DP.

1. Open the S7 project in STEP 7 V5.x (or TIA Portal) and select the CPU 315-2PN/DP in the project tree.
2. Right-click > Target system > Online > Diagnostics (STEP 7 V5.x) or Online & diagnostics (TIA Portal).
3. Navigate to Communication > Connection overview and record the state of every configured connection: Not used, Active, Fault.
4. Count the Active connections against the per-CPU maximums:
   • 16 total S7 connections
   • 14 S7-communication connections (subset of 16)
5. Open the Diagnostic buffer of the CPU and filter for events with ID 0x4300 (connection status change) and 0x4301 (connection establishment failure). Note the associated event text and the local ID of the failing connection.
6. On the partner PLC, repeat steps 1–5. The two diagnostic buffers should mirror each other for type-03 connections. A buffer entry on the partner side confirms the request was received but rejected; an entry on the local side without a partner entry suggests a network-layer failure.
7. Cross-check the rack/slot of the partner CPU against the local NetPro entry: CPU 315-2PN/DP in slot 2 of rack 0 is the default. For multi-CPU racks, slot 2 or 3 is correct; slot 4 is reserved for the IM (interface module) and is never a CPU.
8. In the CPU properties, verify the "Permit access with PUT/GET from remote partner" checkbox is set under Protection > Connection mechanisms. The German STEP 7 dialog labels this as "Bitzugriff PUT/GET von entfernten Partnern zulassen".
9. Use ping from the engineering station to the partner's PROFINET interface to verify IP reachability. A successful ping rules out Layer-1 / Layer-2 issues.
10. If a free slot exists in the connection overview but the connection still fails, disable one of the active S7-communication connections, recompile, download, and re-test. The original problem is frequently resolved by this drop-one-and-retry method, which suggests a hidden resource exhaustion or stale configuration state.

Diagnostic Buffer Event ID Reference

The S7-300 diagnostic buffer is the authoritative source for connection-establishment events. The following IDs are most relevant to type-03 connection troubleshooting.

To filter the diagnostic buffer for these events in STEP 7 V5.x: open PLC > Diagnostic/Settings > Diagnostic Buffer, click Filter, and enter the hex value with a wildcard (e.g., 43*). The buffer will then display only connection-related events. In TIA Portal, the same filter is available under Online & diagnostics > Diagnostic buffer > Filter.

SFC and FB Call Examples for PUT/GET

Although the connection resource is configured in NetPro, the user program must still issue the PUT/GET calls. The relevant blocks for S7 Communication are the connection-oriented PUT (FB 15) and GET (FB 14) instructions; for S7 Basic Communication without a configured connection, the equivalent is SFC 67 (X_GET) and SFC 68 (X_PUT). The following STL snippets illustrate typical usage over a type-03 one-way connection with local ID 3.

PUT (FB 15) over connection ID 3:

// FB 15 "PUT" – write 20 bytes from local DB 100 to partner DB 200
CALL  "PUT" , "IOPUT"
  REQ    :=TRUE              // Rising edge triggers the PUT
  ID     :=3                 // Local connection ID (type 03)
  DONE   :=M100.0            // One scan TRUE on success
  ERROR  :=M100.1            // One scan TRUE on error
  STATUS :=MW102             // Return status (see below)
  ADDR_i :=P#DB200.DBX0.0 BYTE 20   // Partner target area
  ADDR_o :=P#DB100.DBX0.0 BYTE 20   // Local source area

GET (FB 14) over connection ID 3:

// FB 14 "GET" – read 20 bytes from partner DB 200 into local DB 100
CALL  "GET" , "IOGET"
  REQ    :=TRUE              // Rising edge triggers the GET
  ID     :=3                 // Local connection ID (type 03)
  DONE   :=M110.0            // One scan TRUE on success
  ERROR  :=M110.1            // One scan TRUE on error
  STATUS :=MW112             // Return status
  ADDR_i :=P#DB200.DBX0.0 BYTE 20   // Partner source area
  ADDR_o :=P#DB100.DBX0.0 BYTE 20   // Local destination area

Common STATUS return values for FB 14 / FB 15 over a configured S7 connection:

Connection Resource Allocation Reference

For quick reference, the resource allocation for a typical S7-315-2PN/DP project is shown below.

Source: CPU-CPU communications with Simatic controllers (Siemens Support, ID 78028908) and How are the communication resources assigned in the S7-300? (Siemens Support, ID 97649464).

Solution Walk-Through

Once the root cause is identified, the corrective action depends on the condition found.

Solution A: Free a S7-communication slot

1. In NetPro / Devices & Networks, select the failing one-way connection and note its local ID (typically the lowest free ID).
2. Deactivate an existing S7 connection that is not in use. Right-click > Connection resources > Deactivate (or temporarily delete the connection in NetPro).
3. Recompile HW Config / the device configuration and download to the CPU.
4. Re-establish the previously failing connection. Verify it appears as Active in the online connection overview.

Solution B: Enable PUT/GET access on the partner CPU

1. Open the partner CPU's hardware configuration (HW Config) in STEP 7 V5.x.
2. Open CPU Properties > Protection.
3. Check the box "Permit access with PUT/GET communication from remote partner" (German: "Bitzugriff PUT/GET von entfernten Partnern zulassen").
4. Recompile and download to the partner CPU.

Solution C: Migrate from type-03 to type-10

If the project must exceed the 14 S7-communication ceiling, convert the one-way type-03 connection into a two-way type-10 connection. This consumes one resource on each endpoint, so the trade-off is doubled slot usage in exchange for bi-directional capability and slightly different error-handling semantics.

1. In NetPro, right-click the S7-315-2PN/DP and select Insert New Connection.
2. Choose the partner CPU and select S7 connection.
3. In the connection properties, change the "Connection type" to Two-way. The resource ID will become 10 (or the next free ID).
4. Repeat on the partner side so both endpoints advertise a matching two-way connection.
5. Recompile and download both stations.

Solution D: Add a CP 343-1 to expand the connection pool

The S7-315-2PN/DP has an integrated PROFINET interface, but it also supports up to four CPs in the central rack. The CP 343-1 (MLFB 6GK7343-1EX30-0XE0) provides an additional pool of 16 S7 connections per module, fully independent of the integrated interface. If the 14 S7-communication ceiling on the integrated port is the binding constraint, install a CP 343-1 and route the additional PUT/GET connections through it. This is the only hardware-level solution that genuinely expands the connection resource pool without requiring a CPU migration to S7-1500.

Verification

After applying any of the above solutions, validate the fix with the following checks.

1. Open the online Connection overview on the S7-315-2PN/DP. The previously failing connection should display as Active with a green status indicator.
2. In the diagnostic buffer, no new entries with ID 0x4301, 0x4303, or 0x4306 should appear for the next 5 minutes of operation.
3. Trigger a PUT or GET from the partner PLC (e.g., from a VAT/watch table) and verify the data appears at the target DB on the S7-315-2PN/DP within the configured poll cycle (typical 100–500 ms for S7-communication PUT/GET over PROFINET).
4. Monitor the connection status periodically over a 24-hour soak test. S7-communication type-03 connections should remain stable; intermittent drops indicate a network or resource-exhaustion condition, not a configuration error.
5. On the partner PLC, check the DONE and ERROR outputs of FB 14 / FB 15. A persistently set ERROR flag with a non-zero STATUS confirms the partner is rejecting the request; check the partner's diagnostic buffer for protection events.

Comparison and Migration: S7-300 vs S7-400 vs S7-1500

Engineers familiar with the S7-400 or S7-1500 should note that the S7-300 has a significantly lower connection resource ceiling. The S7-400 (CPU 416-3 PN/DP) supports 64 S7 connections with up to 62 S7-communication slots. The S7-1500 (CPU 1515-2 PN) supports 128 S7 connections by default, with no PG/OP reservation. For projects that exceed 14 S7-communication connections, the most cost-effective path is to migrate the S7-300 CPU to an S7-1500 equivalent (e.g., ET 200SP CPU or S7-1512C), which lifts the S7-communication cap to 128 with no firmware-level workaround required.

For long-running S7-300 installations that have outgrown the 14 S7-communication ceiling, the migration to S7-1500 is straightforward with the TIA Portal migration tool. The S7-1500 supports the same PUT/GET FB 14 / FB 15 instructions, and the connection resource IDs follow the same scheme (type 03 for one-way, type 10 for two-way). The migration is largely a recompile-and-download operation once the S7-300 project is converted to TIA Portal format. Connection resource limits are not preserved across the migration; the S7-1500 defaults to its own (much higher) limits.

The S7-1500 also introduces the "Permit access with PUT/GET from remote partner (PLC, HMI, OPC, ...)" flag in a single, clearly labelled location, eliminating the multi-step Protection tab navigation required in S7-300. This reduces the probability of the "protection silently rejects PUT/GET" failure mode described in Cause 5.

Network and Performance Considerations

The S7-315-2PN/DP has a single PROFINET interface with an integrated 2-port switch. All S7 connections over the integrated interface share the same physical port, so traffic contention can affect PUT/GET latency. If the network also carries PROFINET IO (real-time) traffic, the S7-communication frames compete for bandwidth with PROFINET RT and IRT frames. Siemens recommends segregating S7-communication traffic onto a separate VLAN or onto a separate CP 343-1 if real-time performance is critical.

The integrated switch supports prioritised Ethernet (QoS, IEEE 802.1Q), but the S7-300 firmware does not expose the QoS configuration. For deterministic PUT/GET behaviour, an external managed switch with PROFINET QoS support is the recommended approach.

The user-program OB1 cycle time of the S7-315-2PN/DP is affected by the number of active S7 connections, but only marginally. Each PUT/GET call consumes 0.1–0.5 ms of OB1 time depending on data length and connection load. With 14 active connections, the incremental OB1 time is typically 1–5 ms, which is acceptable for most applications but may impact high-speed motion control loops. For applications where OB1 time is critical, route the PUT/GET calls through a cyclic OB (e.g., OB 35 at 100 ms) rather than OB1, and limit the number of active connections per cycle.

PUT/GET latency over the integrated PROFINET interface is typically 10–50 ms for a 100-byte payload, dominated by the PROFINET scan cycle and the OB1 execution time. For sub-10 ms latency, a CP 343-1 with the UPDATE job mode is required, but that is outside the scope of the type-03 one-way connection architecture.

Frequently Asked Questions