CP343-1 to Honeywell DCS: S7 Communication Data Limits and TCP Coexistence

When a Siemens S7-300 CPU is connected to a Honeywell Experion DCS server (or any third-party HMI/SCADA) that uses a CP 1613 with S7 Communication, two distinct communication paths become available on the CP 343-1: the S7 connection (handled by the CPU operating system) and the TCP / SEND-RECEIVE interface (driven from the user program through FC5 AG_SEND and FC6 AG_RECV). Engineers frequently ask whether the FC5/FC6 blocks are required, what the maximum payload is on each path, and how to handle a configuration that appears to mix both protocols on a single CP. This reference consolidates the rules, sizing limits, and configuration steps for the part number 6GK7 343-1CX10-0XE0 (CP 343-1 Lean) and CPU 315-2DP against a Honeywell DCS station running S7 Communication through a CP 1613.

1. Hardware Identification and Roles

The hardware referenced in this article forms a deterministic three-node path. Each device has a single, well-defined role in the topology.

The CP 343-1 Lean is documented in the Siemens manual CP 343-1 Lean (6GK7343-1CX10-0XE0) Operating Instructions. The CPU 315-2 DP is documented at CPU 31xC and CPU 31x - Technical Data and the S7 Communication functions (PUT/GET, USEND/URCV, BSEND/BRCV) are described in the S7-300/400 System and Standard Functions Reference Manual.

2. The Two Communication Paths on CP 343-1

Engineers regularly conflate "Industrial Ethernet" with a single protocol. In reality, the CP 343-1 Lean supports two functionally independent, simultaneously active paths to the same remote partner:

2.1 Path A – S7 Connection (OS-managed)

An S7 connection is established by the operating system of the CPU 315-2DP and transported by the CP 343-1 Lean across Industrial Ethernet. The connection is configured once in STEP 7 / NCM PC using a typed connection (e.g. S7 connection) bound to a CP 343-1 interface, and the CP keeps it alive without any block calls in OB 1. The S7 Communication partner (Honeywell DCS / Experion with CP 1613) reads or writes data blocks using the standard Siemens S7 protocol, mapped onto TCP/IP + ISO-on-TCP (port 102) at the transport layer.

For a CPU 315-2DP, the only S7 Communication function blocks that operate on the S7 connection are:

• SFB 12 BSEND / SFB 13 BRCV – segmented bidirectional transfer
• SFB 14 GET / SFB 15 PUT – read / write remote data (server function on the CPU)
• SFC 7 / SFC 8 – communication status and link-up

For an S7-300 station, the partner-initiated GET (read) does not require PUT/GET to be called in OB 1; the CPU operating system responds to a read request automatically if the configured S7 connection is established and the partner has the right authorization. This is the path used by a DCS that polls tags from the PLC.

2.2 Path B – SEND/RECEIVE (FC5 AG_SEND / FC6 AG_RECV)

The SEND/RECEIVE interface is a generic, byte-stream transport. It is configured as either a TCP, UDP, or ISO-on-TCP connection in the CP properties. The user program calls:

• FC5 AG_SEND – copy N bytes from an ANY-pointer to the CP's send buffer, transmit on a configured connection
• FC6 AG_RECV – block on receive and copy up to N bytes from the CP's receive buffer to an ANY-pointer

This is the path used when the partner is a non-Siemens application that only speaks raw TCP (or ISO-on-TCP / UDP). The function blocks are part of the "SIMATIC NET CP 343-1 Lean SEND/RECEIVE" library and must be instantiated per connection in OB 1.

3. Data-Length Limits – The Key Sizing Matrix

The maximum payload per request on Industrial Ethernet is fundamentally different between the two paths. Mis-sizing either path is the most common cause of incomplete or truncated data.

The two numbers engineers must commit to memory for this part number are:

• FC5 AG_SEND over TCP = 8 192 bytes per call (Path B, byte stream)
• S7 PUT/GET against CPU 315-2DP = ~ 200 bytes per request (Path A, polled by partner)

Anything larger than 200 bytes that must come from the DCS to the PLC and back has to be assembled at the application layer in the PLC data block. The DCS driver typically does this transparently, splitting the desired range into 200-byte chunks. The PLC programmer's responsibility is only to provide a contiguous DB with sufficient length, starting at byte 0 of the area being polled.

4. Why FC5/FC6 Are Not Required for the S7 Connection

The original question on the panel was: "If I remove the FC5 AG_SEND block, can I still communicate with the Honeywell DCS server over Industrial Ethernet?" The answer is yes – with a single, important condition.

The S7 connection is established and maintained by the operating system of the CPU 315-2DP and forwarded by the CP 343-1 Lean. No user program involvement is needed for the connection to come up, to keep it alive, or to respond to a partner-initiated read (SFB 14 GET on the DCS side). The FC5/FC6 blocks are part of the SEND/RECEIVE interface – they belong to Path B, not to Path A.

Conversely, if the partner is a generic TCP server (a Python script, a custom OPC bridge, a SCADA driver that expects raw bytes), the FC5/FC6 blocks are mandatory – there is no other way to push user data from OB 1 onto the Industrial Ethernet interface of the CP.

5. Diagnosing a "TCP + S7" Coexistence on the Same CP

The original configuration reported in this article – "TCP connection at CP 343-1 end, S7 connection at Honeywell DCS server end" – is not in itself contradictory. It simply means that two separate connections have been configured in the S7-300 station: one typed TCP and one typed S7. As long as the partner endpoints are distinct (different IP, different TSAP, or different application port), the CP 343-1 Lean will establish both. The risk is on the partner side: a DCS that only knows the Siemens S7 protocol will not be able to consume data placed on the TCP connection by AG_SEND. In that case, the TCP connection will show as established at the CP (LED / online diagnostics), but the user data will be silently dropped at the partner.

5.1 Decision matrix

6. Configuring the CP 343-1 Lean for an S7 Partner

Use STEP 7 V5.5 (with the CP 343-1 Lean HSP or the standard hardware catalog). The configuration steps assume an S7-300 station with the CP 343-1 Lean inserted in slot 4 (or any free slot).

6.1 Prerequisites

1. STEP 7 V5.5 SP4 or later installed.
2. CP 343-1 Lean (6GK7 343-1CX10-0XE0) in the hardware catalog, with at least firmware V2.x (the device accepts V1.x but V2.x is recommended for stability with modern Experion drivers).
3. CPU 315-2DP with firmware V2.x or later (so that the BSEND/BRCV functions behave per the S7-300 reference manual).
4. Honeywell DCS server with CP 1613 installed and the S7-TCP channel licensed; the station type in NCM PC is set to S7-300 with Ethernet CP 343-1.
5. IP plan in place. The CP 343-1 Lean default address is 0.0.0.0; assign a fixed address (e.g. 192.168.10.20) before commissioning.
6. Firewall / managed switch: port 102/TCP (ISO-on-TCP / S7) and – if the TCP leg is used – the port chosen for AG_SEND/AG_RECV (default 2000 for CP 343-1) must be open between the PLC and the DCS server.

6.2 STEP-by-STEP configuration in STEP 7

1. Open the S7-300 station in STEP 7. In HW Config insert the CP 343-1 Lean (6GK7 343-1CX10-0XE0) at the appropriate slot. Double-click the CP to open its properties.
2. In the Properties – Ethernet Interface dialog, set the IP address, subnet mask, and (if used) router. Confirm with OK.
3. Open NetPro (or Configure Network). Right-click the CP 343-1 Lean and choose Insert New Connection.
4. In the Insert New Connection dialog, choose the partner as Unspecified / S7 connection (the partner is configured in NCM PC; the PLC side is what you are configuring here). Set the connection type to S7 connection.
5. Set the local TSAP (e.g. S7-300-PLC.01.01 – this is the slot and connection number on the CP) and the partner TSAP (e.g. CP1613.01.01 – matching the configuration on the CP 1613 side).
6. Activate Establish an active connection on the PLC side if the DCS server cannot open the connection from its side; otherwise leave it passive (CP 1613 typically opens the connection actively when the channel is enabled in Experion).
7. Save and compile. Download the HW Config and the NetPro data to the CPU (PG target system: CPU 315-2DP).

6.3 DB preparation on the PLC side

The DCS will read a data block; the DB must exist in the CPU with the right length and must not be optimized (i.e. it must be a standard DB with "non-optimized" access – this is the default for S7-300, so no action is needed unless DBs have been converted).

Example configuration block (read-only DB exposed to the DCS):

DATA_BLOCK "DB_HMI_Data"
TITLE = DCS Interface Data Block
{ S7_Optimized_Access := 'FALSE' }
AUTHOR : ENGINEER
FAMILY : DCSIF
VERSION : 0.1
  STRUCT
   ProcessValue_01 : REAL;   // e.g. temperature
   ProcessValue_02 : REAL;   // e.g. pressure
   ProcessValue_03 : REAL;   // e.g. flow
   StatusWord_01   : WORD;   // bit-packed status
   AlarmWord_01    : WORD;   // bit-packed alarms
   Heartbeat       : INT;    // incremented each scan
   Spare           : ARRAY[0..49] OF BYTE;
  END_STRUCT;
END_DATA_BLOCK

The DCS driver is configured to read the first N bytes of DB 100 (or whatever DB number is assigned) starting at byte 0. With a CPU 315-2DP, the partner issues up to ~200 bytes per GET request; the DCS driver accumulates the chunks transparently.

6.4 Optional – sending data actively from the PLC to the DCS (BSEND)

If the application requires the PLC to push data without polling, the partner must support BSEND (CP 1613 does). Add the following call in OB 1:

CALL "BSEND" , "DB_BSEND_INST"     // SFB 12 instance DB
  REQ        := TRUE                 // triggered on rising edge
  R          := FALSE
  ID         := W#16#0001            // S7 connection ID (from NetPro)
  R_ID       := DW#16#0000_0001     // any 32-bit identifier
  DONE       := M10.0
  ERROR      := M10.1
  STATUS     := MW12
  SD         := P#DB100.DBX0.0 BYTE 200  // ANY pointer to the data
  LEN        := 200

Note the LEN of 200 bytes. Exceeding the per-call maximum on an S7-300 server (the partner may still accept it from an S7-400, but for an S7-300 server the recommended LEN is ≤ 200 to avoid the SFB returning STATUS W#16#8088 / 80A1).

7. Verification – Is the S7 Connection Actually Up?

After download and CPU restart, validate the link in the following order. Each step produces an unambiguous pass/fail.

1. CP LED state. The LINK LED on the CP 343-1 Lean must be solid green. The RUN LED must be solid green. SF and BF must be off. A lit BF LED indicates a bus fault – typically an IP or TSAP mismatch on the partner side.
2. Online diagnostics in STEP 7. Right-click the CP in HW Config, choose PLC → Module Information (or use Diagnostics → Connections in NetPro). The S7 connection should be in state Established. The CP also shows byte counters per connection.
3. DCS side – channel status. In the Experion server, the S7-TCP channel should show a green status and an increasing "successful reads" counter. A channel that stays in NOT CONN points to a TSAP, IP, or CP 1613 driver misconfiguration; a channel that goes to FAULT with "connection reset by peer" usually indicates a slot or rack mismatch on the PLC side.
4. Wireshark on the link. With a managed switch and port mirror, filter on tcp.port == 102. You should see a TPKT/COTP connection setup (CR, CC) followed by S7 Read/Write requests. If only TPKT CR is visible without CC, the CP 1613 is not configured as a S7 server with the matching TSAP.
5. Forced value test. In STEP 7, set Monitor/Modify on DB 100 byte 0..3 to a known pattern (e.g. 16#3F80 0000 = 1.0 REAL) and verify the value appears on the DCS HMI within one poll cycle.

8. Common Errors and Recovery

9. Sizing Example – 1 000 Bytes of Process Data from PLC to DCS

Consider a process that exposes 1 000 bytes of structured data to the DCS. The choice of path determines the protocol mechanics:

9.1 If using S7 (Path A – the standard DCS case)

• DB 100 in the PLC, length ≥ 1 000 bytes, optimized access = false.
• DCS channel: read DB 100 from byte 0, length 1 000.
• Driver issues five GET requests of 200 bytes each (background, transparent to the user).
• Update rate on the DCS is set by the channel poll time; typical values 200 ms to 1 s.

9.2 If using SEND/RECEIVE over TCP (Path B)

• Configure a TCP connection to the DCS, port (e.g.) 2 000.
• Call FC5 AG_SEND with LEN = 1 000 – well within the 8 192-byte limit, no segmentation needed.
• DCS partner must speak raw TCP; this is not what the Honeywell S7-TCP channel does – the S7-TCP channel uses the S7 protocol (Path A), not a raw byte stream.

Conclusion for the typical Honeywell DCS integration: keep the data on the S7 connection (Path A), let the DCS chunk the 1 000 bytes into 200-byte GETs, and do not configure a TCP connection in the CP at all. This is the simplest, most supportable, and most diagnostic-friendly topology.

10. When Path B (TCP / SEND-RECEIVE) Is the Right Choice

There are legitimate cases for adding AG_SEND/AG_RECV on a CP 343-1 already carrying an S7 connection to a DCS:

• Event-driven push from PLC to a third-party system (a Python gateway, a custom reporting server) that polls would not be appropriate for. AG_SEND is the right tool here.
• High-throughput data dump to an OPC-DA or OPC-UA bridge that does not implement the S7 protocol.
• Replacement of legacy serial DF1 / Modbus to a free-form ASCII listener. Use ISO-on-TCP for a TSAP-based fixed partner, or TCP for an IP-port-based fixed partner.

In all three cases, the SEND/RECEIVE connection must be configured as a separate entry in NetPro; it must not be merged with the S7 connection. The CP 343-1 Lean supports multiple parallel connections, but the limit must be checked against the device's connection count (the Lean supports 4 S7 connections / 8 SEND-RECEIVE connections, depending on firmware; see the device manual for the exact number on the installed firmware).

11. Engineering Notes and Best Practices

• Do not enable the S7 connection and a TCP connection to the same partner with the same TSAP. The CP will not refuse the configuration, but the partner will only be able to use one of them. The unused one will hold a TCP socket open and consume a CP connection resource for no benefit.
• Keep AG_SEND/AG_RECV LEN at or below the documented limit (8 192 TCP, 2 048 UDP). A LEN that exceeds the buffer produces STATUS 80B1 and no transmission – the error is at the FC5 call, not at the network level.
• Match the SFB 12/13 LEN to the partner's expected per-call size (200 bytes for an S7-300 server). The CP 343-1 firmware is permissive, but the partner's buffer is the binding constraint.
• Use standard (non-optimized) DBs for any data that the DCS or third-party tool reads. Optimized DBs hide their real layout and break fixed-offset access that the S7 protocol relies on.
• Tag the connection with a meaningful local ID in NetPro – the W#16#ID in BSEND/GET/PUT and the AG_SEND/AG_RECV parameter ID both point to the connection ID. Commenting the ID in the project (e.g. "ID 1 = DCS polling") saves a lot of time during commissioning.
• Update the CP firmware before field deployment. The 6GK7 343-1CX10-0XE0 was revised several times; firmware V2.0 or later closes several TCP-edge bugs that otherwise surface as random disconnects under load.
• For redundant DCS paths, plan a second CP 343-1 (full version, not Lean) with separate IP and separate S7 connection. The Lean variant does not support parallel redundancy protocols.

12. Field Commissioning Checklist

1. Verify the CP 343-1 Lean and CP 1613 are on the same subnet and can ping each other.
2. Verify the S7 connection in NetPro is compiled without warnings, downloaded to the CPU, and the CPU is in RUN.
3. Open Module Information on the CP and confirm the S7 connection state is Established.
4. Open the DCS server console, enable the S7-TCP channel, and watch the channel transition from NOT CONN to OK.
5. Force a known value in the interface DB, confirm it appears on the DCS HMI within one poll cycle, and release the force.
6. Add the SFB 12/13/14/15 status words to the VAT if BSEND/PUT/GET are used, and confirm DONE pulses with each successful call and STATUS stays at 0.
7. Capture a 30-second Wireshark trace on the port mirror and save it with the commissioning report.
8. Document the connection ID, TSAP, IP, and DB layout in the project's network register.

13. Frequently Asked Questions