CP 443-1 Communication Block Parameterization and Performance

1. CP 443-1 Module Overview and Performance Scope

The SIMATIC NET CP 443-1 is the communications processor for the S7-400 family that connects an S7-400 station to Industrial Ethernet. It offloads TCP/IP, ISO-on-TCP, UDP, and PROFINET I/O stack processing from the CPU and exposes a set of configurable connection resources (S7 connections, S7-H connections, SEND/RECV connections, FETCH/WRITE, and open IE communication) that are parameterized in the SDBs loaded into the CP at startup.

When field engineers ask how to "parametrize the performance of the Ethernet module" — meaning packet size, send frequency, jitter, and cycle time — the answer is split between two distinct areas:

• CP firmware-controlled parameters — packet size, internal buffer thresholds, keep-alive timing, and the number of simultaneously usable connection resources. These are fixed in firmware and not adjustable from STEP 7.
• Application-controlled parameters — when the PLC is the client (active communication partner), the calling rate, the block (FC/FB) used, the protocol (TCP vs ISO-on-TCP), and the data length per call are entirely under the user-program's control.

Understanding this split is the foundation of every CP 443-1 performance tuning exercise. The remainder of this document maps the available levers in each area, the diagnostic procedure to quantify current behavior, and a verification workflow for the tuned configuration.

2. Block Container Architecture in the CP 443-1

The "Blocks" container visible in the CP 443-1's STEP 7 hardware project (under the CP node in the project tree) is reserved for the CP's own system data blocks and downloaded firmware-related blocks. It is not a place to drop application logic.

Specifically, this container holds:

• The SDBs (System Data Blocks) generated by STEP 7 from the HW Config (connection configuration, IP parameters, port settings, keep-alive, PROFINET device assignments).
• The CP firmware itself, downloaded as a single binary via SIMATIC Manager → Options → Edit Ethernet Node → Firmware Update, or via the Web-Based Management (WBM) page on the CP.

No user FC, FB, OB, or DB belongs in this container. Per the official SIMATIC NET S7-CPs documentation for Industrial Ethernet, the CP's local blocks are strictly used to store the SDBs that the CP interprets at run time. Inserting application blocks here will produce a download error or, at worst, be silently discarded by the CP's loader. The complete CP manual and block version table are available in the SIMATIC NET S7-CPs for Industrial Ethernet CP 443-1 manual (PDF).

3. Application-Side Communication Function Blocks

When the S7-400 is the active partner (client) that initiates SEND/RECV operations, performance is set by the user program through the call frequency, the data length per call, and the block family selected. The CP 443-1 supports the following user-callable interface blocks (libraries shipped with SIMATIC NET):

Control knobs available at the application layer:

1. Call rate — Place the SEND/RECV FC/FB calls inside a cyclic OB (OB 1, OB 30–OB 38) at a known interval. Calling them from OB 1 every scan gives you scan-rate throughput; calling from a 100 ms OB30 gives deterministic 10 Hz.
2. Data length per call — Larger payloads (AG_LSEND up to 8 KB, B_SEND segmented up to 64 KB) amortize the per-packet Ethernet header and TCP/ISO-on-TCP overhead. The CP's internal buffer can hold multiple outstanding SEND jobs; the firmware default is sufficient for typical control workloads.
3. DONE/NERROR evaluation — Each block returns a status word. Polling this at known intervals instead of blocking on it lets you implement a clean rate-limited loop.
4. Connection multiplexing — Multiple SEND/RECV jobs over the same ISO-on-TCP connection are serialized by the CP. If jitter is a concern, open parallel connections and split the I/O image across them.

4. Protocol Selection: TCP vs ISO-on-TCP vs UDP

The protocol choice is the single largest controllable variable affecting throughput and latency on the CP 443-1.

For context, when comparing Industrial Ethernet control protocols on throughput, a useful formula is the bandwidth demand per connection:

where pps is packets per second. For a cyclic RMC-style 50 ms RPI on EtherNet/IP, this gives 1 / 0.050 = 20 pps, and a typical 80-byte EtherNet/IP packet yields ~1.6 kB/s per connection (per the Delta Motion EtherNet/IP I/O performance reference). The same arithmetic applies to CP 443-1 ISO-on-TCP traffic once the header is computed.

5. Firmware-Controlled Parameters (Not Adjustable from STEP 7)

The following CP 443-1 behaviors are fixed in firmware and cannot be changed by the user program, SDB edits, or HW Config:

• Maximum Ethernet frame size — Standard 1518 bytes (1522 with VLAN tag). The CP does not support jumbo frames.
• Internal CP buffer depth — Firmware-defined queue length per connection; the user cannot tune it.
• TCP keep-alive interval — SDB-configurable on the connection's properties dialog (default 30 s), but the underlying keep-alive mechanism is implemented in firmware.
• Nagle algorithm behavior — Internally controlled. On native TCP connections, the CP may apply Nagle-style coalescing; on ISO-on-TCP it generally does not, because the TPDU length is preserved and the user calls AG_SEND per message.
• PROFINET I/O cycle time floor — Determined by the configured send clock (1 ms is typical minimum) and the firmware's internal handling.

Attempting to use non-Siemens third-party utilities to "patch" these values is not supported and will violate the device's operational certification.

6. Diagnostic Procedure: Wireshark Packet Capture

When tuning is required, the first step is always to measure the current traffic rather than guess. Wireshark is the standard tool.

1. Mirror the CP 443-1 port. Configure the managed switch the CP is attached to with a SPAN / mirror session that copies the CP's port to a laptop NIC. On a SCALANCE XC/XB/XR, this is under "Information > Port Mirroring" (a SPAN source of the CP port, destination the laptop port).
2. Set the capture filter to isolate the CP's traffic. Example: host 192.168.0.10 and tcp port 102 for ISO-on-TCP/port 102 S7 traffic, or host 192.168.0.10 and tcp for the full TCP stream from the CP.
3. Capture for at least one full shift or one full process cycle to get representative statistics.
4. Use Statistics > Conversations to identify the top talkers, average and burst packet sizes, and inter-packet timing.
5. Use Statistics > I/O Graph to plot packets per second over time. The graph will show whether traffic is bursty (concentrated in OB 1 scan bursts) or smooth (called from a time-driven OB).
6. Filter for retransmissions: tcp.analysis.retransmission. A non-zero rate indicates network congestion, duplex mismatch, or a faulty cable. Retransmits collapse effective throughput.

Targeted captures should answer three questions: What is the peak pps? What is the peak payload per second? How much of the link capacity is used at peak?

For a 100 Mbit/s link, sustained utilization above 60% with growing jitter is a strong signal that the application is calling SEND/RECV faster than the CP can drain the buffer, and a slower OB or a larger payload per call is required.

7. CP 443-1 Built-in Diagnostics

The CP 443-1 exposes several diagnostic surfaces; none of them tune the CP, but all of them reveal whether the tuning is taking effect.

The diagnostic buffer in particular uses Siemens-standard event IDs. A few common ones:

• Event 0x0101 — CP startup completed.
• Event 0x0A01 / 0x0A02 — Connection established / connection terminated. The accompanying diagnostic word identifies the connection number from NetPro.
• Event 0x0B01 — SEND/RECV error reported back to the user program; the diagnostic word will be the same value returned at the AG_SEND/AG_RECV NERROR output.
• Event 0x0E01 / 0x0E02 — Watchdog or firmware fault.

If the diagnostic buffer shows repeated 0x0B01 errors with status W#16#80A1 ("connection not established") or W#16#8085 ("timeout") immediately after a tuning change, the application is calling SEND/RECV faster than the partner can accept, and the OB period must be lengthened.

8. Network Segmentation with Dual NIC Architecture

For SCADA systems where the same PC both reads PLC data and serves other unrelated network traffic (plant MES, e-mail, internet, file shares), the cleanest performance fix is physical network isolation using a second NIC.

1. Add a second PCI/PCIe Ethernet NIC to the SCADA PC, e.g. Intel I210-T1 or Intel I350-T2 for a server-grade option.
2. Assign the new NIC a dedicated subnet, e.g. 192.168.10.0/24, and connect it point-to-point to the CP 443-1.
3. Bind the SCADA software's Siemens driver (e.g. S7Comm, libnodave, OPC-DA server) to only the new NIC's IP. On Windows this is the binding order in Network Connections > Advanced > Advanced Settings; on Linux it is achieved by the application explicitly opening the socket on that interface.
4. Keep the original NIC on the corporate/plant LAN for MES, file shares, etc. These two networks should never share a switch unless a deterministic firewall/bridge is inserted.

This isolation eliminates cross-traffic contention, broadcast storms from the corporate side reaching the CP, and ARP-table churn caused by the SCADA PC's other network activity. For control networks with deterministic cycle requirements, this is the single most effective change available.

9. Verification and Commissioning Checklist

After tuning, walk this checklist before sign-off:

1. Confirm in the CP 443-1 diagnostic buffer that the relevant connection(s) reached the "established" state (event 0x0A01) and that no error events followed.
2. Capture a Wireshark trace for 10 minutes under normal load. Confirm:
   • Inter-packet timing matches the OB period (or expected jitter envelope).
   • No TCP retransmissions.
   • No out-of-order segments.
3. Force a CP restart (power cycle the S7-400 rack) and confirm the CP reconnects all configured connections within 60 s. This validates that the SDBs are valid and the firmware block is compatible with the CPU firmware.
4. Verify the latest block versions are in use. Siemens ships periodic updates to AG_SEND, AG_LSEND, B_SEND, etc. The current version matrix is published in the SIMATIC NET CP 443-1 manual; mixing old blocks on a new CP firmware is a common source of NERROR = W#16#80C3 ("block version not supported").
5. Run a sustained soak test for 24–72 hours and review SNMP interface counters for input/output discards. Any non-zero discard counter means the CP's firmware buffer is being overrun and the OB period is still too short.

10. Troubleshooting Matrix

11. Putting It Together — A Practical Tuning Recipe

For a typical S7-400 → SCADA link over the CP 443-1, the highest-yield tuning sequence is:

1. Confirm both stations run the latest CP firmware block versions per the SIMATIC NET CP 443-1 documentation.
2. Use ISO-on-TCP (port 102) unless the SCADA driver requires native TCP.
3. Call AG_LSEND / AG_LRECV from OB 35 (100 ms) or OB 32 (500 ms) — time-driven, not scan-driven.
4. Consolidate all per-cycle I/O into one or two large sends (close to the 8 KB AG_LSEND maximum) rather than many small ones.
5. Physically separate the SCADA PC's PLC network from the corporate network with a second NIC.
6. Validate with Wireshark and the CP's own diagnostic buffer; iterate on OB period and payload size until the measured pps matches the design intent and the link utilization stays below 50% on a 100 Mbit/s segment.

With those steps, the S7-400's CP 443-1 will deliver deterministic, low-jitter Ethernet communication bounded by the application code's call rate and the firmware's internal buffer behavior — exactly the levers available to the control engineer.