CP 343-1 Lean: Resolving the 500ms Update Bottleneck on S7-300

The CP 343-1 Lean communications processor (Siemens order number 6GK7 343-1CX10-0XE0) is widely deployed as a low-cost Ethernet attachment for S7-300 stations. Field reports, however, repeatedly surface one specific failure mode: cyclic data exchange from a supervisory system such as iba PDA, WinCC, or a custom OPC client plateaus at 300–500 ms even when the LAN itself is empty 100 Mbit/s infrastructure. The cause is not the Ethernet cable, the switch, or the SCADA driver — it is the serial S7-300 backplane channel that connects the CPU to the CP, which is fixed at 187.5 kbit/s. This reference explains why that limit exists, how to prove it in the field, and what hardware/software changes actually move the update time below 100 ms.

1. Problem Description

A typical configuration that exhibits the symptom:

• CPU: 6ES7 315-2AG10-0AB0 (CPU 315-2DP) or any non-PN CPU in the S7-300 family.
• Communications processor: 6GK7 343-1CX10-0XE0 (CP 343-1 Lean) seated in slot 4 of the rack.
• Supervisory system: iba PDA client requesting process values at a configured update time of 100 ms but receiving them at 500 ms.
• Physical LAN: 100 Mbit/s industrial switch, Cat 5e, RJ45.
• Observed anomaly: a digital input that toggles every 70 ms is captured only every 500 ms; analog values visibly lag.

The user expectation, formed by reading the CP 343-1 Lean datasheet, is that Ethernet bandwidth should govern the throughput. Because the LAN is essentially idle and the PC driver reports no errors, the symptom is misdiagnosed as a polling-rate problem on the SCADA side, an FB call that is too slow, or an OB1 priority issue. None of these address the real constraint.

2. Root Cause: The 187.5 kbit/s Backplane Bus

Inside an S7-300 rack, the CPU and every CP communicate over a serial backplane that is proprietary to the S7-300 platform. The signaling rate is fixed by the CPU's backplane controller and is documented in the S7-300 automation system manual at 187.5 kbit/s. The CP 343-1 Lean has no parallel path to the CPU's process image; every byte — every PUT/GET, every S7 communication frame, every diagnostic request — must traverse that 187.5 kbit/s channel twice (request + acknowledgement).

Useful throughput after protocol overhead is roughly 20–25 kByte/s. At that rate, exchanging a typical 200-byte PDU in S7 communication mode requires about 16 ms of pure backplane time. With multiple subscribed clients (iba, WinCC, plus a programming terminal), 500 ms cycle times are not surprising — they are the expected outcome.

3. CP 343-1 Lean Key Specifications

The following table summarizes the parameters most relevant to data-acquisition throughput. Values are taken from the Siemens CP 343-1 Lean manual (CP 343-1 Lean manual, edition 06/2015) and the S7-300 module data manual.

Two facts in this table govern the troubleshooting outcome:

1. The backplane rate of 187.5 kbit/s is the binding limit. No configuration change — connection resourcing, PG/OP routing, or FB choice — will raise it.
2. The Lean variant is not a PROFINET IO controller. It can act only as PROFINET IO Device on a subset of slot types and cannot substitute for the CPU's own PROFINET interface when cyclic I/O update is required.

4. Confirming the Bottleneck in the Field

Before changing hardware, prove the diagnosis with measurements. Three independent methods give consistent results.

4.1 CP Diagnostic Buffer and Statistics

Open the CP in STEP 7 / TIA online, select Diagnostics > Buffer, and read the CP's communication-statistics block. Look for:

• Backplane utilization counter rising above 70 % during normal cyclic traffic.
• Rejected connection attempts with error code 0x8001 (resource bottleneck on CP).
• Time-stamped entries showing PUT/GET round-trips > 100 ms on a 100 Mbit/s LAN.

4.2 Wire-Trace Round-Trip Test

Capture a TCP stream on the switch port using Wireshark or a managed switch's mirrored port. Time the delta between a PUT request and its ACK from the CP. With an empty LAN, a 200-byte S7 PDU typically returns in:

• 8–12 ms when the CPU has its own PROFINET interface.
• 40–120 ms when the CP 343-1 Lean is in the path.

If the round-trip is > 30 ms on an otherwise quiet network, the backplane is the cause.

4.3 OB1 Cycle and FC/FB Loopback Test

Insert a self-triggered PUT/GET pair into OB1 and instrument it with the system clock SFC64 (TIME_TCK). Measure t1 = TIME_TCK before, t2 = TIME_TCK after. If the program itself completes in < 5 ms but the supervisory client still sees 500 ms, the delay is external — on the backplane or on the LAN — and not in the application code.

5. Solution Paths, Ranked by Cost/Disruption

5.1 Path A — Use the CPU's Integrated PROFINET Interface (Recommended)

If the station contains a CPU 31x PN/DP (for example 6ES7 315-2EH14-0AB0 or 6ES7 317-2EK14-0AB0) the cleanest fix is to remove the CP 343-1 Lean entirely and let the supervisory system talk directly to the CPU's built-in PROFINET port. The integrated interface operates at 10/100 Mbit/s and terminates directly on the CPU core — there is no intermediate 187.5 kbit/s bus.

Procedure:

1. Identify the CPU MLFB. Only CPUs with "PN" in the designation have an integrated PROFINET interface. The 315-2AG10 (CPU 315-2DP) has only MPI/DP and must be replaced.
2. Configure the integrated PN interface in STEP 7 / TIA with the same IP address previously assigned to the CP 343-1 Lean so that no firewall rule changes on the supervisory host are required.
3. Enable Permit PUT/GET access on the CPU's protection settings (this option is required for S7 communication initiated by the SCADA driver).
4. Update the SCADA driver connection from the CP's IP to the CPU's IP. For iba PDA, edit the S7-TCP node.
5. Remove the CP 343-1 Lean from the hardware configuration and download the project.
6. Power down, remove the CP, and restart.

Expected result: update time drops to 5–25 ms per cycle, depending on OB1 priority and PDU size. This is the dominant recommendation in the Siemens CP 343-1 Lean manual's Application section: the CP is intended for stations where the CPU has no PROFINET port of its own.

5.2 Path B — Keep CP 343-1 Lean but Reduce Traffic

If hardware replacement is impossible (no spare CPU, plant in operation, certification locked), the existing CP can be tuned to within 100–150 ms by reducing the volume of data on the 187.5 kbit/s bus:

• Combine polled items into a single contiguous data block on the CPU and read once per cycle, rather than issuing many small PUT/GET calls.
• Disable Web diagnostics if enabled; each HTTP request consumes backplane time.
• Disable unused connections in the CP's connection table. Each configured-but-idle connection still consumes keep-alive bandwidth.
• Raise OB1 priority for the communication FB only if it is currently running in OB100 / OB1 of low priority; however, this rarely helps because the bottleneck is on the CP side, not the CPU.

These tuning steps bring the update time from 500 ms to roughly 150–200 ms but cannot reach the 10 ms class achievable with Path A.

5.3 Path C — Migrate Data Acquisition to PROFIBUS DP

The original poster asked whether to use the CPU's PROFIBUS DP port instead of the CP 343-1 Lean. The DP port on a CPU 315-2DP is also bound to the same backplane bus, so the throughput ceiling is identical. The only difference is that DP runs at 12 Mbit/s on the external side and uses deterministic cyclic I/O — useful when iba or the SCADA is replaced by a PROFIBUS-capable acquisition card. PROFIBUS DP does not in itself escape the 187.5 kbit/s backplane constraint, but it does push the I/O update latency into a deterministic 1–10 ms range instead of the request/response asymmetry of TCP-based polling.

This path is appropriate only when the supervisory system can be re-equipped with a PROFIBUS master card (e.g., iba BMD-PN or a Siemens CP 5611/A2 successor).

5.4 Path D — Replace the CP 343-1 Lean with CP 343-1 (non-Lean)

The full-feature CP 343-1 (for example 6GK7 343-1EX30-0XE0) offers additional connection resources, ISO transport, and faster diagnostic interfaces but, critically, still uses the same 187.5 kbit/s backplane. Upgrading to the non-Lean CP will not solve the throughput problem; it may, however, increase the maximum number of connections from 16 to 64 and add PROFINET IO Device capability, which helps if the bottleneck is connection-resource exhaustion rather than raw bandwidth.

5.5 Path E — Replace the S7-300 with an S7-400

An S7-400 CPU such as 6ES7 414-3EM06-0AB0 (CPU 414-3 PN/DP) has an integrated PROFINET interface and a backplane designed for higher-throughput CPs. Update times of 25–100 ms are typical. Migration is justified only for larger plants where the S7-300 is already at the end of its service life.

6. Recommended Configuration for Path A

The recommended STEP 7 / TIA settings when moving to the CPU's integrated PROFINET interface:

7. Verification After Migration

1. From the supervisory host, ping the new CPU IP. Reply should be < 1 ms on a 100 Mbit/s LAN.
2. Open the CPU's Web diagnostics page (http://<CPU IP>) and confirm the active connections list shows the SCADA driver.
3. In iba PDA, force a 100 ms polling cycle and inspect the actual cycle time reported by the driver. It should stabilize at 90–110 ms; if it remains at 500 ms, the driver is still pointing to the old CP IP — the most common residual error.
4. Capture one second of Wireshark traffic on the SCADA switch port. The number of TCP retries should be zero and the average delta between request and ACK should be < 20 ms.
5. Toggle a digital input faster than 100 ms and confirm the SCADA captures every edge.

8. Common Pitfalls

• Reusing the CP IP on the CPU PN port. STEP 7 will not warn that two devices on the same subnet will collide. Move the CPU to the CP's old address only after physically removing the CP.
• Forgetting "Permit PUT/GET access". Default CPU protection level in newer firmware (V3.x and later on S7-300 PN CPUs) blocks PUT/GET by default. The driver will see W#16#80A7 "connection refused" with no further detail.
• PG/OP routing enabled. If the CP is removed but a routing entry still references it, the engineering station will lose its online connection. Clear the routing table in NetPro before download.
• Configuring the CP for "Web diagnostics" only as a diagnostic tool, then leaving it in the rack. Even with one TCP connection, the CP's HTTP keep-alive consumes ~2 % of the backplane permanently.
• Mistaking a 500 ms update time for an OB1 cycle time. OB1 of a CPU 315 typically runs at 50–150 ms; a 500 ms number is too coarse to be OB1 itself and is the signature of supervisory-driver-side polling plus backplane queuing.

9. Related Error Codes

When the backplane saturates, the CPU and CP report specific entries that are useful in root-cause documentation.

10. Frequently Asked Questions