CP 343-1 'Connection Partner Not Responding' on S7-300 Ethernet

Problem Overview

An S7-300 station built around a CPU 315-2 DP (6ES7 315-2AG10-0AB0, firmware V2.0.8) and a CP 343-1 (6ES7 343-1EX11-0XE0, firmware V2.3.5) programs and monitors cleanly over MPI. After switching the PG/PC interface to TCP/IP and disconnecting the MPI cable, the engineering station can ping the CP at 192.168.0.3, but STEP 7 V5.x reports "Connection could not be established. The connection partner is not responding" followed by "Unable to establish a connection to module CPU 315-2 DP (R0/S2)". The CP RX/TX LEDs flash as if S7 traffic is on the wire, yet the S7 routing handshake with the CPU over the backplane never completes. This is the classic CP 343-1 connection partner not responding symptom on S7-300 Ethernet commissioning.

The field-verified root cause is a stale STEP 7 project routing table. The online path the PG keeps trying is still bound to the MPI subnet, not the Ethernet subnet the CP 343-1 is sitting on. The fix is not a firmware upgrade, a cable swap, or a switch reconfiguration. It is a clean rebuild of the STEP 7 project with Ethernet as the only engineering subnet, plus a controlled download of the new hardware configuration so the CP 343-1 stores the IP, subnet mask, and gateway that match what the PG is actually going to use. The same path resolution rules apply in TIA Portal on S7-300/S7-400 stations that were migrated from STEP 7 V5.x.

Affected Hardware and Firmware Matrix

The exact catalog numbers from the source case and the variants you will most often see in the field are listed below. Pin the firmware column down before you start: a CP 343-1 with very old firmware may not support an S7 connection over TCP/IP the same way as a V2.x module, and it will produce Connection partner not responding for an entirely different reason (no S7 connection resource at all).

The Siemens Industry Online Support portal is the authoritative source for firmware upgrade packages and the S7-300 manual set. For the CP 343-1 family the most useful document is the CP 343-1 Manual (entry ID 24423172 on the Siemens support site), which documents the S7 connection resources and the meaning of the CP's diagnostic buffer entries. A second relevant Siemens Knowledge Base article on this exact symptom, PG operation with CP 343-1, is at Siemens Support entry 21873792.

CP 343-1 Variant Quick Reference

Connection count is the second most common reason "Connection partner not responding" appears after a project is rebuilt. The CP 343-1 Lean (EX11) reserves one S7 connection for "PG/OP communication." If the same CP is simultaneously being used by a configured S7 connection (PUT/GET) or by an HMI panel, the PG will be told no resource is free and the diagnostic buffer will record reason 0x01 / 0x03 / 0x0B depending on firmware. The symptom then looks identical to a routing failure.

Symptoms and Error Messages

The exact dialog text that STEP 7 V5.x shows in the source case is:

Connection could not be established.
The connection partner is not responding.

Unable to establish a connection to module CPU 315-2 DP (R0/S2)

When you click Accessible Nodes or PLC > Edit Ethernet Node, the CP 343-1 shows up in the browse list with the IP you configured (192.168.0.3), but selecting the CPU below it returns the same error. The CP itself responds to ICMP echo, so the issue is at the S7 protocol layer, not the IP layer. This combination - ping works, S7 connection fails - is the hallmark of the routing trap described in the next section.

Useful diagnostic signs to collect before you start changing anything:

• CP RX/TX LED: Flashing on TCP/IP activity confirms Ethernet is alive. If the LEDs are dark on the CP's RJ-45 jack, the link is down and you are not dealing with a routing problem; you are dealing with a physical-layer problem.
• ICMP ping: ping 192.168.0.3 -n 5 from the PG. Anything other than a 0% loss reply means the network path between PG and CP is fine.
• ARP table: Confirm the PG has the correct MAC for 192.168.0.3. If the CP is on a different subnet or behind a switch that filters gratuitous ARP, the PG can ping without a routing entry to the S7 target.
• Online > Accessible Nodes vs. resolved target: The browse will show the CP if the S7 protocol on the CP answers, but it will fail to descend to the CPU. The CP returns 0x01 in the diagnostic buffer with text "No PG/OP connection established" or similar, depending on firmware.
• Diagnostic buffer of the CP: Open in STEP 7 via CP 343-1 > Diagnostics > Diagnostic Buffer. Look for events tagged "S7 protocol error", "Connection abort", or "No resources" with a timestamp matching the failed download.

Root Cause - The MPI-Bound Routing Trap

STEP 7 V5.x stores online access information in three places, and they must agree:

1. The PG/PC interface in the Windows control panel (set to TCP/IP -> <your LAN card>).
2. The PG/PC assignment in the project in NetPro, which says which S7 subnet a "PG" station sits on.
3. The hardware configuration of the CPU and CP, which tells the project which subnets the CPU and CP are connected to and with what addresses.

If the project was originally created against an MPI TS Adapter (972-0CB20-0XA0), the PG/PC station in NetPro is placed on the MPI subnet, and the CPU's MPI interface in HW Config is the one that owns the project-wide "path to the CPU." When you later add the CP 343-1 to the rack and assign it to an Ethernet subnet, the project knows there is now an Ethernet path, but it does not automatically retarget the PG's online path from MPI to Ethernet. The PG station in NetPro is still drawn on the MPI bus.

The result is exactly what the source case shows. The PG tries to resolve the CPU using the path it has been told to use, which runs through the MPI subnet. The MPI cable is gone, the path is broken, and STEP 7 reports Connection partner not responding. Meanwhile the CP is right there on Ethernet, pinging happily and exchanging LED-confirmed traffic, but the PG's online path never reaches the CP because the project routing has not been told to use it.

Fig 1 - PG sees the CP on Ethernet (ping OK, Accessible Nodes finds it) but the project's online path still runs through the disconnected MPI subnet, so the directed request to CPU 315-2 DP fails.

How STEP 7 Stores the Online Path

The online path is stored in the project file OnlineParam.offline for offline projects and is rebuilt every time the project is opened. The relevant settings in SIMATIC Manager > Options > Set PG/PC Interface are:

If you set the PG/PC interface to TCP/IP and you still get the error, the project routing is the prime suspect. The fact that Accessible Nodes finds the CP while the directed download to "CPU 315-2 DP (R0/S2)" fails is the smoking gun.

Preconditions - Cable, Switch, and Subnet

Eliminate the trivial causes first. The source thread had at least one back-and-forth about the Ethernet cable pinout, and the cross-over vs. straight-through debate shows up in every S7-300 commissioning. A modern managed switch auto-MDI/MDIXes, so pinout is rarely the issue with current switches. With a direct PG-to-CP cable, an older NIC without auto-MDI/MDIX will need a cross-over cable. The T-568B straight-through pinout is the correct cable when one of the two devices is a switch port.

For the source case the cable was confirmed good (ping and LED activity are both positive), so the procedure below assumes the link layer is up. If your ping fails, stop and fix the link layer first.

Diagnostic Steps Before Rebuild

Run these in order. The first one to fail tells you where the real problem is. If all four pass, the routing trap described above is the only remaining cause.

Fig 2 - Diagnostic decision tree. Steps 1-4 isolate the physical, network, CP-protocol, and PG/PC layers. Step 5 is the routing fix described in the resolution section.

1. Link-up check. The CP's Link LED must be on solid and the CP's RX/TX LEDs should blink on traffic. If the link LED is dark, fix the cable or switch first.

2. ICMP ping. From a Windows command prompt on the PG:

   ping -n 5 192.168.0.3
   tracert 192.168.0.3
   arp -a | findstr 192.168.0.3
   

   You should see 0% loss and a single hop. arp -a should show the CP's MAC, which is printed on the front of the module.

3. CP diagnostic buffer. Open the project in STEP 7 V5.x, expand the S7-300 station, right-click the CP 343-1, choose Diagnostics > Diagnostic Buffer. The most recent entries should show the CP coming up, the S7 protocol starting, and the configured connections being offered. If the buffer is empty or only shows the boot events, the CP has been re-initialized but no S7 protocol traffic has reached it - this is consistent with the routing trap.

4. Accessible Nodes walk. SIMATIC Manager > PLC > Edit Ethernet Node (or PLC > Accessible Nodes if the interface is set to TCP/IP). The CP must appear with its IP and module name. If it does not, the S7 protocol on the CP is not running, and you have a different problem (firmware, CP mode, IP conflict on the network).

Step-by-Step Resolution - Rebuild the Project Ethernet-Only

The fix is a clean rebuild of the STEP 7 project with the CP 343-1 and the Ethernet subnet in the project before any S7 download. Do not attempt to "patch" the existing MPI-first project. The routing decisions stored in NetPro do not always re-evaluate cleanly when the project's only engineering subnet is changed.

1. Set the PG/PC Interface to TCP/IP First

Before opening SIMATIC Manager, set the access point:

1. Open Start > Control Panel > Set PG/PC Interface.
2. Select S7ONLINE (STEP 7) -> TCP/IP -> <your LAN card>. Do not leave it on TCP/IP -> Auto on multi-NIC laptops.
3. Click OK and let the "Set Interface" dialog warn you that other running STEP 7 applications need to be restarted.

2. Build a New Project Ethernet-First

1. In SIMATIC Manager, choose File > New Project and give it a name (for example CP343_Demo).
2. Right-click the project, choose Insert New Object > SIMATIC 300 Station. Name it to match the plant tag (e.g. PLC_315).
3. Open the station, then HW Config.
4. Insert a RACK-300 rail, then drop the PS 307 5A (or whatever the plant uses) into slot 1, the CPU 315-2 DP (6ES7 315-2AG10-0AB0) into slot 2, and the CP 343-1 (6ES7 343-1EX11-0XE0) into a free slot - slot 4 is conventional.
5. When you place the CPU, a dialog asks you to assign the MPI interface to an MPI subnet. Either create a new MPI(1) subnet with the CPU's default MPI address (here, address 2) or attach it to an existing one. The MPI subnet is still useful for other MPI devices, but it is no longer the engineering path.
6. When you place the CP 343-1, double-click the CP and open Properties > Ethernet Interface. Either create a new Ethernet subnet (e.g. Ethernet(1)) or attach to an existing one. Set the IP to 192.168.0.3 and the subnet mask to 255.255.255.0. The router field stays empty if there is no router.
7. Save and compile HW Config (Station > Save and Compile, Ctrl+S).

3. Place the PG/PC Station on the Ethernet Subnet in NetPro

This is the step the source case got right only after the rebuild - the PG/PC station has to be drawn on the Ethernet subnet, not on the MPI one.

1. Open NetPro from the S7-300 station object.
2. Right-click in the network area and choose Insert New Object > PG/PC Station. Use the default name or rename it to match the engineer's laptop name.
3. Open the PG/PC station's properties. Add an Ethernet interface with IP 192.168.0.2, subnet mask 255.255.255.0.
4. Add an MPI interface only if you still need MPI access later (for example, to reach another PLC). For the source case, MPI access is being decommissioned, so leave the MPI off the PG/PC station entirely. This is what makes the rebuild "Ethernet-only."
5. Draw an S7 connection from the PG/PC station to the CP 343-1. Right-click the PG/PC station, choose Insert New Connection. The dialog will offer a connection to the S7-300 station's CP 343-1; select it. Confirm the connection type is S7 Connection.
6. Save and compile NetPro. Any compile error here means the subnets and the PG/PC station are not in agreement, and the rebuild has not yet replaced the MPI-bound project.

4. Download the Hardware Configuration to the Station

You have two options for the first download. Pick the one that matches what is still plugged in.

• If the MPI cable is still attached: With PG/PC interface temporarily flipped back to PC Adapter (MPI), do the first download over MPI. After the CP's IP is in the CPU's system data, flip the interface back to TCP/IP for all further downloads.
• If the MPI cable is gone (source case): Use the PLC > Edit Ethernet Node dialog to assign the IP 192.168.0.3 to the CP via the Assign IP Address button. Then go to the S7-300 station in SIMATIC Manager and choose PLC > Download > Target System. The download dialog must show the target IP 192.168.0.3, not the old 192.168.0.1 from the previous project.

5. Re-Verify PG/PC Interface and Test

1. Re-check Set PG/PC Interface is on TCP/IP and the LAN card.
2. From SIMATIC Manager: PLC > Accessible Nodes. The CP 343-1 should appear at 192.168.0.3, and the CPU 315-2 DP should appear under it with the project name.
3. Open OB1, click the glasses icon to monitor online. The block should open with live values.
4. Open HW Config and choose PLC > Download to Target System. The download should complete without a dialog warning.

That is the working state. The source case reports exactly this: "I did not use the MPI adapter (only Ethernet) and it all worked."

Verification Checklist

Run this list after the rebuild to confirm a clean Ethernet-only online path. Each step has a measurable pass/fail condition.

Step 4 versus 5 is the tell. If 4 passes (CP shows up) and 5 fails (CPU does not appear under it), the project routing is still wrong even though the network is fine. Re-run the rebuild from step 2 of the resolution.

PG/PC Interface and Routing Re-check

There are three common post-rebuild landmines. All three look like routing failures on the surface but each is a different bug.

Landmine 1: TCP/IP <-> Auto

On some STEP 7 installs the access point shows TCP/IP -> Auto as the first entry. This is not a real interface; it is a probe that listens on every NIC and picks the first one that responds. If your laptop has both a Wi-Fi and an Ethernet card and the Wi-Fi is up first, Auto will route S7 traffic over Wi-Fi and fail when the plant WLAN does not forward TCP/102. Force the access point to the explicit LAN card.

Landmine 2: VirtualBox / Hyper-V virtual NICs

Engineering laptops that run PLC simulators often have virtual NICs from VirtualBox, Hyper-V, or VMware. The Auto entry above may bind to one of those and "find" a CP that lives only on the virtual subnet. Set the access point to the physical LAN card explicitly.

Landmine 3: Multiple CP 343-1 with the same default IP

A new CP 343-1 ships with IP 0.0.0.0. After a fresh download, some CPs accept a default IP if the project is built with that IP. If you have two stations in the plant both configured for 192.168.0.3, the second download will fail intermittently. Use the Edit Ethernet Node dialog to enumerate MAC addresses and IP assignments before connecting the second station.

Field-Proven Tips and Edge Cases

These are the gotchas the source thread and adjacent field cases surface. They are organized as a troubleshooting matrix you can run when the rebuild above does not immediately fix the symptom.

Related Diagnostic Buffer Entries

Open the CP 343-1's diagnostic buffer in STEP 7 to read the actual reason code. The codes below are reproduced from the CP 343-1 manual. They tell you whether the failure is on the CP side or the CPU side of the backplane. Always cross-check against the manual that ships with the firmware version installed on the CP - reason codes are stable across firmware but the textual description can vary.

The source case's failure mode is "Connection partner unreachable" (reason 4) from the PG's point of view, even though the network is fine. The reason is that the PG is asking the wrong subnet to do the lookup. Reason 4 in the CP 343-1's diagnostic buffer would be the smoking gun, but the source case never gets that far because the request never reaches the CP in the first place.

Security and Safety Notes

If the station is part of a safety-related circuit (F-CPU, F-I/O), do not perform any online operation that requires a stop of the CPU. The S7-300F family uses a separate PROFIsafe configuration that must remain consistent. Online over Ethernet against an F-CPU is supported by the CP 343-1 only with the right safety configuration in the project; do not assume that the same fix will apply to an F-station without involving the safety engineer.

Summary

The "Connection partner not responding" error on an S7-300 station with a CP 343-1 over Ethernet is almost always a STEP 7 project routing problem when the network is provably good (ping, LEDs, accessible nodes). The fix is to rebuild the STEP 7 project with the PG/PC station on the Ethernet subnet, not the MPI subnet, and to download the new system data so the CP stores the IP, subnet mask, and gateway the PG will actually use. The MPI cable is no longer the engineering path, the CP 343-1 is, and the project must reflect that. Once the rebuild is done, OB1 monitoring, hardware download, and any subsequent PG operations succeed over Ethernet without further work.

FAQ