Configuring CP 343-1 TCP Connections at Runtime with FB55

Overview: The Runtime Configuration Challenge

On a SIMATIC S7-300 station fitted with a CP 343-1 (for example 6GK7 343-1EX30-0XE0, -1GX30-0XE0, or the IT variant 6GK7 343-1CX00-0XE0), the standard way to establish TCP communication is to pre-configure one or more ISO-on-TCP / TCP / UDP connections in NCM S7 / STEP 7 (NetPro) and bind them to the Send/Receive interface of the CP. In many field scenarios the engineer must change the partner IP address, subnet, or even rebuild connections without owning the engineering station, so the project team needs to do it from inside the CPU program using FB55 "IP_CONFIG".

This reference consolidates the official Siemens documentation (entry 8777865 — S7-CPs for Industrial Ethernet: Configuring and Commissioning) with the IP_CONFIG notes published in the Siemens Industry Online Support (entry 19316787) and the S7-CP runtime configuration FAQ (entry 21738745), and pairs them with a .NET partner that uses the System.Net.Sockets TcpClient / TcpListener classes on the application side. The result is a single end-to-end procedure that takes the S7-300 from a freshly powered CP to a verified runtime TCP exchange.

Prerequisites

CP 343-1 Communication Architecture

The CP 343-1 is a passive IO module from the CPU's perspective. It owns its own firmware stack and MAC/IP layer, and exposes a Send/Receive interface to the user program through internal dual-port memory. Three logical layers are involved when establishing a runtime TCP connection:

1. Layer 1 — IP parameters (MAC, IPv4, subnet mask, default router). These can be reloaded at runtime through FB55 "IP_CONFIG".
2. Layer 2 — Connection objects (one per partner, with type TCP / ISO-on-TCP / UDP and local/remote TSAP or port). These are stored in the CP's connection DB; they are normally downloaded from STEP 7 NetPro, but FB55 alone does not add new entries.
3. Layer 3 — Data exchange via the Send/Receive FBs (FC5 AG_SEND, FC6 AG_RECV, FC10 AG_CNTRL on the classic interface; FC50 AG_LSEND, FC60 AG_LRECV, FC62 AG_CNTRL on the extended / "lean" interface).

Because the connection objects themselves are CP firmware-resident, the practical "programmatic creation" workflow is: pre-define a free connection in NetPro (e.g. connection #1 and #2) without an active partner, set their partner parameters to "IP address is read at runtime via IP_CONFIG", and then push the partner IP into the CP with FB55 to light up the connection.

FB55 "IP_CONFIG" — Block Interface

FB55 is a synchronously called function block that performs a one-shot download of the configuration record to the CP. Each call uses a static instance DB (e.g. DB55) for the control data. The block interface is summarised below.

Typical Config UDT fields (declared in the instance DB or in a separate DB):

TYPE UDT_IPConfig
  STRUCT
    MAC    : ARRAY[1..6] OF BYTE;  // 08-00-06-AB-CD-EF
    IP     : ARRAY[1..4] OF BYTE;  // 192.168.0.10
    Subnet : ARRAY[1..4] OF BYTE;  // 255.255.255.0
    Gateway: ARRAY[1..4] OF BYTE;  // 192.168.0.1
  END_STRUCT;
END_TYPE

STEP 7 Project Pre-Configuration (NetPro)

1. Open HW Config and place the CP 343-1. Set its logical base address (e.g. 256) — this becomes the LADDR input for FB55.
2. Open the CP properties dialog, tab "Options" (or "Operating Mode"), and tick "IP address can be set via the user program (FB55)". Save and download to the CPU.
3. Switch to NetPro. Insert a new TCP or ISO-on-TCP connection from the CP to the partner, or use an existing free connection slot. In the partner properties, set the partner IP field to "Set by user program (FB55) / fetched at connection setup" — the checkbox name varies between STEP 7 versions, but the effect is the same: the CP will resolve the partner at runtime.
4. Compile and download the connection configuration. Verify in NetPro that the connection is in state "Established" only after FB55 has been executed with the matching partner IP.

Step-by-Step: Calling FB55 from SCL / STL

The block is one-shot: it must be called with rising edge on a trigger tag, polled until BUSY = FALSE, and only then retriggered. The pattern below uses SCL in STEP 7 V5.5.

// Trigger from any HMI tag or sequence bit
IF "Trigger_Apply" AND NOT "Apply_HasRun" THEN
    "Apply_HasRun" := TRUE;
    "iDB_IP_Config".SS_MAC   := FALSE;     // keep the factory MAC
    "iDB_IP_Config".SS_IP    := TRUE;
    "iDB_IP_Config".SS_SUBN  := TRUE;
    "iDB_IP_Config".SS_GATE  := TRUE;
    "iDB_IP_Config".LADDR    := W#16#100;  // CP base address 256
END_IF;

// Cyclic call to FB55 (instance DB "iDB_IP_Config")
FB55_DB55(
    LADDR    := "iDB_IP_Config".LADDR,
    SS_MAC   := "iDB_IP_Config".SS_MAC,
    SS_IP    := "iDB_IP_Config".SS_IP,
    SS_SUBN  := "iDB_IP_Config".SS_SUBN,
    SS_GATE  := "iDB_IP_Config".SS_GATE,
    Config   := "UDT_IPConfig_DB".PartnerSet,
    BUSY     => "iDB_IP_Config".BUSY,
    DONE     => "iDB_IP_Config".DONE,
    ERROR    => "iDB_IP_Config".ERROR,
    STATUS   => "iDB_IP_Config".STATUS
);

IF "iDB_IP_Config".DONE THEN
    "CP_Configured" := TRUE;
    "Apply_HasRun"  := FALSE;     // arm for next trigger
END_IF;

IF "iDB_IP_Config".ERROR THEN
    "ConfigFault" := TRUE;
    "ConfigFaultStatus" := "iDB_IP_Config".STATUS;
    "Apply_HasRun" := FALSE;
END_IF;

STL equivalent for older projects:

AN    "Trigger_Apply_HasRun"
A     "Trigger_Apply"
S     "Trigger_Apply_HasRun"
R     "CP_Configured"
// Load the Config data area into the FB55 instance DB
L     W#16#0          // set up the Config fields in DB 100
T     DB100.DBW 0
...

Send/Receive Interface (AG_SEND / AG_RECV)

After FB55 returns DONE, the CP will (within 1–3 s) resolve the configured Send/Receive connection with the new partner IP. Data exchange is then driven by the AG blocks (FC5, FC6, FC10) on the configured connection ID.

For TCP, the SEND/RECV user data length is up to 8192 bytes per call; for ISO-on-TCP it is up to 1452 bytes. Always evaluate NDR / DONE separately from ERROR. The connection ID must match the one shown in NetPro for the connection whose partner is fed by FB55.

Partner-Side Implementation (.NET 6+)

Once the S7-300 has the new partner IP, the listening end is typically a .NET service. Microsoft's TcpClient and TcpListener classes provide the sockets plumbing. A minimal C# listener that accepts a Send/Receive connection from a CP 343-1 looks like this:

using System.Net;
using System.Net.Sockets;
using System.Threading;

var listener = new TcpListener(IPAddress.Any, 2500);
listener.Start();
Console.WriteLine("CP 343-1 listener up on 0.0.0.0:2500");

while (true)
{
    using var client = await listener.AcceptTcpClientAsync();
    using var stream  = client.GetStream();
    var buf = new byte[8192];
    int n;
    while ((n = await stream.ReadAsync(buf)) > 0)
    {
        Console.WriteLine($"RX {n} bytes from {client.Client.RemoteEndPoint}");
        await stream.WriteAsync(buf, 0, n);  // simple echo
    }
}

Confirm the firewall on the partner host allows inbound TCP on the configured port (default 2500 for CP 343-1 TCP connections, but explicitly configured in NetPro). When the CP connects, the remote endpoint will appear as the CP's runtime IP; verify it matches the value pushed by FB55.

Error Codes and Diagnostics

For a deeper trace, open SIMATIC Manager → "CP diagnostics" or use the NCM S7 "Online → Diagnostic Buffer" entries on the CP. Each IP_CONFIG run leaves an entry that records the source (LADDR) and the resulting IPv4 / MAC.

Verification Procedure

1. In STEP 7, open "Online → Accessible Nodes" and verify the CP responds on the new IP address within 30 s of the FB55 DONE pulse.
2. In NetPro, right-click the connection and choose "Connection status" — it must report "Established" with the partner IP that was written by FB55.
3. From the partner, ping the CP. The ICMP echo must succeed. If the CP is in a different subnet, ensure the gateway was set (SS_GATE = TRUE with a non-zero Gateway).
4. Send a test frame with the .NET TcpClient and confirm AG_RECV on the S7 side raises NDR with the correct byte count. The turnaround is typically 50–250 ms on a 100 Mb/s link.
5. Force a CP fault by unplugging the Ethernet cable. AG_CNTRL with CMD = 0 (status only) should now return a non-zero STATUS. Re-plug the cable, wait 10 s, and verify the connection auto-restores without an FB55 retrigger.

Edge Cases and Field-Proven Caveats

• Factory reset behaviour: If the CP is power-cycled, the runtime IP pushed by FB55 is lost — the CP falls back to the STEP 7 default. Re-execute FB55 in OB100 (warm restart) if the IP must survive reboots.
• CP 343-1 Lean vs CP 343-1: The Lean variants (6GK7 343-1CX0x) have a reduced connection budget and may not support the same number of "free" runtime-resolved connections as the full CP 343-1. Refer to the CP's manual for the connection limit and the maximum number of AG_SEND calls per scan.
• Multiple CPs: Each CP gets its own FB55 instance DB. LADDR must match the CP's logical base address. Do not call the same instance for two CPs.
• Subnet boundary: Writing an IP that does not match the supplied Subnet is silently rejected (the CP keeps the old IP). Validate the host bits of the IP against the subnet before the call.
• Watchdog on FB55: If the block is held BUSY for more than the CP's internal timeout (default 10 s), the CP cancels the job and returns STATUS W#16#80A7. Always use a watchdog timer in the S7 program.

Recommended Practice Summary

• Pre-define all Send/Receive connections in NetPro; never rely on FB55 to add new connection objects.
• Use FB55 only to push IP/transport parameters to the CP for an already-existing connection.
• Call FB55 once at start-up (OB100) and on demand (HMI trigger); never call it from a fast OB1 loop.
• Mirror the partner IP into a watch tag and feed it into the partner TcpListener / TcpClient as a runtime parameter, so the .NET side can follow the CP's address changes.
• Always confirm the HW Config checkbox for FB55-controlled IP addressing is set before the CP is downloaded.

FAQ