CP 343-1 Communication: Programming S7-300 Data Exchange Blocks

Overview of the CP 343-1 Family

The CP 343-1 is a Siemens communications processor for the SIMATIC S7-300 PLC family that connects the CPU to Industrial Ethernet and PROFINET networks. The variant referenced in field service, 6GK7-343-1EX11-0XE0, was superseded by later revisions with extended functionality, identical mechanical footprint, and backward-compatible firmware. Every CP 343-1 occupies one slot in the S7-300 rack and operates as an intelligent communication node — frame handling and connection management run on the module itself, leaving the CPU free for the application program.

Communication Services and Connection Types

The CP 343-1 supports multiple OSI Layer 4–7 services. Selecting the right service dictates which block the user program must call. The catalog below matches each transport to its SIMATIC_NET_CP block; the S7 protocol (ISO-on-TCP, port 102) is the default for controller-to-controller exchange, while raw TCP and UDP serve third-party integrations.

SIMATIC_NET_CP Library: Block Catalog

All S7-300/400 communication blocks that drive a CP live in the SIMATIC_NET_CP library (STEP 7 V5.x) or in the equivalent TIA Portal "Communication Blocks" palette. Blocks with identical numbers in the IEC standard library (e.g., FB14 from Standard Library > Communication Blocks) have a different interface and must not be substituted. The CP-aware blocks begin all parameter names with the same prefix conventions (REQ, ID, NDR, DONE, ERROR, STATUS) and accept the connection ID assigned in NetPro.

STEP 7 V5.x vs TIA Portal Block Equivalence

When the same project is migrated to TIA Portal V13 or later, the SIMATIC_NET_CP FBs are replaced by instruction extensions of the same name. The interface is unchanged; only the call mechanism differs (single-instance DB, no need to open the project library). The reference manual for CPU-CPU communication with SIMATIC controllers is published as Siemens support entry 78028908 — Communication with SIMATIC.

Project-Spanning Data Exchange: Connection Setup in NetPro

When two CP 343-1 modules live in different STEP 7 projects and exchange data across an Industrial Ethernet / PROFINET subnet, the connection must be configured in NetPro (STEP 7 V5.x) or in the "Devices & Networks" editor (TIA Portal). The connection is the S7 connection type, identified by its connection ID used as the ID input on the FB. The full procedure is documented in Siemens support entry 78028908.

1. Open NetPro in the project that owns the CP 343-1 acting as the active partner (the partner that calls PUT/GET/BSEND).
2. Right-click the CP 343-1 module and choose Insert New Connection > S7 Connection.
3. In the connection dialog, enter the partner IP address, partner rack, and partner slot of the remote CPU. Do not select "Establish connection actively" on both ends — exactly one end is active, the other is passive.
4. Note the local connection ID shown in the connection properties (typical range 1..16). This same ID is passed to the FB.
5. Compile and download the NetPro configuration; the CP 343-1 stores the connection in its project database.
6. If the partner lives in a separate project, export it as a station (.s7p / .tnf) and import it under "Partner" in the active project so NetPro can resolve the IP at compile time.

Programming the GET / PUT Pair

FB14 GET and FB15 PUT are the simplest mechanism for cross-project data exchange. Both run on the active partner; the remote side needs only the S7 connection resource but no program changes. Each call moves a contiguous data area, so a 200-byte DB block is moved in one FB call without segmentation.

FB15 PUT Call (STL / SCL)

CALL FB15, DB15 (
REQ    := M100.0,             // Trigger: rising edge
ID     := W#16#0001,          // Connection ID from NetPro
DONE   := M110.0,
ERROR  := M110.1,
STATUS := MW112,
ADDR_1 := P#DB100.DBX0.0 BYTE 40,  // Remote DB100 bytes 0..39
SD_1   := P#DB200.DBX0.0 BYTE 40   // Local source DB200 bytes 0..39
);

FB14 GET Call (STL / SCL)

CALL FB14, DB14 (
REQ    := M120.0,
ID     := W#16#0001,
NDR    := M130.0,
ERROR  := M130.1,
STATUS := MW132,
ADDR_1 := P#DB100.DBX50.0 BYTE 80,
RD_1   := P#DB300.DBX0.0 BYTE 80
);

ADDR_1 through ADDR_8 (eight variable slots) extend the transfer up to 462 bytes per call when used concurrently. STATUS should always be evaluated in OB1 or OB35; STATUS W#16#0000 signals success, while any non-zero value should be evaluated against the FB15/FB14 error table in the manual.

BSEND / BRCV: Segmented Transfers up to 32 KB

When the payload exceeds 462 bytes — or the application must synchronize blocks with a defined start/stop — use FB12 BSEND and FB13 BRCV. BSEND fragments up to 32 768 bytes into multiple ISO-on-TCP packets; BRCV reassembles them and signals completion with DONE. Each BSEND call is acknowledged end-to-end by the receiver, making the pair well suited to recipe download and bulk diagnostics transfer.

CALL FB12, DB12 (
REQ    := M200.0,            // Trigger
ID     := W#16#0002,
R_ID   := DW#16#DEADBEEF,    // Arbitrary, must match BRCV
DONE   := M210.0,
ERROR  := M210.1,
STATUS := MW212,
SD_1   := P#DB500.DBX0.0 BYTE 8192,
LEN    := 8192
);

CALL FB13, DB13 (
EN_R   := TRUE,
ID     := W#16#0002,
R_ID   := DW#16#DEADBEEF,
NDR    := M220.0,
ERROR  := M220.1,
STATUS := MW222,
RD_1   := P#DB600.DBX0.0 BYTE 16384
);

USEND / URCV: Uncoordinated 4-Byte Handshake

FB8 USEND and FB9 URCV move up to four bytes without coordination or acknowledgment. They are intended for status flags and handshake signals, not for payload data. The receiver must be ready (URCV in the cycle) before USEND fires, or the data is lost silently. Because of this race condition, prefer BSEND/BRCV or GET/PUT for any data that must not be dropped.

ISO Transport vs TCP Connections

The CP 343-1 can be programmed to use either ISO-on-TCP (RFC 1006, port 102) or raw TCP for S7 communication. The choice is made in NetPro under connection properties > "Address Details". Use ISO-on-TCP unless the partner requires raw TCP — for example, a third-party application speaking S7 communication over a non-Siemens firewall or NAT boundary.

Cross-Project Exchange via S7 Routing

When the two CP 343-1 modules reside in different STEP 7 projects but share a common Ethernet subnet, NetPro establishes the connection across project boundaries. The active partner must hold the partner IP address; the passive partner needs only its own CP configuration. If the two projects are owned by different engineering teams, export the partner project as a station (.s7p / .tnf) and import it under "Partner" in the active project. This is the Siemens-recommended workflow and the only supported route for a cross-project S7 connection. The S7 routing table — see entry 78028908 for the routing rules — must permit the gateway CP 343-1 to forward frames addressed to either subnet.

Data Exchange Between Standard User Program and Safety Program

On an S7-300F / S7-300F CPU (e.g., CPU 317F-2 PN/DP) or on a CP 343-1 installed in an F-CPU rack, data exchange between the standard user program and the safety program uses fixed channels rather than the SIMATIC_NET_CP FBs. The mechanism is described in the TIA Portal help and the SIMATIC Safety Configuring and Programming manual, available at TIA Portal — Data exchange between standard user program and safety program.

Per the TIA Portal Safety manual: "Tags can be transferred using DBs, F-DBs and bit memory." When a tag is written by the standard program and consumed by the safety program, the standard program must provide both the data and a separate validity flag, and the F-program must check the validity flag on a defined cycle before acting on the data. The pairing of data + validity is mandatory; a single untagged tag may never cross the standard/safety boundary.

Status and Error Codes

Diagnostics and Verification

1. Open NetPro, right-click the CP 343-1 and choose Connection Status. All configured S7 connections should show "Established".
2. In the partner project, open the same CP's online diagnostics: PLC > Online & Diagnostics > Communication. Byte counters for sends and receives confirm live data flow.
3. Force a GET/PUT with a watch table on the active side: writing DB200.DBD0 = 12345 on the remote CPU should appear in the partner DB after one cycle of the calling FB.
4. Trigger a BSEND/BRCV pair; verify DONE toggles on both sides and the receiver DB shows the exact byte count equal to LEN.
5. Cross-check the F-CPU's F-Change History if a safety program is involved; CP 343-1 transport errors do not appear here, but invalid tag validity flags do.
6. Use the CP 343-1's Web diagnostics page (if enabled: http://<CP-IP>/diag) for live connection state without needing STEP 7 online access.

Troubleshooting Matrix

Field-Commissioning Checklist

• Confirm CP 343-1 firmware version under Online & Diagnostics > Module Information; firmware ≥ 2.0 is recommended for EX11 variants running modern TIA Portal projects.
• Reserve the CP 343-1's Ethernet port exclusively for S7 communication if PG/OP traffic is heavy; use a managed switch with VLAN to separate the two traffic classes.
• Document connection IDs (1..16) in the project functional specification; collisions are a common startup fault when several engineers add connections in parallel.
• For cross-project exchange, attach a partner stub (.s7p / .tnf) to each project and check it into version control so connection changes are reviewed.
• Configure SNTP time sync via the CP 343-1 if both sides timestamp events; mismatched timestamps confuse audit logs and sequence-of-event reconstruction.
• Disable unused services (FTP, HTTP, SMTP) on the CP 343-1 IT variants to reduce attack surface — the Advanced firmware adds an integrated firewall for this purpose.
• Schedule a periodic backup of the CP's project file via the Web diagnostics > "Backup" page; replacing an EX11 in the field without a project file can cost a full day of commissioning.