S7-300 CPU-to-CPU Ethernet Communication with CP 343-1 Lean

Overview: Four-Station S7-300 Network Architecture

Multi-station S7-300 networks with CPU 317-2DP controllers and CP 343-1 Lean communication processors are common in water/wastewater, building automation, and small process plants. The challenge is implementing deterministic CPU-to-CPU data exchange on Ethernet while keeping the same CP available for SCADA polling, leaving the PROFIBUS-DP master port free for distributed I/O.

The reference configuration discussed in this guide is:

• 4x SIMATIC S7-300 stations, each with a CPU 317-2DP (6ES7317-2AK14-0AB0, firmware V3.x)
• 1x CP 343-1 Lean (6GK7343-1CX10-0XE0) per station in the Ethernet subnet
• 1x SCADA/operator station on the same switched Ethernet segment
• TCP/IP-based cyclic data exchange between all four CPUs

Each CPU must read data published by the other three and publish its own data, with a typical exchange budget of 50 to 400 bytes per station. Because the application is non-time-critical (wastewater treatment), latency in the 100 ms range is acceptable.

Clarification: Global Data (GD) vs. Ethernet Communication

A frequent source of confusion is the term "Global Data." In SIMATIC vocabulary, Global Data is a Siemens-specific broadcast mechanism for exchanging small amounts of data over MPI or the backplane bus, not over Ethernet. CPU 317-2DP supports GD communication with the following hard limits:

For an Ethernet-based four-station project with a SCADA client, Global Data is the wrong tool. The correct family of solutions is the Open Communication Services (ISO-on-TCP, TCP, UDP) or S7 Communication (PUT/GET) carried over the CP 343-1 Lean. The remaining sections of this guide focus on those mechanisms.

Connection Type Selection: ISO-on-TCP, TCP, UDP, S7

SIMATIC S7-300 / CP 343-1 Lean supports four transport protocols for user-controlled data exchange. Selection depends on data size, partner type, and diagnostic needs.

For the four-station wastewater reference plant, ISO-on-TCP with FC5/FC6 is the canonical choice: every CPU is a Siemens device, the 8 KB ceiling per call is far beyond the data requirement, and ISO-on-TCP gives clean per-job acknowledgment and orderly close behavior. The remainder of this guide uses ISO-on-TCP exclusively.

Hardware and Topology Prerequisites

1. Four CPU 317-2DP mounted on a common rack profile with PS 307 power supply, SM 321/SM 322/SM 331/SM 332 as required.
2. One CP 343-1 Lean (6GK7343-1CX10-0XE0) per station. The Lean variant is part number 6GK7343-1CX10-0XE0; the EX11 firmware is current. Note: CP 343-1 Lean does not support routing to other subnets and has no integrated switch (single RJ45 port). An external managed switch (e.g., SCALANCE XB005 or XB208) is required to build the Ethernet segment.
3. Ethernet patch cabling, Cat 5e or better, maximum segment length 100 m.
4. SCADA station (WinCC, Citect, iFIX, or a third-party SCADA) with Ethernet interface and the same subnet. SCADA talks to each CPU over the same CP 343-1 Lean used for CPU-to-CPU traffic.
5. STEP 7 V5.5 SP4 (or V5.6) project with the four stations inserted, CP 343-1 Lean hardware catalog (HSP) installed.

STEP 7 Project Structure and IP Plan

Assign fixed IP addresses. The CP 343-1 Lean acts as a separate Ethernet node from the CPU, even though it sits in the same S7 station. CPU 317-2DP has an integrated PN/DP port, but the Lean CP is typically used for the SCADA-coupled traffic to keep that path isolated from distributed I/O on PROFIBUS-DP.

Use subnet mask 255.255.255.0 and keep the SCADA station on the same /24 as the CPs. Avoid duplicate IP addresses; the CP 343-1 Lean will refuse to come online with a duplicate and report SF/BF on the front panel.

NETPRO Connection Configuration

Open SIMATIC Manager > Options > Configure Network (NETPRO). Each CPU needs three outgoing ISO-on-TCP connections, one to each of the other three CPUs. On the partner CPU you create the matching receive-end connection. This is the standard "configured connection" model: every connection has a local ID, a partner IP, a TSAP, and an active/passive role assignment.

1. Right-click the CP 343-1 Lean of Station A in NETPRO and choose "Insert New Connection." Pick "ISO-on-TCP connection" and select the CP of Station B as the partner. The CP offers to create the partner side automatically; accept.
2. In the connection properties, give the local connection an ID, for example ID 1. The partner receives a mirrored ID automatically. Assign TSAPs: the active end is typically the one whose CP connects, so on Station A assign TSAP "PLC1.01" (or simply "01.01") and on Station B the passive TSAP "PLC2.01" / "02.01". The TSAP must be identical on both sides for the connection to establish.
3. Repeat to create connections A ↔ C (ID 2) and A ↔ D (ID 3) on Station A. Each partner station gains the corresponding mirror connections.
4. On Station B, add connections to C (ID 4) and D (ID 5) - the A-link was created in step 1.
5. On Station C, add connection to D (ID 6) - A and B links are already there.
6. Save and compile NETPRO, then download the connection configuration (Connections button on the CP properties, or the entire station) to each PLC.

Connection Budget on the CP 343-1 Lean

This is the single most common stumbling block on this topology. The Lean CP is limited:

For a four-station ISO-on-TCP design with a SCADA server, the budget is:

• 3 ISO-on-TCP CPU-to-CPU connections per CP = 3
• 1 S7 connection (or ISO) to SCADA per CP = 1
• Total per CP = 4 connections, well within the 8-connection ceiling.

If the SCADA polls via ISO-on-TCP and the engineering team also wants one diagnostic connection per CP (e.g., a laptop for online viewing), plan the connection matrix carefully and document it in NETPRO. The CP 343-1 Lean does not allow the budget to be exceeded at runtime; new connection attempts are rejected with status word W#16#80A1 in the AG_SEND / AG_RECV blocks.

Programming FC5 AG_SEND and FC6 AG_RECV

The Open Communication interface is a pair of function blocks shipped with STEP 7. For ISO-on-TCP, the classic pair is FC5 (AG_SEND) and FC6 (AG_RECV) from the "Standard Library > Communication Blocks" catalog. Place the calls in OB1 (cyclic) or in a watch-dog OB (e.g., OB35 at 100 ms) for deterministic cycling.

FC5 AG_SEND interface (STEP 7 V5.5)

FC6 AG_RECV interface

Sample LAD / FBD call pattern (per CPU, 3 partners)

For each of the three connection IDs, instantiate a send call and a receive call. The send calls may be triggered by a cycle clock (e.g., OB35 at 1 s for slow process data) while the receive calls are evaluated every OB1 scan. Keep the receive buffer slightly larger than the send length to tolerate future growth:

// Station A - send to Station B (ID=1)
CALL FC5 // AG_SEND
  ACT := M100.0 // 1-second cycle pulse from OB35
  ID  := 1
  LADDR := W#16#100 // CP 343-1 Lean in slot 4
  SEND := P#DB100.DBX0.0 BYTE 200
  LEN  := 200
  DONE := M110.0
  ERROR:= M110.1
  STATUS:= MW112

// Station A - receive from Station B (ID=1)
CALL FC6 // AG_RECV
  ID  := 1
  LADDR := W#16#100
  RECV := P#DB201.DBX0.0 BYTE 200
  NDR  := M120.0
  ERROR:= M120.1
  STATUS:= MW122
  LEN  := MW124

Repeat for IDs 2 and 3 (Station C and Station D). For each CPU, three DBs are typical:

• DB100 - "MyData": local data published to all three partners
• DB201, DB202, DB203 - received data from partners B, C, D

Synchronize send cadence so that all four stations trigger FC5 within a 100-200 ms window of each other. Use a global enable bit distributed via the SCADA or a small dedicated "heartbeat" byte that each station broadcasts and increments in the send DB. This makes timeouts in NDR/DONE much easier to diagnose.

Status Word Diagnostics (FC5/FC6)

The STATUS output of FC5/FC6 follows the SIMATIC communication status convention. Critical codes for this topology:

See the official SIMATIC Communication DOKU v21 for the complete status table.

SCADA Integration on the Same CP 343-1 Lean

Running SCADA on the same CP as CPU-to-CPU traffic is fully supported and is the default plant architecture for small systems. Two technical points to enforce:

1. Define SCADA as one additional connection on each CP. The total cost is one connection per CP (the SCADA polls the CPU, the CPU is server). The CPU-to-CPU connections are unchanged.
2. Disable the CP 343-1 Lean "Write protection" and "Read protection" for the SCADA connection, or set the CPU's protection level to "No protection" / "Write-protection for HMI" so the SCADA can read consistently.

For the SCADA-side protocol, two common options exist:

• S7 communication (recommended): The SCADA driver (e.g., WinCC with "SIMATIC S7 PROTOCOL SUITE" channel, KEPware, or LibNoDave) opens a single S7 connection to the CP, then uses PUT/GET semantics. Configuration in NETPRO: one unspecified S7 connection per CPU pointing at the SCADA PC.
• ISO-on-TCP to SCADA: The SCADA acts as a passive ISO-on-TCP partner. Used when the SCADA vendor does not have a native S7 driver. Connection count is the same.

WinCC typically uses S7 communication and consumes one S7 connection per CPU, leaving the four CPU-to-CPU ISO-on-TCP links untouched. The 8-connection budget is then 3 (CPU) + 1 (SCADA) + 1 (engineering, optional) = 5 per CP.

Commissioning Procedure

1. Wire the panel, install the CP 343-1 Lean, and connect all four PLCs to a managed switch. Verify the SF/BF LED pattern: SF off, BF off, LINK LED green = healthy link.
2. Open the STEP 7 project, perform a full download of each station (hardware, connections, program). Wait for the SF LED to extinguish on each CP.
3. From a programming PC, use the menu "PLC > Ethernet Node > Edit Ethernet Node" or the Web diagnostics of the CP (http://192.168.1.11 if reachable) to confirm the assigned IP and firmware. CP 343-1 Lean supports Web diagnostics from firmware V2.0 onward.
4. Go online with each CPU. In OB1, evaluate the STATUS word of the first FC5/FC6 pair. Expect 7000/7001 transitioning to 0000 within 3-5 seconds of CPU RUN.
5. Use a VAT (Variable Table) to monitor M110.0, M110.1, MW112. A persistent 80A4 status indicates that the partner CPU has not established the connection, most often because of TSAP mismatch or because the partner CPU is still in STOP.
6. Force a small value (e.g., a counter in DB100) from Station A. Verify that the same counter appears in DB201 of Station B within one cycle clock (1 s if OB35 is configured at 1 s).
7. Bring SCADA online. Add the four PLCs as S7 connections in the SCADA project, and confirm tag polling at the configured update rate (250 ms - 1 s is typical).
8. Test failure modes: stop one CPU, confirm that the partner stations report 80D0 or 80A4 in the receive side, and that the SCADA driver marks the stopped CPU as "not reachable" but keeps the other three online.

Alternatives: S7 Communication with PUT/GET

If the data volume is asymmetric (e.g., one master CPU pulls from three slaves) and the data fits inside the 160-byte single PUT limit, the S7 Communication blocks (FB14 PUT, FB15 GET) offer a leaner implementation. The downside is that PUT/GET require both partners to be active or configured, and they count against the S7-connection budget on the CP, which on the Lean is even tighter than the open-communication budget.

For symmetric "all stations publish and consume" topologies, ISO-on-TCP with FC5/FC6 is the right call. For star topologies with a clear master, PUT/GET may be simpler.

Common Pitfalls and Field-Proven Caveats

Verification Checklist

• All four CPs show SF off, BF off, LINK green.
• FC5 DONE pulses once per send cycle for all three connections on every CPU.
• STATUS words read 0000 in steady state.
• Receive DBs on each CPU update at the configured cycle time.
• SCADA online diagnosis shows all four PLCs "Connected."
• Stopping one CPU does not crash the others; the partner STATUS words degrade gracefully to 80D0.
• Connection count per CP = 3 (CPU-to-CPU) + 1 (SCADA) + 1 (engineering) = 5, within the 8-connection budget of the CP 343-1 Lean.

FAQ