Resolving CP343-1 Lean S7-300 Ethernet Connection Error 16#F9C1

Problem Summary

On a multi-cell machine network built around three SIMATIC S7-300 stations, each CPU uses a CP 343-1 Lean (Siemens part number 6GK7343-1CX10-0XE0) for Ethernet/IP-based S7 communication. After a working installation, one of the three PLCs is suddenly only able to maintain one active S7 connection out of the two configured partner connections. The CP's diagnostic buffer shows the second connection as "Not Set Up" and the related diagnostic event reads W#16#F9C1:0220. Ping tests to the remote partner succeed, so the physical link and the CP's basic IP stack are healthy. The fault is purely at the S7 connection / IP layer above Layer 3.

This is one of the most common S7-300 communication faults seen on brownfield S7-300 cells: a single cell drops one or more of its S7 partner connections while remaining reachable on the network, with the diagnostic buffer pointing at F9C1. The root cause is almost always one of the following, ranked by frequency:

1. Duplicate IPv4 address on the same Ethernet subnet (most common).
2. Mismatched or corrupted S7 connection configuration in NetPro/STEP 7.
3. CP firmware bug or CP that has been reset to factory defaults.
4. Switch port security, MAC filter, or managed-switch ACL rejecting the second MAC.
5. Partner CPU in STOP or partner CP removed/de-energised.

This article walks through the diagnostic path, the meaning of the event ID, and the exact procedure to isolate and fix the fault on a CP 343-1 Lean.

CP 343-1 Lean Hardware and Communication Architecture

The CP 343-1 Lean is the entry-level Ethernet CP for the S7-300 family. The variants in the field relevant to this fault are:

The CP occupies a single slot in the S7-300 rack and is configured as a separate station in the STEP 7 project. S7 connections are not owned by the CPU; they are owned by the CP, even though the CPU's program uses them via PUT/GET or BSEND/BRCV SFCs (SFC 30 / SFC 20, SFB 12 / SFB 13, etc.). This is why a successful ping test does not prove that S7 connections are healthy — ICMP echoes are answered by the CP's IP stack, but S7 connections are end-to-end CPU-to-CPU application relations over ISO-on-TCP (port 102) or TCP.

In the failing cell, the typical topology is:

PLC_A (CPU 315-2 DP + CP 343-1 Lean 192.168.0.10)
      |
      +--< Ethernet switch >--+-- PLC_B (192.168.0.11)   <-- connection 1: OK
      |                       |
      |                       +-- PLC_C (192.168.0.12)   <-- connection 2: "Not Set Up"
      |
      +-- Engineering station / server

The CP at PLC_A holds two S7 connections in NetPro, one to PLC_B and one to PLC_C. Connection 1 is "Established"; connection 2 is "Not Set Up" and the diagnostic buffer holds F9C1:0220.

Root Cause: Duplicate IP Address on Subnet

On the affected cell, both partner PLCs (B and C) were eventually found to share the same configured IPv4 address. The user confirmed: "the IP address configuration for both partner are same."

This is the classic IP-collision failure mode for the CP 343-1 Lean, and the reason it manifests as one working connection plus one failed connection is straightforward:

• The CP at PLC_A sends its ARP request before opening an S7 connection.
• ARP resolution returns whichever partner is reached first (e.g. the switch replies with the MAC of the most-recent responder on that IP).
• The first S7 connection that opens therefore "wins" the MAC of the conflicting partner; the second S7 connection either times out or terminates on a different host than expected.
• Because the CP is connected to the network through an unmanaged switch, the duplicate IP is not detected by any client; it only surfaces as a missing connection.

The CP 343-1 Lean has no built-in IP-conflict detection in firmware versions V2.x. Detection is delegated to the operator through LED patterns and diagnostic buffer events — which is why the diagnostic buffer is the first thing to check on a CP-only fault.

Decoding Event ID 16#F9C1:0220

The CP's diagnostic buffer (also called the "diagnostic list") is the canonical source of truth for CP-side connection faults. Event IDs in the W#16#F9xx range are CP343-1 Lean communication events. F9C1 is the connection-related sub-class.

For a full list, refer to the SIMATIC NET S7-300 CP 343-1 Lean Operating Instructions (Siemens manual A5E01274660), section "Diagnostics of the CP" — the diagnostic-event table lists the full F9xx range with byte-by-byte meanings.

For F9C1:0220 the standard remediation is to walk through the OSI layers upwards from the CP:

1. Verify the configured partner IP matches the partner CP's actual IP (do this on the partner CP, not the CPU).
2. Verify the partner CP is powered, has its LINK LED solid, and is bound to the same subnet mask.
3. Verify there is no duplicate IP on the subnet.
4. Verify the partner CPU is in RUN (S7 connections require the CPU, not the CP, to be in RUN for the partner side to accept a connection).
5. Verify the TSAPs on both ends match exactly. CP 343-1 Lean defaults to TSAP 01.01 for server connections and is freely configurable for client connections.

CP 343-1 Lean Diagnostic Buffer Interpretation

To read the diagnostic buffer in STEP 7 V5.x:

1. Open SIMATIC Manager > PLC > Diagnostics/Settings > Diagnostics Buffer on the CP (not the CPU). Right-click the CP node under the S7-300 station and choose CP Diagnostics > Diagnostic Buffer or use PG/PC > Diagnostics > Online with the CP's MPI/TCP address.
2. Read the most recent events. The first entry is the latest.
3. For each F9xx event, double-click to expand the byte fields. The lower 4 bytes identify the local and remote connection endpoint, the TSAPs, and the reason code.

Example diagnostic buffer content for the fault described in this article:

12:34:56.789  16#F9C1:0220  ERROR   CP    CONN_SETUP_FAIL
   Local  : CP   192.168.0.10    TSAP  01.01
   Remote : CP   192.168.0.12    TSAP  03.02
   Reason : no response from partner / timeout

To read the same buffer on the CPU (the CPU also logs the failure on the affected connection):

1. Open PLC > Diagnostics/Settings > Diagnostics Buffer on the CPU.
2. Look for events from class OB85 / OB86 / OB122 (connection-related) and from SFB / SFC errors (e.g. REQ=1, BUSY=1, ERROR=1, STATUS=W#16#81E1 from SFB 12 BSEND).

Cross-referencing the CP buffer with the CPU buffer is essential: a CP-side F9C1:0220 will often appear on the CPU side as a STATUS=81E1 on the SFC/SFB doing the send or fetch. The CP buffer tells you why the connection failed; the CPU buffer tells you which user program was affected.

Prerequisites for Troubleshooting

Before opening STEP 7, ensure the following are available:

• STEP 7 V5.5 SP4 (or later, up to V5.7) installed on the engineering station. TIA Portal V13+ can read CP 343-1 Lean stations as "unspecified S7-300" with limited diagnostics, but full event-ID decoding is best in STEP 7 V5.x.
• STEP 7 project archive (.zip or unzipped) for all three PLCs in the cell, dated to a known-good point in time. The project must include the NetPro view with the S7 connections.
• Online access to each CP via Ethernet (TCP) or MPI/Profibus if the CP's Ethernet port is unusable.
• IP address book (or the system commissioning sheet) listing every device on the cell's subnet, including the engineering station, the HMI, the cell server, and any third-party devices (vision systems, weighing terminals, etc.).
• A managed switch with port-mirroring capability (helpful but not required). Even an unmanaged switch with Wireshark on a tap will work.

Step-by-Step Diagnostic Procedure

1. Read the CP diagnostic buffer. Connect to the failing CP, read the diagnostic buffer, and record the first F9C1 entry. Note the partner IP, the local TSAP, the remote TSAP, and the reason code.
2. Read the CPU diagnostic buffer. Note any OB85/OB86/OB122 events and any SFB/SFC STATUS values from the connection-using blocks.
3. Check the connection status in NetPro. In STEP 7, right-click the failing S7 connection in NetPro and choose Connection Status (requires online). The status field will show Established, Not Set Up, or Disabled. Not Set Up confirms a connection setup failure, not a runtime abort.
4. List every device on the subnet. From the engineering station, ping the entire subnet (for /L %i in (1,1,254) do @ping -n 1 -w 100 192.168.0.%i > nul on Windows, or use nmap -sn 192.168.0.0/24 on Linux). Cross-reference the responses with the IP address book. Any IP that responds from a device that is not in the book is a duplicate-IP candidate.
5. Compare the partner CP's actual IP with the project's IP. For each partner (B and C), connect to its CP, read the Ethernet interface IP (Online > CP Diagnostics > Ethernet Interface, or STEP 7 Hardware Configuration > CP Properties), and compare it with the IP entered in NetPro for the partner. The two must match exactly. This is the most common reason for F9C1:0220.
6. Check for ARP collisions. On the engineering station, run arp -a twice with a 30-second gap. If the MAC address associated with a given IP changes between the two samples, two devices are responding to ARP for the same IP — this is the smoking gun for a duplicate.
7. Capture traffic on the failing connection. If the project allows it, mirror the switch port of the CP and run Wireshark with the filter tcp.port == 102. S7-300 uses ISO-on-TCP (RFC 1006) on TCP port 102. A healthy setup shows a CR (Connection Request) from the client CP, then CC (Connection Confirm). On a partner-not-reachable fault, the CR is sent repeatedly and the CP retransmits without ever receiving a CC.
8. Verify the partner CPU is in RUN. S7 connections are accepted by the partner CPU, not the partner CP. If the partner CPU is in STOP, the partner CP will reject the connection with reason code 0201 rather than 0220. If you see 0220, the CR is not even reaching a TCP listener, which strongly suggests an IP-stack problem (duplicate IP, wrong subnet, firewall).
9. Check the CP firmware version. Read the CP's diagnostic buffer for the firmware string. Firmware V2.0 has known issues with connection re-establishment after switch reboots; upgrade to V3.0 (file 6GK7343-1CX10-0XE0_V30.fwl, see Siemens firmware download portal entry 109744658) if the firmware is below V3.0.

Resolving Duplicate IP Conflicts

Once the duplicate IP has been identified, the correction is mechanical. Follow this sequence to avoid locking yourself out of the cell:

1. Document the current state. Print the diagnostic buffer of all three CPs, the CPU buffers, and a screenshot of NetPro's online connection status. This is your rollback point.
2. Identify the device whose IP is wrong. The "correct" device is the one whose IP matches the NetPro project for that station. The "wrong" device is the one whose IP has drifted (typically because an integrator re-used an IP from a different cell during commissioning, or because a default-firmware CP booted up with its pre-configured 192.168.0.x address). On the wrong device, note its MAC address (arp -a on the engineering station).
3. Power off the wrong device first. Bringing the wrong device down frees the IP for the correct one and makes the cell temporarily healthy again — this also confirms the diagnosis before any project change is made.
4. Re-assign the IP of the wrong device. Connect the wrong device to the engineering station on a separate subnet (e.g. direct cross-over cable with the PG on 192.168.1.x) and use STEP 7 Hardware Configuration to download the correct IP for that station. Verify with ping from the PG.
5. Reconnect the corrected device to the cell subnet. Power it up. From the engineering station, ping its new IP. Then watch the CP diagnostic buffer of the previously failing CP: the F9C1:0220 entry should be replaced by F9C1:0A01 (Connection Established) within 30-60 seconds.
6. Verify the application. Run the relevant blocks (SFB 8 / SFB 9 for PUT/GET-style data exchange; SFB 12 / SFB 13 for BSEND/BRCV). Check that the STATUS output is W#16#0000 on every call.

Verifying S7 Connections in NetPro / STEP 7

After the duplicate IP is removed, formally verify the S7 connections:

1. Open the STEP 7 project in NetPro.
2. Select PLC > Verify Project (icon with the green checkmark, or menu Options > Verify Project). STEP 7 will cross-check the project for connection, subnet, and TSAP consistency across all stations.
3. Right-click the previously failing S7 connection and choose Connection Status. The status should now read Established in the online view. The "Status of the S7 Connection" dialog also shows the connection's local and remote TSAP and the underlying transport (ISO-on-TCP or TCP).
4. Force a connection re-establishment by re-downloading the connection configuration. In NetPro, right-click the connection and choose Download Selected Connection to Target Station. This is non-destructive — STEP 7 will not delete connections that are not in the project; it will only update the selected one.
5. Cross-check by reading the CP diagnostic buffer again. The latest F9xx entry should be F9C1:0A01 (Connection Established). If you instead see F9C1:0220 repeating, there is a second instance of the same fault or a different root cause (e.g. a third device with a duplicate IP that was not caught in step 4 of the diagnostic procedure).

Preventive Measures and Network Hardening

Duplicate-IP faults on CP 343-1 Lean cells are avoidable. Apply the following in order of effort vs. payoff:

For high-availability cells, the documented cell Failure Mode and Effects Analysis (FMEA) should list "CP cannot reach all partners" as a failure mode with "duplicate partner IP" as a documented cause. The above countermeasures are the technical controls that close that risk.

Related Diagnostic Event IDs on CP 343-1 Lean

For the field engineer, the following event IDs are the ones that recur on S7-300 cells using CP 343-1 Lean. Keep this table as a quick reference:

For the full canonical list, see the CP 343-1 Lean Operating Instructions (Siemens A5E01274660). The same event ID range applies to CP 343-1, CP 343-1 Advanced, and CP 343-1 ERPC, so familiarity with this table is portable across the entire S7-300 Ethernet CP family.

Field-Proven Notes and Edge Cases

The following are conditions that look like a duplicate-IP fault but are not:

• Switch port security with sticky MAC. If the managed switch has port security enabled and the CP's MAC is bound to a port, a second device with a different MAC on the same port will be silently dropped. The symptom is identical to a duplicate IP from the perspective of the application — only the second connection is broken — but the cause is at L2, not L3. Always check the switch's show port-security output before blaming the PLC.
• Subnet mask mismatch. If the engineering station and one CP are on /24 (255.255.255.0) and another is on /23 (255.255.254.0), the /23 device will see a duplicate of any IP on the larger subnet. This is a common commissioning error on cells that were originally designed at /24 and later expanded.
• CP in a Profinet sub-module configuration (rare on Lean, common on the Advanced variant). If the CP's Profinet port is enabled and the IP is set on the Profinet interface while the Ethernet interface still holds the old IP, the two interfaces can ARP-conflict on the same subnet. Disable Profinet on the CP if it is not in use.
• Power-on delay of partner CP. After a power cycle, the partner CP takes 30-60 seconds to bring up its IP stack. If the local CP starts sending CRs before the partner CP's stack is up, the first connection setup will fail with F9C1:0220. The CP retries automatically; the entry clears after the partner is reachable. This is not a duplicate-IP fault, but it can be confused with one if the operator only looks at the buffer during the boot window.