Siemens CP 343-1 Connection Partner Not Responding: Fix Guide

Problem Description: "Connection Partner Is Not Responding" (S7 Diagnostic Event 33:16656)

When commissioning or maintaining a SIMATIC S7-300 station fitted with a CP 343-1 communications processor, STEP 7 / SIMATIC Manager may display the diagnostic message:

Operating Mode (33:16656)
Online: Connection could not be established - the connection partner is not responding.

This event is generated by the S7 communication firmware when an active or passive ISO-on-TCP / TCP connection establishment request times out. The CP 343-1 transmits its ARP/TCP-SYN, the CPU's communication stack registers no reply within the configured keep-alive window, and the diagnostic buffer logs the event ID 33:16656 in the operating mode of the CPU. The message is not a CPU fault - it is a transport-layer time-out.

In practice this event almost always traces to one of three classes of fault:

1. Layer 1 fault: no physical link - cable, port, or transceiver fault, often revealed by a dark LINK LED on the CP 343-1.
2. Layer 3 fault: the PC's TCP/IP stack is bound to the wrong network adapter, or two adapters are fighting over the same /24 subnet.
3. Layer 7 fault: STEP 7's PG/PC interface does not point at the adapter that physically reaches the CP, so S7 online services never leave the PC.

The remainder of this article walks each layer in the order a field engineer should test it, using the CP 343-1 (order number 6GK7 343-1CX10-0XE0) and CP 343-1 Lean (6GK7 343-1EX30-0XE0) as the reference hardware. The diagnostic procedure also applies to the CP 343-1 Advanced (6GK7 343-1GX30-0XE0) and to all S7-300 CPU variants (31x, 31xC, 31xT, 31xF) with on-board PROFINET, because the failure mode is identical.

CP 343-1 Hardware Identification and LED Layout

Before touching any software setting, identify the exact CP variant and verify the port LEDs. The CP 343-1 family has two RJ-45 jacks on the front, each with a dedicated two-LED indicator stack:

A CP 343-1 Lean (6GK7 343-1EX30-0XE0) uses the same LED labels but does not support routing, clock synchronisation, or the PROFINET CBA role - relevant only if your project configuration tries to use those services.

Step 1: Hardware Layer Verification - LINK/FDX LEDs

The single most common cause of 33:16656 in green-field commissioning is a Layer-1 problem. Confirm the link before chasing IP settings.

1. Power up the S7-300 station; allow 30 s for the CP to finish its self-test and ARP scan.
2. Connect a known-good Cat 5e (or better) patch cable from the PC to the CP 343-1's left-hand RJ-45 jack (X1). For most CPs, X1 is the default PROFINET interface; X2 is reserved for switch cascading.
3. Observe the LINK LED on the CP. If it stays off, the PC's NIC is the suspect: try the cable in the PC's other RJ-45, try a different cable, then try a switch between PC and CP.
4. If the link comes up only when a switch is in the path, the suspect is auto-negotiation, not the cable. Modern CP 343-1 modules (firmware V2.x and later) and almost all PC NICs since 2010 implement Auto-MDI/MDIX, so a straight-through cable is electrically identical to a crossover. Very old CP 343-1 revisions (firmware V1.0, e.g. 6GK7 343-1CX10-0XE0 with MLFB suffix < 0AE0) may require a crossover cable or a switch when connecting directly to a NIC. Check the module's MLFB suffix against the Siemens Industry Online Support catalog to confirm.
5. Once the LINK LED is solid green, confirm FAST FDX is also lit. If only LINK is on and FAST FDX is off, the link has downshifted to 10 Mbit/s half duplex - replace the cable or the patch panel run; 10 Mbit HDX is not supported by PROFINET and will drop S7 connections under load.

Step 2: Multi-NIC and Windows IP Subnet Conflict Resolution

The most subtle source of 33:16656 is a Windows host with more than one network adapter. Modern Windows does not gracefully route between two adapters that share a subnet; the TCP/IP stack picks one and the other becomes a "black hole" for outgoing packets.

A typical laptop setup that triggers the failure:

Because both the Wi-Fi and the Ethernet NIC live in 192.168.0.0/24, the Windows routing table produces ambiguous next-hop decisions. ARPs go to the wrong MAC, S7-connection TCP-SYNs disappear, and STEP 7 reports 33:16656.

Resolution procedure

1. Open Control Panel > Network and Sharing Center > Change adapter settings (or run ncpa.cpl).
2. Disable any NIC you do not need for the engineering session. Right-click the Wi-Fi (or unused second Ethernet) and select Disable. Wait 10 s for the routing table to re-converge.
3. Re-enable the NIC only after STEP 7 has successfully connected to the CP. If the connection drops the moment the second NIC comes back, the IP configuration of that NIC is the culprit - move it to a different subnet, e.g. 192.168.1.50/24, so it cannot be mistaken for a PLC route.
4. Hard rule: every active NIC on an engineering PC must live in a different /24 (or finer) subnet. If you must keep both active, put the PLC engineering adapter in 192.168.1.0/24 and the internet adapter in 192.168.0.0/24 (or vice-versa). Never overlap.

Verifying the routing table

Open a command prompt and run:

route print -4

For a healthy engineering PC you should see exactly one interface route per subnet, with the CP 343-1's subnet (e.g. 192.168.0.0 255.255.255.0 On-link 192.168.0.1 ... Intel I219-V) and no other active interface in the same subnet. If two entries appear, disable one of them.

Step 3: PG/PC Interface Assignment in STEP 7

Even when the IP layer is correct, STEP 7 will not find the CP if the PG/PC interface is bound to the wrong adapter.

1. Open Start > Siemens Automation > Set PG/PC Interface (or run SetPgPcInterface.exe).
2. Set Access Point of the Application to S7ONLINE (STEP 7) --> TCP/IP <your Ethernet NIC>.
3. Confirm the chosen adapter is the one that just established the link. Run ipconfig /all in a second command window; the NIC with the 192.168.0.x address assigned to your engineering network must match the NIC selected in the PG/PC dialog.
4. Click Diagnostics in the Set PG/PC Interface dialog. A successful Read on the local adapter proves the driver layer is alive. A failure here points at a corrupt SetPgPc.Ini - close the tool, delete the file at %APPDATA%\Siemens\Automation\SetPgPc\SetPgPc.Ini, and re-open.

For TIA Portal (V14 and later) the same logic applies, but the path is Project > Online > Go online > PG/PC Interface type: TCP/IP > PG/PC Interface: <your NIC>. See the TIA Portal documentation for the corresponding Local/Partner connection configuration object, which defines the logical binding of two communication partners for S7 services.

Step 4: STEP 7 Online Access - Accessible Nodes

Use Accessible Nodes as the first live check, before any project download attempt.

1. In SIMATIC Manager, choose PLC > Edit Ethernet Node > Browse (or Target system > Ethernet > Browse in TIA).
2. STEP 7 broadcasts a DCP identify request on the bound adapter. The CP 343-1 replies with its MAC and IP. The station should appear in the list within 5 s.
3. If nothing appears, the problem is Layer 1/2 (cable, switch, or NIC), not STEP 7. Re-check the LINK LED.
4. If the station appears, double-click it. The IP/MAC editor opens - this is also where you can correct an IP that is out-of-range or duplicated on the subnet.

Step 5: Direct Cable, Auto-Crossover, and Switch Considerations

Auto-crossover (Auto-MDI/MDIX) is mandatory for any direct CP-to-PC connection without a switch. The CP 343-1 supports it on ports shipped with firmware V2.0 or later - the cut-in date for the family is around 2008. CP 343-1 modules with a single Ethernet controller (early EX10 and CX10) require a crossover cable or an intermediate switch when connected to a PC NIC that does not implement Auto-MDI/MDIX.

Verify by reading the module's firmware from the diagnostic buffer (Module Information > Diagnostic Buffer > Module startup). If the entry shows firmware V1.x, install a crossover cable or insert a switch. The physical-layer link is the only honest test of auto-crossover - the LEDs are the answer.

Step 6: Ping Test as the Connectivity Sanity Check

Once the LINK LED is steady, the next gate is a Layer-3 ping. A successful ping proves the IP stack and ARP are healthy; a time-out proves either a firewall or a wrong subnet.

C:\> ping 192.168.0.10

Pinging 192.168.0.10 with 32 bytes of data:
Reply from 192.168.0.10: bytes=32 time=1ms TTL=64
Reply from 192.168.0.10: bytes=32 time<1ms TTL=64
Reply from 192.168.0.10: bytes=32 time<1ms TTL=64
Reply from 192.168.0.10: bytes=32 time<1ms TTL=64

If the ping times out:

1. Disable the Windows Firewall temporarily (wf.msc > Windows Defender Firewall Properties > Off) and re-test. Re-enable after the test - S7-connection ports (TCP 102, TCP 161/162 for SNMP, UDP 34964 for PNIO) must be allowed through the firewall profile used on the engineering NIC. The Siemens SIMATIC Automation Tool installer normally opens these ports automatically; a manual install on a hardened PC may not.
2. Confirm both ends share the subnet. 192.168.0.1/24 and 192.168.0.100/24 are the same /24 - that is fine. 192.168.0.1/24 and 192.168.1.100/24 are not the same /24 and need a router to talk.
3. Check for a duplicate IP. If another device on the same /24 already has the CP's IP, both the ping and the S7 connection will fail with intermittent results. arp -a shows the MAC behind each IP - if the MAC for 192.168.0.10 is not the CP's MAC, change the CP's IP.

Step 7: CPU and CP 343-1 IP Address Configuration

The CP 343-1 takes its IP address from the SD-card project, the MPI/DP download, or a SIMATIC Manager Edit Ethernet Node assignment. For first commissioning, use the hardware path:

1. Open SIMATIC Manager with no project open.
2. PLC > Edit Ethernet Node > Browse - the station should appear (LINK LED proven).
3. Select the station, click Edit, and assign IP 192.168.0.10, subnet mask 255.255.255.0, leave router empty unless you actually have one.
4. Click Assign IP Configuration. The CP stores the address in its non-volatile memory and restarts its PROFINET stack - the BF LED will blink briefly during restart.

If the CP has an MPI/DP interface as well, the same IP can be assigned from the CPU's display (where fitted) via SETUP > PN > IP Address. This is the only path that works when the LINK LED is dead and STEP 7 cannot see the CP at all.

Step-by-Step Resolution Procedure (Field Card)

Use this ordered checklist on the next 33:16656 ticket. Stop at the first failing step and remediate before continuing.

1. LINK LED on CP 343-1 - if off, fix the cable, switch, or NIC first.
2. FAST FDX LED on - confirms 100 Mbit/s full duplex; replace cable if downshifted.
3. Single active NIC on PC, in the CP's subnet - disable every other NIC, or move them to non-overlapping subnets.
4. IP address reachable by ping - proves the stack and ARP.
5. Accessible Nodes finds the station - proves DCP and the PG/PC interface binding.
6. PG/PC interface points at the right NIC - Set PG/PC Interface > S7ONLINE > TCP/IP <your NIC>.
7. STEP 7 / TIA online connection succeeds - downloads the project; from here on, project download overwrites any temporary IP.

Verification and Commissioning

After completing the procedure, verify the fix end-to-end:

1. Open SIMATIC Manager with the engineering project. PLC > Accessible Nodes shows the CP at 192.168.0.10 within 5 s.
2. Select PLC > Download. STEP 7 negotiates a connection on TCP port 102; the diagnostic event 33:16656 must be absent from the new diagnostic buffer entry "Online connection established".
3. In TIA Portal, choose Go online from the project tree. The online state should turn green within 10 s for a small project.
4. Open the CP's web server (browse to http://192.168.0.10) - this is the cleanest end-to-end check, because the web server uses HTTP on TCP 80, completely independent of the S7 stack. If the web page appears, your IP and routing are proven correct and any remaining 33:16656 is a STEP 7 PG/PC binding problem, not a network problem.
5. Force an online diagnostic refresh (PLC > Diagnostic/Settings > Module Information > Diagnostic Buffer). The most recent entry should be the new "Go online" event, not a stale 33:16656.

Troubleshooting Matrix

Notes on S7-300 / CP 343-1 Connection Resources

CP 343-1 modules support a finite number of S7 connections. Hitting the limit is another common source of 33:16656 - the new connection request finds no free resource and is rejected, not "not responded to". The error code in that case is 33:16508 ("no resources free") rather than 33:16656, but field reports frequently conflate the two.

CPU 31x-2 PN/DP variants have their own connection resources for the on-board PROFINET interface. CPU 315-2 PN/DP supports 16 S7 connections, CPU 317-2 PN/DP supports 32. The total S7 connections used by the project (engineering + HMI + OPC + S7 routes) must fit inside both the CPU and the CP. Open NetPro in STEP 7 to audit.

Quick Reference: S7 Diagnostic Event Codes Encountered During CP 343-1 Bring-up

FAQ