Configuring Multiple S7 Connections to Remote PLCs in TIA Portal

Overview: S7 Connections to Remote PLCs in TIA Portal

The S7 communication protocol is the primary mechanism SIMATIC controllers use to exchange process data, exchange diagnostics, and coordinate distributed control logic. When a central PLC must read data from two or more remote PLCs, each remote partner requires its own dedicated S7 connection. The TIA Portal connection editor enforces this rule silently: a second remote partner is only made available after a fresh, uniquely identified S7 connection has been created in the project tree. Engineers who attempt to reuse the same connection block for a second IP address receive no error — the GET/PUT instruction simply does not bind, or the connection table refuses to add the duplicate.

This article consolidates the official Siemens connection-limit data for the S7-1200, S7-1500, S7-300, and S7-400 families and walks through the configuration steps that allow one CPU to read from multiple remote controllers using the GET and PUT instructions. The same procedure applies whether the remote partners are on the same PROFINET subnet, on different subnets bridged by a router, or reached through S7 routing across a PROFIBUS backbone.

For a quick reference on the routing limits that govern these scenarios, see the Siemens support article What is the maximum number of connections available for S7 routing with the S7-1500 CPU modules?

S7 Connection Types and Resource Accounting

An S7 connection is a logical, point-to-point channel between two S7 stations. It is not a TCP socket in the classical sense; rather, it is a managed resource on top of ISO-on-TCP (RFC 1006), TCP, or PROFIBUS-FDL. Every active S7 connection consumes one connection resource on each participating station, regardless of which side initiated the establishment. Connection resources are limited by the CPU type and are also consumed by CPs/CMs that the engineer adds to the station.

Siemens classifies S7 connections into four families that the connection editor exposes as separate configuration types:

• S7 connection — for SIMATIC-SIMATIC communication between two S7 CPUs (or between an S7 CPU and an S7-compatible HMI/SCADA).
• S7 routing connection — for traversing gateways and crossing PROFINET/PROFIBUS boundaries when the partners are not on the same logical subnet.
• HMI connection — automatically generated when a Panel/PC is added to the device tree; counted against the same resource pool.
• Programming/PG connection — established transiently by TIA Portal; not persistent, but it still borrows a resource for the duration of the online session.

The total number of available S7 connection resources is a property of the CPU firmware and is not freely scalable on the CPU itself. The only legal way to expand the budget is to add a CP (communications processor) or CM (communications module) to the S7-1500/S7-1200 station; each CP brings its own pool of connection resources. Per the TIA Portal documentation Configuration limits in the connection configuration, "The maximum number of resources for connections can be expanded by added CPs," and "S7-400: The used CPU defines the number of possible resources for S7 connections."

Connection Limits by CPU Family

The connection budget is the first constraint to verify. The table below summarises the maximum number of S7 connections (PG, HMI, S7, S7 routing combined, where applicable) for the most common S7-1200, S7-1500, S7-300, and S7-400 CPUs. Always cross-check the exact article number on the Siemens support portal because firmware revisions sometimes change the value.

S7-1200 Resource Profile

The S7-1200 is the most constrained family. A CPU 1214C DC/DC/DC with firmware V4.4 supports a maximum of eight S7 connection resources in total, and these are shared with PG (online), HMI, and S7 partner connections. If the project has one HMI panel and one engineering station online during commissioning, only six S7 partner resources remain for GET/PUT partners. When integrating two remote PLCs, the configuration works, but the engineer should avoid adding more than the budget allows.

The S7-1200 is also limited as an S7 router. It does not support S7 routing in the traditional sense; therefore, the central PLC must be on the same PROFINET subnet as the remote partners, or an external router such as a SCALANCE XC/xb must be inserted.

S7-1500 Resource Profile

S7-1500 CPUs are the recommended choice for multi-PLC aggregation because of the headroom they provide. A CPU 1516-3 PN/DP exposes 128 connection resources from the integrated PROFINET interface alone, and each CP 1543-1 added to the station contributes another 64. The 16 S7 routing connections are an architectural limit, not a per-interface one, so a single CPU can route 16 PROFINET-to-PROFINET partners and another 16 PROFINET-to-PROFIBUS partners — but never more than 16 simultaneous routed sessions in total.

From a practical standpoint, the typical bottleneck for an aggregation project is the IP/Subnet assignment, not the resource count. A CPU 1516 with a single HMI, a PG online, and eight remote partners uses 10 of 128 resources — only 8 % of the budget.

S7-300 and S7-400 Resource Profile

Legacy S7-300 and S7-400 CPUs follow the rule that the CPU itself defines the budget. A CPU 315-2 PN/DP supports 16 total connections; a CPU 416-3 PN/DP supports 64. Expansion requires CP 343-1 (S7-300) or CP 443-1 (S7-400) modules, each of which contributes its own connection pool. When aggregating remote S7-1200/S7-1500 stations from a central S7-400, the engineer should use the CPU's integrated PN interface first and reserve CPs for HMI and PG traffic to avoid contention on the backplane.

Prerequisites for Multi-PLC Configuration

Before opening the connection editor, verify the following. Each item maps to a common failure mode observed when adding a second remote PLC.

1. Subnets and IP plan. All three stations (local CPU, remote CPU #1, remote CPU #2) must be on the same logical subnet, or an explicit router must be inserted into the network view. Duplicate IP addresses — including the HMI — cause the connection editor to reject the partner silently.
2. Device firmware. Confirm the local and remote CPUs run a firmware version supported by your TIA Portal version. Mismatched TIA Portal versions can prevent the connection editor from exposing the partner interface, even though the underlying communication would work at runtime.
3. Connection-resource headroom. Cross-check the resource table in the previous section. Each remote partner consumes one resource on the local CPU, plus one on itself. If the budget is exhausted, the second connection cannot be established even if the editor accepts it.
4. Protection and PUT/GET access rights. On the remote CPUs, enable Permit access with PUT/GET communication from remote partner in Device configuration → Properties → Protection & Security. Without this flag, the GET instruction returns W#16#80E1 (object access error) or W#16#80B1 (illegal opcode), depending on the CPU generation.
5. Connection-mechanism choice. Decide between classic S7 GET/PUT (configured connections) and open communication (TSEND/TRCV with ad-hoc TCP). GET/PUT is recommended for point-to-point data exchange with two or three remote partners because each block binds to a single, statically configured connection.

Step-by-Step: Configuring Multiple GET/PUT Connections

The configuration that resolves the typical "TIA Portal doesn't let me add a second IP" symptom is structured as follows. The procedure assumes a central S7-1500 CPU and two remote S7-1500 partners, but the same steps apply to S7-1200, S7-300, and S7-400 stations.

Step 1 — Insert both remote CPUs in the project tree

In TIA Portal, open Project tree → Devices → Add new device and insert the central CPU. Then insert each remote CPU as an additional SIMATIC S7-1500 / S7-1200 / S7-300 / S7-400 station (not as an I-device — an I-device only exposes its own data; it is not an S7 server). Verify that each remote CPU is assigned an IP address on the PROFINET interface that belongs to the local CPU's subnet.

Step 2 — Create the S7 connections

Select the local CPU in the project tree, then open Properties → Communication → Connections. Click Add new connection and choose S7 connection. The partner dropdown will list every S7-1500/S7-1200 CPU in the project. Select the first remote CPU, assign a unique Connection ID (for example, 1), and click Apply.

Repeat the procedure for the second remote CPU. The connection editor assigns a fresh Connection ID automatically (often 2 or 3) and stores the relationship in the S7 connection_2 / S7 connection_3 data blocks. The key error pattern that causes the symptom in the original ticket is reusing the first connection block rather than adding a second one. Without a unique S7 connection object, the GET block has nowhere to bind and the IP address is rejected at compile time or at runtime.

Step 3 — Configure connection properties

For each created connection, open Properties → General → Connection mechanism and verify:

• Local interface: the PROFINET interface of the central CPU.
• Partner interface: the PROFINET interface of the remote CPU.
• Connection path: direct (same subnet) or via router/S7 routing.
• Connection ID: unique across all configured connections.

If the remote CPU sits on a different PROFINET subnet, the connection editor will offer a routing path. The path can include SCALANCE switches, IE/PB gateways, and CP modules. Maximum 16 S7 routing connections are supported, and only up to 16 of those may use PROFIBUS as the back-end, per the Siemens support article referenced above.

Step 4 — Insert GET/PUT blocks and assign IDs

From the Instructions → Communication → S7 communication palette, drop a GET (or PUT) block into OB1. For the first instance, set ID = 1 (matches the first connection). For the second instance, set ID = 2 (matches the second connection). Both instances reference different connection IDs; the underlying blocks automatically resolve the partner IP from the configured S7 connection.

// First GET block — reads from Remote_PLC_1 (Connection ID 1)
CALL GET_1, DB_GET_1
  REQ    := TRUE
  ID     := W#16#1              // matches S7 connection_1
  ADDR_1 := P#DB100.DBX0.0 BYTE 20
  RD_1   := P#DB200.DBX0.0 BYTE 20
  DONE   := "dbGet1.Done"
  BUSY   := "dbGet1.Busy"
  ERROR  := "dbGet1.Error"
  STATUS := "dbGet1.Status"

// Second GET block — reads from Remote_PLC_2 (Connection ID 2)
CALL GET_2, DB_GET_2
  REQ    := TRUE
  ID     := W#16#2              // matches S7 connection_2
  ADDR_1 := P#DB110.DBX0.0 BYTE 20
  RD_1   := P#DB210.DBX0.0 BYTE 20
  DONE   := "dbGet2.Done"
  BUSY   := "dbGet2.Busy"
  ERROR  := "dbGet2.Error"
  STATUS := "dbGet2.Status"

Compile the project. If the connection editor accepted both partners, the compile finishes without warnings related to unresolved connections.

Step 5 — Download to the central CPU

Download the hardware configuration and the program blocks. The S7 connection data blocks are downloaded implicitly as part of the system data. TIA Portal will warn if the remote partners are unreachable; this is normal when the project is downloaded before the remote CPUs are online, but it does not block the download to the local CPU.

Routing Considerations and Cross-Network Communication

When the two remote PLCs sit on a different PROFINET subnet than the central CPU, the connection must traverse a router. The TIA Portal connection editor allows you to define the routing path explicitly. The path consists of one or more gateways — SCALANCE XC/xb switches, IE/PB PN/PN couplers, or CP modules — and the engineer's responsibility is to ensure that the central CPU can route the S7 packet all the way to the partner's IP address.

Key limits to respect:

• 16 S7 routing connections max per S7-1500. This includes PROFINET-to-PROFINET and PROFINET-to-PROFIBUS. Aggregating 20 remote partners via S7 routing is not possible; switch to IP routing or distribute the load across multiple aggregating CPUs.
• Single S7 routing path per connection. A single S7 connection cannot simultaneously traverse two routing hops; for double-hop routing, plan intermediate S7 stations.
• Active partner configuration. The partner that initiates the connection is the active side; the receiver is passive. For GET/PUT initiated by the central CPU, the remote partner acts as server and the central CPU is the client.

For deeper guidance on S7-1500 routing limits, see the Siemens support article What is the maximum number of connections available for S7 routing with the S7-1500 CPU modules?

PUT/GET Access Rights and S7-1200 Specifics

The S7-1200 family requires the PUT/GET access right to be enabled on the partner CPU. This setting is per-CPU and applies to all S7 partners. The setting is found in Device view → Properties → Protection & Security → Connection mechanisms. Without the flag, the GET block returns W#16#80B1 (illegal opcode) and the partner CPU logs a security event.

From firmware V4.5 onward, Siemens added a per-connection access-list option that lets the engineer restrict specific partners by IP. Use this option in environments where the PLC is on a shared network with engineering laptops and external SCADA clients.

Common Errors and Their Resolution

The troubleshooting matrix below covers the most common failure modes encountered when adding a second remote PLC. Each row maps a symptom to a root cause and a concrete verification step.

Verification and Diagnostic Procedures

After the configuration is complete, perform the following verification sequence to confirm that both remote PLCs are reachable and that the central CPU is reading data correctly.

1. Online connection diagnostics. In TIA Portal, mark the central CPU, then Online → Online & diagnostics → Connections. The connection list should show both S7 connections in the Established state. Right-click any connection to view its statistics (send/receive counts, error counters).
2. Watch the GET STATUS word. With TIA Portal online, add the GET instances to a watch table. The STATUS word should settle on W#16#0000 after a successful read, and DONE should pulse high for one cycle on every successful transfer.
3. Inspect the remote CPU's diagnostic buffer. On the remote CPU, open Online & diagnostics → Diagnostic buffer. Each S7 connection establishment produces an entry; unexpected disconnections appear as well. The buffer is the most reliable way to identify which side terminated the connection and why.
4. Compare actual values to expected values. Force a known value into the remote DB and verify it appears in the central CPU's mirror DB after the next GET cycle. If the value is correct but jittery, increase the GET REQ period; if it is wrong, verify the ADDR_1 byte offset and length.
5. Run a sustained load test. Issue a REQ every 50 ms for one hour and monitor for any STATUS non-zero values. Sustained zero values across both partners confirm that the resource budget, routing, and access rights are all correctly configured.

Performance and Timing Considerations

The GET/PUT round-trip time on PROFINET is typically 10-30 ms per transfer, but it grows with payload size and with contention from other connections on the same CPU. When aggregating data from two remote PLCs, a common design pattern is to:

• Trigger the GETs from a cyclic OB (OB1 or OB30) at 100 ms, alternating between the two partners to avoid back-to-back load spikes.
• Use a 2-byte handshake (REQ + DONE) per partner to keep the data fresh without overloading the bus.
• For larger payloads (>200 bytes), split the transfer into multiple GET calls and use a sequence number to reorder at the consumer.

When the aggregate data rate exceeds 1,000 bytes/second, or when the number of remote partners exceeds eight, consider switching from GET/PUT to the Open User Communication blocks (TSEND/TRCV) with ad-hoc TCP connections, which have a lower per-call overhead on the S7-1500 firmware V2.5 and later.

Migration from Legacy STEP 7 to TIA Portal

Engineers migrating multi-PLC projects from STEP 7 V5.x to TIA Portal V13 or later commonly hit the same symptom: the legacy NETPRO connection table is converted, but the GET block still references a single, auto-generated connection ID, and the second remote partner fails to bind. The fix in TIA Portal is identical to the new-project procedure: open Properties → Communication → Connections, manually add the second S7 connection, and assign a fresh ID. The conversion does not always create one S7 connection per partner; the engineer must verify and, if necessary, create the missing connection. Refer to the TIA Portal help Configuration limits in the connection configuration for the maximum number of connections supported by your specific CPU firmware revision.

Security and Hardening Notes

Two field-proven hardening measures are often missed in multi-PLC aggregation projects:

• Disable unused S7 connection resources. If the local CPU has 128 resources but the project only uses 10, do not leave the remaining 118 reachable from the network. Use the access-list feature (S7-1500 firmware V2.6+) to restrict each connection to its known partner IP.
• Enable TLS for the central CPU's PROFINET interface. On S7-1500, the integrated PROFINET interface supports TLS for S7 communication. Even though ISO-on-TCP is not encrypted, wrapping the entire CPU-to-CPU traffic in a VPN tunnel is the standard Siemens recommendation for greenfield deployments.
• Audit the PUT/GET flag. The PUT/GET access right is global to the remote CPU. In security-sensitive projects, prefer the OPC UA server blocks (S7-1500 firmware V2.0+) over PUT/GET, because OPC UA exposes a per-node access control list.

Summary Checklist

• Confirmed the local CPU's S7 connection budget supports two additional remote partners.
• Verified that the two remote PLCs are inserted as full S7 stations (not I-devices) in the project tree.
• Created two distinct S7 connections in Properties → Communication → Connections, each with a unique Connection ID.
• Assigned the GET/PUT block ID parameter to the corresponding Connection ID.
• Enabled PUT/GET access on each remote CPU.
• Confirmed the routing path for any partner on a different subnet.
• Downloaded the configuration to the central CPU and verified both connections in the online diagnostics.
• Forced a known value in each remote DB and verified the read in the central CPU's mirror DB.

FAQ