Troubleshooting Bus Fault BF LED on Siemens CP 343-1 Lean

1. Problem Overview

The Bus Fault (BF) LED on a Siemens SIMATIC NET CP 343-1 Lean communications processor illuminates (steady or flashing red) whenever the module detects a fault on its Ethernet/PROFINET interface. A common field scenario that produces this condition is the presence of two CP 343-1 Lean modules that share an identical PROFINET device name but are configured with different IP addresses on the same physical network. Because PROFINET uses the device name as the primary station identifier on the network, a duplicate name prevents the controller (PLC) from resolving either device to a unique node, and the CP reports a bus fault even though basic ICMP ping tests may still succeed between the engineering station and each CP.

This article provides a complete diagnostic and resolution procedure for the BF condition on the CP 343-1 family, with special focus on duplicate device name conflicts, IP/subnet anomalies, MAC address duplicates, and STEP 7 / TIA Portal commissioning mistakes that produce the same symptom.

2. CP 343-1 Lean Hardware Reference

The CP 343-1 Lean is a slim-form-factor communications processor for the SIMATIC S7-300 PLC family, used to connect an S7-300 station to Industrial Ethernet / PROFINET. The CP 343-1 equipment manual (GH_CP343-1-EX30_76) documents the following relevant indicators and ports:

3. Reference Scenario: Two CP 343-1 Lean Modules with Identical Names

A field report describes the following configuration on a single Ethernet segment:

Both CPs respond to ICMP echo from a laptop on the same network. Despite reachability, the BF LED is active on at least one of the devices. Two anomalies are immediately visible:

1. Duplicate PROFINET device name — both modules declare the same station name cp-343-1-lean. PROFINET uses the device name as the unique node identifier (analogous to a host name); duplicate names are forbidden and trigger an alarm at the IO controller.
2. Non-standard subnet mask 255.240.0.0 — a 12-bit contiguous mask is legal in the IETF sense (RFC 950 allowed non-contiguous masks historically; RFC 4632 re-affirmed classless rules), but it is unusual on a Siemens PROFINET segment. Verify the mask matches the project definition exactly; a mismatch between configured and runtime subnet mask can prevent the IO controller from reaching the device even when the device itself is reachable from a laptop.

4. Root Cause Analysis

PROFINET IO uses the following identifiers, in order of priority:

1. PROFINET device name (the station name, e.g., cp-343-1-lean).
2. IP address (resolved through DCP or assigned statically).
3. MAC address (used during DCP discovery, never as the runtime identifier).

When two devices share the same name on the same broadcast domain, the DCP identify/response exchange becomes ambiguous. The IO controller logs an error similar to "Station failure / Duplicate station name detected". The affected CP then enters the bus-fault state because its AR (Application Relationship) to the controller cannot be established. The CP continues to respond to ARP and ICMP because the lower layers of the stack are still healthy — which is why a laptop can still ping both modules.

Additional root causes that surface with the same BF symptom include:

• Duplicate IP address on two different devices.
• Device name assigned to a device on the wrong subnet, so the controller cannot reach it after name resolution.
• CP not present in the STEP 7 / TIA Portal project (or wrong slot/GSD used).
• Replacement CP not yet re-assigned a device name after module swap (factory state).
• Switch port blocked by management, VLAN mismatch, or IGMP snooping stripping DCP multicast.
• LLDP disabled, blocking PROFINET neighbor discovery.

5. Diagnostic Procedure

Use the following ordered procedure to isolate the BF root cause on a CP 343-1 Lean:

5.1 Physical Layer Check

1. Inspect the LINK LED on the CP RJ45 jack. If off, replace the patch cable and verify the switch port is enabled.
2. Verify the switch port speed/duplex is forced to 100 Mbit/s full-duplex, or set to auto-negotiate. Do not force 10 Mbit/s on the CP port.
3. Confirm 24 VDC is present on the S7-300 rack and the DC5V LED on the CP is lit green.

5.2 Logical Layer Check

1. Open STEP 7 (V5.x) or TIA Portal and use Online > Accessible Nodes (STEP 7) or Online > Online & Diagnostics (TIA) to discover the CP on the network.
2. Note the device name, IP, MAC, and PROFINET device number reported for every node.
3. Compare the discovered list with the STEP 7 / TIA project. Any device appearing twice, or with a name that differs from the project, is a candidate for the fault.

5.3 Capture BF Diagnostics from the CP

In TIA Portal, with the project online, open the CP's Diagnostics view and read the PROFINET interface > Port statistics and the Diagnostic buffer of the S7-300 CPU. Typical entries when a name conflict is present:

• "Station failure" on the IO controller side.
• "DCP - identify response received from station with same name".
• "AR establishment failed: reason = name conflict".

5.4 Compare Project vs. Reality

6. Resolution Steps

6.1 Rename One of the Two CPs (the Primary Fix)

1. Decide a unique PROFINET device name for each CP. Recommended convention: <rack>.<slot>.<function>, e.g., rack0.slot4.cp3431lean and rack1.slot4.cp3431lean.
2. In STEP 7 (V5.x): PLC > Ethernet > Assign Internet Address / PROFINET device name. In TIA Portal: Online > Assign PROFINET device name.
3. Enter the unique name for the second CP, leaving the first unchanged. Click Assign name. The CP restarts the PROFINET stack and reattempts AR establishment with the IO controller.
4. Confirm the BF LED extinguishes within ~10 seconds and the CPU's diagnostic buffer no longer records station failure.

6.2 Reconcile Subnet Masks

1. Confirm the network design intent. For PROFINET, Siemens recommends 255.255.255.0 on a flat plant segment, or a routed subnet when crossing routers.
2. Update both CPs and the IO controller to the same subnet mask via the device configuration or via online assignment.
3. If 255.240.0.0 is required for backward compatibility with a legacy device, document it and ensure the controller's routing table agrees.

6.3 Resolve Duplicate IP Addresses

1. Use arp -a on a laptop to list IP-to-MAC bindings. If two IPs map to the same MAC or two MACs claim the same IP, a duplicate IP exists.
2. Identify the offending device (often a Windows PC, a router, or a second CP).
3. Reassign a free IP via the device's configuration interface or via STEP 7 / TIA Portal.

6.4 Assign a Name to a Replacement CP

A spare CP comes with an empty PROFINET device name. If it is plugged into a configured slot, the BF LED will illuminate because the controller cannot reach an unnamed device. To recover:

1. Open the STEP 7 / TIA project.
2. Right-click the CP in the project tree and choose Assign PROFINET device name.
3. Select the MAC of the new CP and assign the name as defined in the project.

6.5 Clear a Frozen BF State

If the BF remains after the cause is fixed, force a stack re-initialization:

1. Cycle power on the CP (pull and re-seat it from the S7-300 rack with the rack powered down).
2. Alternatively, trigger a STOP/RUN on the CPU so the IO controller re-issues ARs.

7. Verification

After the corrective action, verify the fix using all of the following checks:

• LED pattern: BF off, LINK on, RX/TX flashing during IO data exchange, DC5V steady green.
• STEP 7 / TIA online view: the CP appears in Accessible Nodes with the correct name, IP, and MAC; status field shows OK.
• CPU diagnostic buffer: no further Station failure or AR establishment entries.
• IO data test: use a watch table in STEP 7 / TIA to read a known input and write a known output through the CP. Confirm the value round-trips.
• Permanent ping: ping -t <ip> from the engineering station should show no loss over a 5-minute window.

8. PROFINET Naming and Identification Rules

9. Subnet and IP Sizing Reference

For a flat PROFINET segment of N devices, a single /24 (255.255.255.0) supports 254 usable hosts, which is more than enough for the typical machine. The 255.240.0.0 mask in the source scenario is a /12, supporting 1,048,574 usable hosts — far larger than needed and a sign that the mask may have been chosen by accident. Choose your mask as follows:

• Single machine, no router: 255.255.255.0, gateway field unused.
• Multi-machine, single plant segment: 255.255.255.0 with router only at the plant backbone.
• Large campus with VLANs: routed subnets, one /24 per cell, default gateway on each CP.

For the source case, if the intent is a single machine with two CPs, a /24 such as 10.1.41.0/24 with the two CPs at 10.1.41.11 and 10.1.41.12 is appropriate.

10. BF LED Behavior — Steady vs. Flashing

11. Common Pitfalls When Migrating from a Lab to the Plant

1. Cloning the project between machines — duplicate device names are inherited from the original project. Always rename when copying a STEP 7 project to a second S7-300 station.
2. Forgetting to download HW Config — the IO controller must have the CP in its configured slot before the CP can establish an AR. BF will persist until HW Config is downloaded to the CPU.
3. Switch management features — some managed switches block DCP multicast (LLDP, IGMP, DHCP) by default. Confirm DCP multicast group 01:0E:CF:00:00:00 is forwarded.
4. Replacing a CP without renaming — new CPs ship with an empty PROFINET name. Always re-assign the name after a swap.
5. Two engineering sources — STEP 7 V5.x and TIA Portal must not both be used to assign the same name; one will overwrite the other and the controller can be left in an inconsistent state.

12. Preventive Measures and Best Practices

• Maintain a PROFINET naming convention on the plant and enforce it in the project. Document the convention in the project README.
• Use IP and name allocation sheets during commissioning. Print and file a hard copy in the cabinet.
• Enable port security and DCP filtering on managed switches to prevent rogue devices from advertising conflicting names.
• Schedule annual diagnostic reviews: read the CPU diagnostic buffer and confirm no recurring BF / station-failure events.
• Keep a spare CP pre-configured with the plant's standard name template; rename only the suffix to slot/rack before deployment.
• Label every CP at the cabinet with its name, IP, and MAC. This is the fastest field fix when a duplicate slips through.

13. Escalation Path

If the BF persists after all the steps above:

1. Capture the CP's full diagnostic buffer (online > diagnostics > save as text).
2. Capture a Wireshark trace on the same switch port with a SPAN/mirror to the controller. Filter on dcp and pn-io to view name resolution traffic.
3. Open a Siemens support request at support.industry.siemens.com with the diagnostic buffer, project (exported as *.zip), and Wireshark capture attached.
4. Reference the equipment manual for the CP revision: CP 343-1 Equipment Manual (GH_CP343-1-EX30_76).

14. Frequently Asked Questions