S7-400H CP443-1 TCP Communication Testing with AG_LSEND/AG_LRECV

Engineering Problem: Verifying Redundant TCP Native Logic

You have an S7-400H fault-tolerant PLC, two CP 443-1 communication processors, and a third-party DCS that talks to it over TCP using SIMATIC native "open" communication. The user program on each CPU uses AG_LSEND (FC50) and AG_LRECV (FC60) - one send/receive pair bound to CP-A, one pair bound to CP-B. The DCS mirrors that pattern so either side of the redundant pair can carry traffic at any moment.

The challenge: confirm the four send/receive jobs behave correctly under (a) normal operation, (b) link failure of CP-A, (c) full H-station fail-over to the backup CPU, and (d) duplicate-frame rejection, all before the real DCS is available. Standard Modbus simulators (Modsim, Modscan) cannot be used - the S7-400H emits raw open-TCP or ISO-on-TCP frames, not Modbus PDUs. You need a generic byte-level TCP server/client plus visibility into the FC50/FC60 status word and the CP443-1 connection table.

Redundant S7-400H TCP Native Architecture

The standard pattern for redundant native TCP between an S7-400H and a DCS is shown below. Two H-stations, each with a CPU 41x-H and a CP 443-1, are connected over a plant LAN to the DCS. The H-system keeps both CPUs memory-consistent via the sync fiber. Each CP443-1 opens its own TCP connection to the DCS (separate ports), and the application arbitrates which of the two received frames is "fresh."

Physical equipment you will see in HW Config (STEP 7 V5.5 / V5.6):

• CPU 414-4H (6ES7414-4HM14-0AB0), CPU 416-3H (6ES7416-3HS12-0AB0), or CPU 417-4H (6ES7417-4HT14-0AB0) in each H-station.
• CP 443-1 in each rack. Common order numbers: 6GK7443-1EX20-0XE0 (legacy single-port), 6GK7443-1EX30-0XE0 (multi-port), 6GK7443-1GX20-0XE0 (Gigabit, advanced IT functions), and the security variants 6GK7443-1EX40-0XE0 / 6GK7443-1EX50-0XE0.
• Sync modules and sync fiber between the two H-stations (subrack 0 in each).
• Ethernet switch infrastructure: the CP443-1 connects to a managed switch on the plant network; the DCS connects on the same subnet unless you are using a routed topology with a firewall.

The IP address plan in the example: CP-A = 192.168.10.11, CP-B = 192.168.10.12, DCS = 192.168.10.50. The CP-A and CP-B addresses are bound to the H-system's virtual MAC; the active CPU owns the ARP entry at any moment, but the CP443-1 module's IP is the one seen on the wire per H-station.

AG_LSEND (FC50) and AG_LRECV (FC60) Block Interface

FC50 and FC60 live in the SIMATIC_NET_CP library that ships with STEP 7. They are the supported open-TCP send/receive primitives for CP443-1 in STEP 7 V5.x; TIA Portal's TSEND_C/TRCV_C blocks are functionally similar but are only available in TIA Portal projects, and a STEP 7 V5.x program using FC50/FC60 cannot be transferred as-is.

Calling pattern in OB1 (STL):

CALL "AG_LSEND"  // FC50
 LADDR  := W#16#100   // CP443-1 #1 at HW address 256
 ID     := 1          // Connection ID 1
 SEND   := P#DB100.DBX0.0 BYTE 200
 LEN    := 200
 DONE   := M100.0
 ERROR  := M100.1
 STATUS := MW102
 BUSY   := M100.2

Calling pattern in OB1 for the receive (SCL):

AG_LRECV(
  LADDR  := W#16#100,
  ID     := 1,
  RECV   := P#DB110.DBX0.0 BYTE 200,
  LEN    := 200,
  NDR    := M110.0,
  ERROR  := M110.1,
  STATUS := MW112,
  BUSY   := M110.2
);

You repeat the same call template for the second CP443-1 by changing LADDR (e.g. W#16#0180 for CP-B at HW address 384) and a separate set of DONE/ERROR/STATUS/BUSY flags. The four send/receive jobs share the same DB areas only if you intend the application to treat both CP-A and CP-B as a single redundancy group; in practice, four separate DBs (DB100 for CP-A send, DB110 for CP-A receive, DB200 for CP-B send, DB210 for CP-B receive) keep the logic clean and let you see which frame arrived on which channel.

CP 443-1 Configuration for Open TCP

Open TCP on the CP443-1 is configured in NetPro by adding a "TCP connection" to the CP, then setting the partner (the DCS) as an unspecified / "other" partner and entering its IP address and remote port. The local port is chosen by the configuration tool (default 2000, but the CP increments it automatically for additional connections).

1. In HW Config, double-click the CP 443-1 and assign a unique IP address, e.g. 192.168.10.11 for CP-A and 192.168.10.12 for CP-B. Enable the "Use Router" option only if a router is on path.
2. In NetPro, right-click the CP and select Insert New Connection > TCP connection > Unspecified / other.
3. Configure the connection:
   • Local port: leave at default (the CP will pick the next free port starting at 2000; do not duplicate across CPs on the same H-station).
   • Partner address: 192.168.10.50 (the DCS).
   • Partner port: 2001 for the A-channel, 2002 for the B-channel - or whatever the DCS expects.
   • Connection name: CP443A_TCP_A and CP443B_TCP_B.
   • Connection ID: 1 and 2 (must be unique per CP - the IDs are per-CP-scoped, not project-wide).
4. Compile and download the connection table to both CPUs. In an H-system you must download to both H-stations; the S7-400H runtime keeps the connection table mirrored.
5. Set the operating mode of the CP to "RUN" (no PG/OP routing change required for open TCP, but the CP must not be in STOP).

If you are using ISO-on-TCP (RFC 1006) instead of plain open TCP, change the NetPro connection type to "ISO-on-TCP connection" and the CP443-1 will add the 4-byte TPKT header (length + 0x03 0x00) automatically. The FC50/FC60 interface does not change - the framing is handled by the CP. For plain open TCP the CP sends no header; the raw user data goes straight onto the wire. Wireshark with a tcp.port == 2001 filter will show the difference clearly.

Connection ID, Resource, and Port Allocation

For an S7-400H with two CP443-1 cards and a DCS partner that accepts two open-TCP sockets, the allocation looks like this:

On the H-master, both CPU 0 jobs are active. CPU 1 jobs run in the background and are kept in lock-step by the H-system; once a fail-over happens, the backup takes over both send/receive pairs without the user having to re-trigger. The CP443-1 in the H-backup does not open its own TCP connection during steady state - the connection is owned by the H-master's CP443-1; after fail-over the new master's CP443-1 re-opens it.

FC50/FC60 State Machine

The behavior of FC50 is dictated by a small state machine on the REQ, BUSY, DONE, and ERROR outputs. Understand this state machine before commissioning - the most common bugs in S7-400H TCP programs are violations of it (re-triggering while BUSY=1, missing the DONE edge, racing the H-system during fail-over).

FC60 has a similar shape, with NDR playing the role of DONE and no equivalent of "send complete" - the receive job is pending whenever BUSY=1. The recommended user pattern is:

// Trigger pattern (OB1)
IF NOT "busy_send_A" AND "send_request_A" THEN
   "AG_LSEND_A"(REQ := TRUE, ...);  // single-cycle pulse
ELSE
   "AG_LSEND_A"(REQ := FALSE, ...); // keep calling to read BUSY/DONE/ERROR
END_IF;

// Edge handling (OB1)
IF "done_send_A" THEN
   "send_request_A" := FALSE;
   "last_send_status_A" := "status_send_A";
END_IF;
IF "error_send_A" THEN
   "send_request_A" := FALSE;
   "last_error_code_A" := "status_send_A";
   // raise a maintenance alarm with "status_send_A"
END_IF;

FC50/FC60 Status and Error Code Reference

Before testing, memorize the STATUS codes that matter for open TCP. They are documented in the SIMATIC NET help and in the S7-400H / CP443-1 manual. The table below is the subset you will see in practice on native TCP / ISO-on-TCP with FC50/FC60.

Codes in the 80xx range that you do not recognize are usually reported directly in the CP443-1 diagnostic buffer. Open them with STEP 7 > PLC > Module Information on the CP443-1. The S7-400 buffer and the CP buffer are independent - read both; a 7000 on FC50 with a buffer entry "connection aborted by partner" still tells you the partner is the cause.

Simulating the DCS Partner: TCP Server/Client Tools

To test the four-block redundant logic, you need a raw TCP server and a raw TCP client on a PC (or two PCs). Avoid tools that hard-code a protocol on top of TCP - the S7-400H sends user-defined bytes, not Modbus, not S7-comm, not OPC UA. The following are useful.

For the typical setup, run two Hercules instances (or a small Python script) listening on TCP ports 2001 and 2002 - one for CP-A's connection, one for CP-B's connection. The CP443-1 will open both as active partner; the simulator acts as the passive server. Use Wireshark in parallel to capture and confirm frame contents.

A minimal Python test harness that emulates the DCS for one connection:

import socket, threading

def serve(port, replies):
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind(('0.0.0.0', port))
    s.listen(1)
    while True:
        conn, addr = s.accept()
        while True:
            data = conn.recv(8192)
            if not data: break
            conn.sendall(replies.pop(0) if replies else data)
        conn.close()

threading.Thread(target=serve, args=(2001, [b'\xAA'*200]*1000), daemon=True).start()
threading.Thread(target=serve, args=(2002, [b'\xBB'*200]*1000), daemon=True).start()
import time; time.sleep(3600)

If the CP443-1 is configured as the passive partner (it waits for an incoming connection), flip the test: use Hercules in TCP Client mode to dial the CP's IP and port, then watch FC60 receive the data. The active / passive role is fixed in NetPro by checking "Active connection establishment" on the local CP or on the partner - the source design has the CP as active.

Online Diagnostics in STEP 7

Three online views are the workhorse for troubleshooting FC50/FC60 on the CP443-1:

1. Module Information on the CP443-1. In SIMATIC Manager, right-click the CP443-1 in the project (online), choose PLC > Module Information. The "Diagnostics" tab lists connection state, the "Connection" tab shows established / aborted connections with their ID and partner IP/port, and the "Statistics" tab counts send/receive errors and link resets.
2. NetPro online view. In NetPro, right-click the configured TCP connection and select Connection Status. The status is reported as one of: Established, Not Established, Being Established, Being Aborted. The detail shows the local and remote port and the connection ID.
3. Watch table / VAT on FC50/FC60 outputs. Open a VAT in OB1 or attach a watch table to the FC50/FC60 instance environment and monitor DONE, ERROR, STATUS, BUSY, NDR (for FC60). This is the fastest way to capture transient STATUS codes during a fail-over test.

To force a fail-over during the test, use the S7-400H test panel: PLC > Operating Mode > Switch Over. This swaps the H-master to the backup CPU; the connections held by the CPs on the original master are torn down and rebuilt by the new master. Watch STATUS cycle through 7000 → 7001 → 7002 → 0000 (or an error) on both the FC50 and FC60 jobs.

Additional diagnostic tool, often forgotten: the CP443-1 has a web server that you can enable in HW Config. Point a browser at https://192.168.10.11 and you get a live view of the connection table, the system log, and the diagnostic buffer - useful when the PG is far away. Disable the web server in production or at least restrict it via the security settings on the 6GK7443-1EX50-0XE0 variants.

Test Procedure and Verification

1. Pre-flight. Confirm the CP443-1 module is in RUN (no SF / BF LED), the IP address and subnet match NetPro, and the partner IP (the simulator PC) is reachable: ping 192.168.10.50 from a PG on the same VLAN.
2. Stand up the simulator. Run two TCP listeners on ports 2001 and 2002 (Hercules / netcat / Python). Confirm the listener shows LISTEN state on both ports. Start Wireshark with a capture filter for tcp port 2001 or tcp port 2002 on the simulator PC's interface.
3. Bring up FC50 jobs. Trigger the two AG_LSEND calls in the H-master. In a VAT, watch STATUS for the expected sequence: 7001 (start) → 7002 (sending) → 0000 (done). Wireshark should show a TCP SYN from CP-A (port 2000) to 192.168.10.50:2001 and a payload of 200 bytes on DATA.
4. Bring up FC60 jobs. The simulator echoes a known reply payload (e.g. 200 bytes of 0xAA). Watch the two AG_LRECV calls: NDR should pulse for one PLC cycle, LEN should report the actual bytes received, and STATUS = 0000 on success.
5. Verify duplicate handling. With both CP-A and CP-B receiving the same echo payload from the simulator, the application should accept only one of them per scan - typically the one with the most-recent sequence number or timestamp. A simple test: send a payload with an embedded counter; verify the application increments its expected counter and discards the duplicate.
6. Simulate CP-A link loss. Unplug the Ethernet cable on CP-A (or shut its switch port). Watch the Wireshark capture for a TCP RST/FIN. FC60 on the CP-A pair should report STATUS = 80A1 (connection terminated by partner) or 80A3 (connection closed locally). The CP-B pair must continue to receive and the application must fall back to the CP-B data path.
7. Simulate H-station fail-over. From SIMATIC Manager trigger PLC > Operating Mode > Switch Over. The H-master and H-backup swap roles. Both CP443-1 jobs (originally on the old master) should now appear in the new master and re-establish their TCP connections - expect to see two TCP SYN packets in Wireshark and STATUS cycling 7000 → 7001 → 7002 → 0000.
8. Restore and confirm steady state. Reconnect the CP-A cable. Both pairs should show STATUS = 7000 (idle, connection established) and the application should re-enable the CP-A data path.
9. Capture evidence. Save the Wireshark trace, the VAT recordings, and the CP443-1 diagnostic buffer export as the commissioning record. Keep one capture per failure mode (link loss, H fail-over, partner abort) for the site acceptance test.

Troubleshooting Matrix

For the official FC50/FC60 description and the full status-code table, see the Siemens Industry Online Support entry for "AG_LSEND / AG_LRECV" in the SIMATIC NET CP library documentation, and the CP 443-1 manual on the same portal. For the S7-400H fail-over behavior and the switchover procedure, refer to the S7-400H Fault-Tolerant Systems manual, available on Siemens support under product support for S7-400H. SIMATIC product documentation is also reachable from Siemens SIMATIC product page.

Frequently Asked Questions