Resolving the 'Remote Partner Is Not Responding' Error on Siemens S7 PG Routing

1. Problem Statement

A mixed-vintage Siemens S7 network consists of one S7-412 acting as a central station (gateway), with subordinate S7-400, S7-300, and S7-200 CPUs connected either directly on Industrial Ethernet (IE) or downstream on PROFIBUS DP from the gateway's PROFIBUS interface. Two Field PGs (Siemens Field PG M4 / M5 class programming devices running STEP 7 V5.4 or later) are in use:

• PG #1 — originally used to commission the project. Reads every CPU, online over both Ethernet and PROFIBUS.
• PG #2 — used to retrieve the archived STEP 7 project. It successfully opens the project offline and, when a PROFIBUS CP (PC adapter, USB, or MPI/DP) is attached, it can reach every node behind the gateway on the PROFIBUS leg.

The failure mode: as soon as PG #2 attempts to Go Online over the Ethernet interface, STEP 7 immediately returns the dialog:

Remote partner is not responding

No ARP resolution attempt, no connection timeout cycle, no broadcast. The error is raised at the transport-layer reachability check before any S7 connection (ISO-on-TCP / RFC 1006, port 102) is even attempted. The error is reproducible against the central S7-412 gateway and against every downstream node that should be reached through the gateway.

This symptom is the classic signature of a PG routing table mismatch: the IP address embedded in the gateway CPU's downloaded system data no longer matches the IP address currently assigned to PG #2's Ethernet interface.

2. Architecture Reference: How PG Routing Works in STEP 7

PG routing is a Siemens-specific mechanism in which a single CPU or communications processor (CP) acts as a router between two subnets (PROFIBUS, Industrial Ethernet, MPI). The router CPU is referred to as the gateway. STEP 7 builds the routing topology at project engineering time and compiles it into the system data (SDB) container of the gateway. Three tables are relevant:

The PG/PC assignment table is the piece that is silently breaking the second PG. When you originally commissioned the project on PG #1, STEP 7 wrote the IP address of PG #1 (e.g. 192.168.0.10) into the gateway CPU's SDB. After the project is archived and re-opened on PG #2, the STEP 7 project still contains PG #1's IP address as the "PG on Ethernet subnet." When PG #2's TCP/IP stack is configured with a different address (very common with DHCP — even when the lease looks stable), the gateway CPU's PG routing filter rejects the routing request. The error surfaces as "Remote partner is not responding" because the gateway CPU simply drops the connection setup frame at the routing layer.

Reference: Siemens — Configuring Hardware and Communication Connections STEP 7 V5.4 (Chapter 11.7 "Networking Stations that Represent Network Gateways").

3. Root Cause Analysis

The error appears only on PG #2 and only over Ethernet, which immediately rules out:

• Physical Ethernet cable / switch port failure — PG #1 would also fail.
• CPU fault (SF / BF LED) — PG #1 reaches every node successfully.
• PROFIBUS termination / repeater fault — only the Ethernet path is affected.
• STEP 7 project corruption — the same archived project opens on PG #1 without issue (or PG #1 still has its own local copy).

What remains is a configuration or addressing mismatch. Ranked by observed frequency in field reports:

4. Prerequisites for the Fix

• STEP 7 V5.4 SP5 or later (V5.5 / V5.6 also supported; the SDB layout is identical for S7-400/300 routing).
• Administrative rights on PG #2 (to change IP, modify firewall, run Set PG/PC Interface).
• Read access to the original archived project (the one that was downloaded to the gateway CPU originally).
• If system data must be re-downloaded: a working PROFIBUS or Ethernet path to the gateway CPU. PROFIBUS via the PC adapter (USB or MPI/DP) is the lowest-risk path because it bypasses the routing problem.
• Optional: a temporary static IP assignment for PG #2 (disable the DHCP client on the Ethernet NIC while you are troubleshooting).

5. Step-by-Step Resolution

5.1 Confirm the Symptom Boundary

1. On PG #2, open a command prompt and execute:

   ipconfig /all
   ping <gateway_cpu_ethernet_ip>
   ping <downstream_ethernet_cpu_ip>
   tracert <downstream_ethernet_cpu_ip>

2. Verify that the gateway CPU and every Ethernet-attached downstream CPU respond to ping from PG #2. This confirms the IP layer is intact and isolates the failure to the ISO transport (port 102) and the S7 routing filter.
3. Run STEP 7's Set PG/PC Interface (Start → SIMATIC → STEP 7 → Set PG/PC Interface) and confirm that the active access point is bound to PG #2's Ethernet NIC, not to a virtual adapter or to a Wi-Fi interface.

5.2 Identify the Authoritative PG IP in the Project

1. Open the archived STEP 7 project in SIMATIC Manager on PG #2.
2. In the project tree, locate the PG/PC station object (typically named after the original PG, e.g. FIELDPG_01).
3. Open HW Config for that PG/PC station. The Ethernet interface IP and subnet mask shown there are the values that were compiled into the gateway CPU's PG/PC assignment table when the project was downloaded originally.
4. Record: AUTHORITATIVE_IP, AUTHORITATIVE_MASK, and the gateway CPU's Ethernet interface GATEWAY_IP.

5.3 Apply the Quickest Fix (Path A — No Re-Download)

If the archive and the running plant permit a one-time change of PG #2's IP address:

1. Open Network and Sharing Center → Change adapter settings on PG #2.
2. Disable the DHCP client on the Ethernet NIC (or set the NIC to a static address).
3. Assign PG #2 the IP address AUTHORITATIVE_IP with mask AUTHORITATIVE_MASK, and the gateway CPU's IP as the default gateway.
4. Reopen SIMATIC Manager, choose Accessible Nodes over the Ethernet access point. The gateway CPU and every routed node should now appear.
5. Open the project and Go Online. The "Remote partner is not responding" dialog should no longer appear.

This path is non-invasive: it touches the PG only, requires no PLC downtime, and is the right answer when the network DHCP server is assigning the wrong range or when a different PG once used the authoritative IP.

5.4 Apply the Permanent Fix (Path B — Re-Download System Data)

If PG #2's IP must remain as it is (for example, it is on a managed DHCP range that cannot be locally overridden), the gateway CPU's PG/PC assignment table must be updated. This requires a download of system data to the gateway CPU.

1. On PG #2, open the STEP 7 project offline.
2. Insert a new PG/PC station if one is missing: Insert → Station → SIMATIC PC Station. Rename it to reflect PG #2 (e.g. FIELDPG_02).
3. Open HW Config on the new station. Add an IE General or CP 1613 / CP 1623 / Softnet IE module whose IP and subnet match PG #2's current NIC settings. Do not reuse the original PG's IP.
4. Assign the new PG/PC station to the same Industrial Ethernet subnet the gateway CPU is on (drag and drop in NetPro, or use the subnet properties dialog).
5. Open NetPro and verify that there is a routing entry from the gateway CPU to the new PG/PC station. Save and compile the project (Station → Consistency Check → Compile).
6. Establish a working online path to the gateway CPU. The simplest is via PROFIBUS using the PC adapter on PG #2's MPI/DP port, since Ethernet routing is the failure mode being addressed.
7. Select the gateway CPU in the project, then PLC → Download to Station. STEP 7 will identify the delta in SDBs and prompt to overwrite system data.
8. Accept the download. The gateway CPU performs an SDB update (typically a short stop of routing; the user program is not stopped on S7-400 with RUN-mode SDB updates, but the S7-300 will briefly enter STOP if the SDB affects central I/O — gateway-only SDBs usually run without STOP).
9. After the CPU returns to RUN, wait one routing cycle (about 10–30 s) and retry the Ethernet Go Online from PG #2.

5.5 Firewall and Multi-NIC Remediation

On PG #2, even with the correct IP assigned, Windows firewall or routing-table interference will reproduce the same error.

1. Open Windows Defender Firewall with Advanced Security.
2. Add inbound rules for:
   - TCP port 102 (ISO-on-TCP / RFC 1006) — used by S7 communication.
   - UDP port 161 (SNMP) — used by SIMATIC diagnostics, optional.
   - The STEP 7 executables: S7WUIEX.EXE, S7ASIAV.EXE, CCAgent.exe (where installed).
3. If PG #2 has both Wi-Fi and Ethernet active, disable Wi-Fi during the session or use Set PG/PC Interface to bind STEP 7 exclusively to the Ethernet NIC.
4. Confirm the active route to the gateway subnet is via the Ethernet NIC:

   route print
   

   If the route to 192.168.0.0/24 (example) shows a higher metric on the Ethernet interface than on Wi-Fi, delete the Wi-Fi route for that destination or raise its metric.

6. Verification

After applying Path A or Path B, validate the fix end to end:

1. Accessible Nodes test: In SIMATIC Manager, choose PLC → Accessible Nodes with the Ethernet access point. Every CPU on the Ethernet subnet, including the gateway, must appear in the list.
2. Direct Go Online: Select the gateway CPU in the project and click Go Online. The online view must open, and the project must compare equal to the offline program blocks (no SDB diff at the gateway level).
3. Routed Go Online: Select a downstream S7-300 on PROFIBUS. Right-click → Go Online. The connection must establish through the gateway; the online diagnostics must show the path as Ethernet → Gateway CPU → PROFIBUS in the Online → Diagnostics → Module Information screen.
4. S7-200 over Ethernet: If the network includes an S7-200 reached via an Ethernet-to-MPI/PPI converter (e.g. S7-200 EM 243 or third-party X-PBC), confirm the routing chain works: PG → Ethernet → Gateway → PROFIBUS → S7-200.
5. Routing diagnostic buffer: On the gateway CPU, open PLC → Diagnostics/Settings → Diagnostic Buffer. Look for entries of class "Communication error" with ID 0x03A1 or 0x03A2. These should be absent after the fix. If they reappear when only PG #2 is online, the routing table update did not take; repeat Path B.

7. CPU and CP Reference

Reference manuals:

• S7-400 Automation System, Module Data
• CP 443-1 Manual
• S7-300 CPU 31x Technical Data
• S7-200 Programmable Controller System Manual

8. Diagnostic Event IDs in the Gateway CPU

When PG routing fails, the gateway CPU writes entries to its diagnostic buffer. Interpret them as follows:

Reading the diagnostic buffer is done with STEP 7's PLC → Diagnostics/Settings → Diagnostic Buffer. For S7-400, the buffer is persistent across power cycles; for S7-300 it is volatile.

9. Alternative Access Strategies

If the Ethernet routing path cannot be restored quickly, the following temporary access methods work in parallel with the troubleshooting:

• PROFIBUS PC adapter (USB or MPI/DP): Attaches to PG #2's USB port and connects to the gateway's PROFIBUS segment. STEP 7's Accessible Nodes over the PROFIBUS access point will list the gateway and all PROFIBUS-attached nodes. This is the fastest fallback and is unaffected by the routing filter.
• Direct MPI connection: For S7-400 CPUs with an MPI port, the PC adapter at MPI/DP can connect at 187.5 kbps directly to the CPU without going through the Ethernet CP. This is useful for downloading SDBs in Path B when the Ethernet path is broken.
• Telnet / Web diagnostics of CP 443-1: Modern CP 443-1 variants (firmware V3.x and later) expose a web interface. Browse to https://<cp_ip> for link status, port statistics, and active connection list. This is read-only and does not bypass routing, but it confirms the CP itself is alive and not in a faulted state.
• Remote access via WAN/VPN: When the field network is reached over a corporate VPN, an industrial router or remote-maintenance module (e.g. SINEMA RC, SCALANCE M) can be deployed. See HMS Networks — PLC Communication and Remote Access for an overview of vendor-neutral remote-access topologies.

10. Preventive Measures and Best Practices

1. Centralize PG IP allocation. Maintain a project register that lists every PG/PC station and its IP. Treat the PG/PC assignment table in each gateway CPU as part of the controlled documentation; changes require a controlled SDB download.
2. Use static IPs on engineering stations. DHCP leases are the most common cause of "PG routing was working yesterday" failures. Configure Field PGs with static addresses and document them in the project.
3. Lock the STEP 7 project PG/PC station list. When a project is archived, validate that the PG/PC station count matches the number of engineering devices that will ever need to route through the gateway. Add placeholder PG/PC stations for known engineering laptops before commissioning.
4. Test routing paths from every engineering station at commissioning. A simple matrix test (one row per PG, one column per subnet, success/fail) catches routing gaps before a future PG is added.
5. Keep firmware current on CP 443-1. Siemens has published multiple PG routing and PROFINET-related fixes in CP 443-1 firmware; review release notes before commissioning a new CPU. See the CP 443-1 firmware history on Siemens Industry Online Support.
6. Document the routing topology in the plant electrical drawing set. Include a routing table that lists the gateway CPU, the subnets it bridges, and the PG/PC stations allowed on each subnet. This becomes the reference during future troubleshooting.

11. Frequently Asked Questions