Troubleshooting Slow ISO Transport on S7-400H Redundant Systems

1. Problem Overview

An S7-400H redundant station built around a CPU 417-4H (order number 6ES7 417-4HT14-0AB0) communicates with 41 S7-416F2 controllers. Twenty-seven of those partners use the S7 Communication protocol, and the remaining fourteen use ISO Transport (ISO-on-TCP) via the CP 443-1 (order number 6GK7 443-1EX20-0EX0). The S7 connections deliver an AGSend/BRECV round-trip of roughly 300 ms for 200 bytes of payload, while the ISO Transport connections require approximately 1,500 ms (1.5 s) for the same payload, a 5× penalty that turns into 30× the SOLO-mode baseline.

Measured in SOLO mode (redundant partner CPU powered off, single CPU active), the same 200-byte AGSend completes in 1–2 OB1 scans, which the operator reports as 35–70 ms because the OB1 minimum cycle time has been raised to 35 ms. That gives the following approximate scaling:

The Siemens S7-400H manual states that H-redundant communication is typically only 2–3× slower than SOLO mode. The observed ratios of 5–9× for S7 Communication and 20–30× for ISO Transport therefore indicate a misconfiguration, a missing firmware fix, or both.

2. Affected Hardware and Firmware Inventory

Capture the exact order numbers, hardware revision, and firmware version of every CPU, CP, and IM involved. The reported system consists of:

3. Root Cause Analysis

Several mutually-amplifying factors cause the observed 20–30× ISO Transport latency in H-redundant mode:

3.1 H-Redundancy Update Penalty on Connection Endpoints

In an S7-400H system, every TCP connection owned by the active CPU is mirrored on the standby CPU. When the master fails, the standby re-establishes the connections. The CP 443-1 running firmware V2.049 has a known connection-mirroring overhead, particularly for ISO Transport (RFC 1006) endpoints, that is reduced in newer firmware. Each ISO-on-TCP connection in H mode is internally maintained as a primary and shadow socket, doubling the per-connection handshake work.

3.2 Communication Load and OB1 Minimum Cycle Time Interaction

The configured communication load is 50 %, and the OB1 minimum cycle time has been raised from 5 ms to 35 ms. These two parameters interact non-linearly. The formula governing the effective share of OB1 given to communication is:

t_comm_max = OB1_min_cycle_time × (communication_load / 100)

With the reported values:

• t_comm_max = 35 ms × 0.50 = 17.5 ms per OB1 pass

Forty-one AS connections plus the internal H-sync traffic must share that 17.5 ms window. The lower-priority ISO Transport paths are scheduled behind higher-priority S7 Communication and the H-sync frames. If the AS-side CP also has a small send buffer, the AGSend call blocks until the buffer drains, and the DONE bit is delayed by several OB1 cycles. The 1,500 ms result is consistent with ~43 OB1 passes of 35 ms each.

3.3 Missing AG_SSEND/AG_SRECV Optimization

Standard AG_SEND / AG_RECV block pairs run on the OB1 priority and are time-sliced by the communication load share. Siemens documents an optimized variant — AG_SSEND / AG_SRECV (SPEED SEND/RECEIVE) — that bypasses the OB1 time-slicing for transmission within an S7-400 station, reducing latency and jitter. The trade-off is that the SPEED blocks occupy the bus for the full send duration, so they must be used only on dedicated, high-priority connections.

3.4 Connection Type Mismatch on the CP 443-1

The CP 443-1 (6GK7 443-1EX20-0EX0) supports a fixed number of ISO-on-TCP connections simultaneously. The hardware limit is 64 connections for the EX20 variant. With 14 active ISO-on-TCP connections plus H-mirroring, you are well under the hardware limit, but the configured connection resources (PG/OP, S7, ISO, TCP) and the CP's internal job queue still have to be sized correctly. The BSEND/AG_SEND jobs from the S7-Communication partners are running in the higher-priority S7 connection class and pre-empt the ISO Transport jobs.

4. Diagnostic Procedure

Run the following sequence before changing firmware or block calls. Each step is non-destructive.

1. Read the CPU diagnostic buffer. Connect via STEP 7 and inspect both the active and standby CPU 417-4H. Filter for events of class "Communication" and "CP fault". Note any "Connection abort", "Resource shortage", or "Send buffer overflow" entries with their timestamps.
2. Read the CP 443-1 diagnostic buffer. From STEP 7, open the CP under the active CPU, select "Diagnostic", and dump the buffer. Pay attention to "Connection status" events and any "Send retry" counters on the 14 ISO-on-TCP endpoints.
3. Measure per-connection cycle time with AGSend/AGRecv status outputs. Capture the DONE, ERROR, STATUS outputs of AG_SEND and AG_RECV in a watch table. Status word W#16#0001 (job active) and W#16#0000 (job complete with no error) are the most common values. A status of W#16#8083 / W#16#8084 indicates a temporary resource problem; W#16#80C3 / W#16#80C4 indicates send/receive buffer problems.
4. Switch to SOLO mode and re-measure. Stop the standby CPU and run the same AGSend/AGRecv tests. The ratio between H-mode and SOLO-mode latency should drop to 2–3× after the firmware and optimization steps below.
5. Inspect PC station load. Open the STEP 7 "Mode — Online — Connection Status" view and sort by "Load" to identify whether the 14 ISO-on-TCP connections are sharing the CP's job queue with the 27 S7 connections.

5. Solution Path 1 — Firmware Update on CPU 417-4H

The reported CPU firmware V4.5 is two service packs behind the current V4.5.3. The update must be applied in steps:

1. Download the V4.5.1, V4.5.2, and V4.5.3 firmware files from the Siemens Online Support entry for the 6ES7 417-4HT14-0AB0.
2. In the H-station, take the standby CPU offline using the H-system console ("Update firmware — Standby").
3. Apply V4.5.1 to the standby, wait for it to come back RUN-redundant, then perform a master/standby switchover.
4. Update the new standby from V4.5.1 → V4.5.2 → V4.5.3 in the same way.
5. Verify with the diagnostic buffer that the firmware is V4.5.3 on both CPUs and that H-sync is healthy.

6. Solution Path 2 — Switch the 14 ISO Connections to AG_SSEND / AG_SRECV

For the 14 ISO-on-TCP connections that are running slow, replace the standard AG_SEND / AG_RECV blocks in the user program with AG_SSEND / AG_SRECV from the STEP 7 standard library path "Standard Library — Communication Blocks — SPEED SEND/RECV". The block interface differs:

A minimal call example in STL for AG_SSEND (FB 56) on an OB 35 interrupt:

// Trigger AG_SSEND on the ISO-on-TCP connection "ISO_TO_416F2_07"
// DB700 holds the send buffer (200 bytes), DBW0 = request edge bit
CALL  FC 56  // AG_SSEND
  ACT      :=TRUE
  ID       :=W#16#0007   // connection ID 7
  LEN      :=200          // 200 byte payload
  DONE     :=M 700.0     // 1 = complete, 1 cycle
  ERROR    :=M 700.1
  STATUS   :=MW 702
  SEND     :=P#DB700.DBX0.0 BYTE 200
  BUSY     :=M 700.2

AG_SSEND only allows the next call after the previous one has returned DONE or ERROR. The BUSY bit must be checked before re-arming, otherwise the block returns STATUS = W#16#80C3 (job still active).

7. Solution Path 3 — Reallocate the 14 Slow Connections Back to S7 Communication

If firmware and AG_SSEND do not bring the ratio down to the documented 2–3× band, the simplest engineering fix is to migrate the 14 ISO-on-TCP partners to S7 Communication. S7 Communication has dedicated high-priority connection resources on the CP 443-1 and runs through the same S7 function calls (PUT / GET / BSEND / BRCV) that are already serving the other 27 partners.

Resource budget after migration:

• Total S7 Communication connections: 27 + 14 = 41 (each partner). The CPU 417-4H supports 128 S7 Communication connections; the CP 443-1 EX20 supports 64 of those to be routed externally — still well under the limit.
• ISO-on-TCP connections: 0, freeing the EX20's reserved ISO connection class.

The only code change required is replacing the AG_SEND/AG_RECV calls against the 14 partner connections with BSEND/BRCV (FB 12 / FB 13) or PUT/GET (FB 14 / FB 15) calls. The 200-byte payload fits inside a single BSEND frame (max 32 KB), so no application segmentation is needed.

8. Connection and Resource Limits to Verify

Before applying any of the solutions above, confirm the station is not already at a resource limit:

The combined H-mirrored total of 82 connections is well inside the CPU 417-4H's 128-connection ceiling, so the latency is not a connection-count shortage.

9. Verification Procedure After the Fix

1. Bring the H-station back into full redundancy. Confirm in the H-system console that both CPUs show "RUN — Redundant" and the H-sync LEDs (IFM, IFM1F) are green on the active and standby IM 153-2 / Y-link.
2. Force a master/standby switchover with the H-system console "Stop — Master". Measure the same 200-byte AGSend cycle on a single ISO-on-TCP partner. The latency should remain within 2–3× of the pre-switchover value if the fix is correct.
3. Re-measure the 14 ISO-on-TCP AGSend cycles in H-redundant mode. Compare to the SOLO-mode baseline (35–70 ms). The expected range is 70–250 ms after the AG_SSEND migration, or 100–210 ms after the S7 Communication migration.
4. Capture the CP 443-1 connection statistics via STEP 7 "CP Diagnostics — Connection Statistics". Verify that the "Send retries" counter is near zero and that the "Send buffer full" counter has not incremented in the last 24 hours.
5. Run the same event-driven triggers used in production (e.g., a piece of process data on a recipe change) and confirm that the DONE bit of AG_SEND/AG_SSEND returns within the expected window for at least 1,000 consecutive cycles.

10. When to Escalate to Siemens International Customer Support

If, after applying firmware V4.5.3 and migrating the 14 ISO-on-TCP connections to AG_SSEND (or to S7 Communication), the H-redundant latency ratio still exceeds 5× the SOLO baseline, escalate with the following package:

• CPU 417-4H order number, hardware revision, and firmware version (read from the online diagnostic buffer, not the project offline view).
• CP 443-1 order number, hardware revision, and firmware version.
• Project archive (compressed, no source code) containing the H-station and one representative S7-416F2 partner.
• Diagnostic buffer dumps of both CPUs and both CPs.
• Watch table capture of AG_SEND DONE/ERROR/STATUS for one slow connection over 100 consecutive triggers in H-redundant and SOLO mode.
• The H-system log file (H-system console — Log — Save).

This is the minimum data set that Siemens specialist support requires to reproduce the configuration in the lab. The combination of a 41-partner fan-out, mixed connection types, and raised OB1 minimum cycle time is not a stock support case, so attaching the project archive is the difference between a quick resolution and a multi-week back-and-forth.

11. Preventive Recommendations for Future S7-400H Stations

• Prefer S7 Communication (BSEND/BRCV) over ISO Transport (AG_SEND/AG_RECV) on S7-400H stations. The internal priority class and connection resource handling on the CP 443-1 favor S7 Communication in H-redundant mode.
• Reserve AG_SSEND/AG_SRECV for the handful of connections that must meet hard cycle-time targets. Do not blanket-deploy SPEED blocks; they consume the bus for the full send duration.
• Keep OB1 minimum cycle time as low as the application allows. Raising it to 35 ms to "make room for communication" often creates the latency problem the change was meant to solve, because it widens the OB1 time-slicing window for every job.
• Lock the firmware version of every CPU and CP at the latest available service pack at project commissioning. Document the firmware version in the project documentation and re-check it on every hot-fix window.
• Run the diagnostic buffer comparison at every master/standby switchover test. A switchover is the cheapest, fastest load test of H-redundancy-correct communication and exposes connection-mirroring bugs immediately.

12. FAQ