Configuring Removable PROFINET Connections Between ET200S CPUs

Problem Overview

Engineers deploying two autonomous machines—each built around a Siemens ET 200S CPU with its own dedicated PROFINET network—frequently need to couple the two controllers temporarily so they can exchange status, hand off product, or coordinate shared resources. Because the units are mobile, the PROFINET cable between the two CPUs is only present intermittently. The recurring engineering question is: "If I download a hardware configuration that references the partner CPU, won't the PROFINET controller raise a station failure alarm on every power-up when the partner CPU is not reachable?"

The answer is: it depends on how the connection is modeled. A direct PROFINET IO controller-to-controller relationship (where one CPU acts as a PROFINET IO device of the other) does indeed raise diagnostics, because the IO controller polls its IO devices cyclically and any absent device produces a station-fault message. A pure PN/PN coupler, an S7 connection over PROFINET, or an Open Communication (TCP/ISO-on-TCP) link does not produce that fault, because the connection is established and released programmatically through the user program rather than by the PROFINET IO system.

ET 200S CPU Variants and PROFINET Capability

The "ET 200S CPU" is the IM 151-8 PN/DP interface module with an integrated CPU, used as a distributed automation station. Variants in the ET 200S family relevant to PROFINET communication include:

The IM 151-8 PN/DP supports the PROFINET IO controller role on its X1 port and provides standard PROFINET communication services including S7 communication, open TCP/UDP, ISO-on-TCP, and PROFINET CBA (where licensed). The X2 port can be configured for either PROFINET or PROFIBUS DP master operation.

PROFINET Communication Services Available

Siemens SIMATIC controllers expose several communication services that can ride on a PROFINET physical connection. The relevant subset for the two-CPU scenario is:

For an intermittent mobile link, S7 communication (PUT/GET or BSEND/BRCV) or Open Communication (TCON/TDISCON) is the right choice. PROFINET IO controller-to-controller would lock out the partner whenever the cable is missing, so it should not be used for this scenario.

Why the "Missing Device" Fault Happens

When a PROFINET IO controller is configured with an IO device, the controller's PROFINET stack runs a cyclic device watchdog. The default behavior in STEP 7 / TIA Portal is:

1. Controller sends AR (Application Relationship) setup request to device IP.
2. Device responds with its real-time slot configuration.
3. Controller begins cyclic IRT/RT frame exchange on the configured send clock (typically 1 ms).
4. If the controller does not receive valid responses for the configured number of failed update cycles (default 3), it raises station failure (SF) and stops updating the process image for that device.

The SF LED on the CPU, the diagnostic buffer entry "Station failure", and the system error in OB 82 / OB 86 are all consequences. Even if you suppress the OB 86 call, the I/O data simply stops updating. This is unacceptable for safety or coordination functions, and the diagnostic noise is unacceptable for commissioning.

Network Topology for the Mobile Link

The recommended topology separates the two machine networks and brings them together only through a dedicated patch cable or industrial wireless link:

Inline SVG (ASCII representation; replace with rendered SVG in production):

[Machine A ET200S CPU #1]                [Machine B ET200S CPU #2]
   |                                            |
   | PROFINET Subnet A                          | PROFINET Subnet B
   | (192.168.0.0/24)                           | (192.168.1.0/24)
   |                                            |
   |  X1 PN port (IO controller)                |  X1 PN port (IO controller)
   |                                            |
   +---- Mobile / patch cable (when docked) ----+
                  ^
                  |
              Plugged only when units are
              physically connected

When the cable is absent, the second network interface on each CPU (or a dedicated X2 port configured for cross-machine communication) is the one that loses its neighbor. The standard PROFINET IO on subnet A or B is unaffected.

Hardware and Software Prerequisites

• Two IM 151-8 PN/DP (or compatible) CPUs with firmware ≥ V3.0 (V3.0 is the first firmware that supports the full TCON family in the ET 200S family).
• STEP 7 V5.5 + SP4 (or later) for the ET 200S CPU configuration, or TIA Portal V13 SP1 or later (V20 referenced in the official TIA Portal V20 ET 200S configuration documentation).
• Available Standard library blocks (SFB/FB for TCON, TDISCON, TSEND, TRCV) — these are in the Standard Library / Communication Blocks under "Open Communication".
• IP addresses assigned to the cross-link port on each CPU. Static addresses are strongly recommended for deterministic behavior. PROFINET DCP-based naming is acceptable if the partner's PROFINET device name is preserved in the project.
• A PROFINET cable (or industrial Ethernet cable, since the cross-link uses standard Ethernet framing) long enough to span the docked distance, or a wireless bridge pair with PROFINET-compatible behavior (note: PROFINET IO over wireless is not officially supported; open communication is).

Step-by-Step: TCON/TDISCON Implementation

The TCON family gives the application program explicit control over the connection lifecycle. This is the cleanest solution because the absence of a connection is handled in OB 1 / OB 100 logic, not by the PROFINET IO subsystem.

Step 1 — Configure the Cross-Link Port

In HW Config (STEP 7 V5.5) or the Devices & Networks editor (TIA Portal), open the IM 151-8 PN/DP properties. On the X1 port (or the second PN interface if you have a 2-port CPU), assign a fixed IP address in a separate subnet that is unique to the inter-CPU link:

Do not place any PROFINET IO device in this subnet. Leave it strictly as an "Ethernet" subnet for Open Communication. The PROFINET diagnostic system will not poll for IO devices on a plain Ethernet subnet.

Step 2 — Declare the Connection in the Hardware Configuration

In NetPro (STEP 7) or the Connections editor (TIA Portal), insert a new Open Communication (TCP) connection. The connection description stored in the connection DB (generated by NetPro or the Connections editor) contains the partner IP, local TSAP, and remote TSAP. For TCP, the local and remote ports are usually any free port > 1024; the TSAP concept is not used for raw TCP, but is used for ISO-on-TCP.

Step 3 — Add the Open Communication Blocks to the Symbol Table

From the Standard Library > Communication Blocks folder, copy the following FBs into your project (STEP 7 V5.x: copy from "Standard Library > Communication Blocks > Open Communication". TIA Portal: they ship in the system library and you instantiate them directly):

• FB 65 TCON — Establish connection. REQ rising edge triggers connect. ID = connection ID from NetPro. CONNECT = pointer to the generated connection DB (UDT 65 for TCP). DONE/BUSY/ERROR indicate status.
• FB 66 TDISCON — Terminate an established connection. Idempotent — calling on an already-disconnected connection returns ERROR=1 with STATUS=W#16#80A3 but does not crash the CPU.
• FB 63 TSEND — Send data over an established connection.
• FB 64 TRCV — Receive data. EN_R enables reception; RCVD_LEN reports the bytes actually received (important for variable-length protocols).

Step 4 — Write the Connection Lifecycle in OB 1

The pattern below shows an SCL/FB implementation that periodically attempts to connect, monitors the link, and tears down cleanly when the partner is gone. The key insight is to call TCON in OB 100 (warm restart) and on a cyclic retry timer; call TDISCON whenever the receive watchdog expires.

Step 5 — Suppress the IO-Device-Fault Path (If You Do Use PROFINET IO Cross-Link)

If a project constraint forces you to expose the partner CPU as a PROFINET IO device, you must handle OB 82 (diagnostic interrupt) and OB 86 (rack failure) gracefully. Insert the following "do-nothing" OBs to prevent the CPU from going into STOP:

Even with the OBs suppressed, the input process image for the missing IO device will hold its last value, so any safety or control function that depends on it will see stale data. The TCON-based approach above is the correct engineering solution; this OB-suppression approach is a workaround, not a fix.

Step 6 — Download and Commission

1. Compile the project. Resolve any "connection partner not assigned" warnings — these typically mean the IP routing between the two subnets is incomplete.
2. Download to CPU #1, then to CPU #2. Do not power-cycle during download.
3. Verify the cross-link port LEDs: Link (green, steady) and Activity (yellow, flashing) should both illuminate within 5 s of plugging the cable.
4. From CPU #1, monitor the diagnostic buffer (Online & Diagnostics > Diagnostic Buffer) for any "Connection established" / "Connection terminated" entries that match the TCON/TDISCON calls.
5. From CPU #2, do the same; the connection status must be visible in both directions.

Handling the "Cable Unplugged Mid-Session" Case

When the mobile units are undocked while a TCON connection is open, the following sequence happens inside the PROFINET stack:

1. Physical link drops (Link LED goes dark on both ports).
2. TCP keep-alive timer expires (default 30 s on SIMATIC, configurable). The CPU raises a connection-error event.
3. FB 64 TRCV returns RCVD_LEN = 0 and STATUS = W#16#80A1 (connection terminated by remote, or by the stack due to link loss).
4. Your application must call TDISCON_DB.REQ := TRUE on the next scan to clear the stack resources, then a TCON retry timer can begin a new establish attempt when the cable is reconnected.

TCON Status Word Reference

Diagnose issues by reading the STATUS output of TCON / TDISCON / TSEND / TRCV. Common values for the ET 200S CPU on PROFINET:

Alternative: S7 PUT/GET Communication

If the data exchange is purely a few variables (state, position, hand-off request), S7 communication may be simpler than open TCP. S7 PUT/GET rides on ISO-on-TCP (connection type 0x12) and is initiated by one side via SFB 14 / SFB 15 or the PUT / GET blocks (FB 14 / FB 15 in STEP 7 V5.x). The advantage is the S7 connection editor in NetPro handles the partner's slot and rack automatically. The disadvantage is the connection is more rigid: you cannot easily buffer a payload, and PUT/GET will not auto-retry on link loss. Apply the same lifecycle pattern: call PUT/GET only when the connection is "established".

To configure PUT/GET access rights on the partner CPU, the partner's "Permit access with PUT/GET from remote partner" option in the CPU properties > Protection > Connection mechanisms must be enabled. Without this, the S7 communication attempt returns STATUS W#16#80A1 with a partner-side rejection.

Verification Checklist

After commissioning, perform the following verification sequence on both CPUs:

Troubleshooting Matrix

Key Field-Proven Caveats

• When the ET 200S CPU's PROFINET port is shared between the local subnet and the cross-link, disable PROFINET IO on the cross-link port in the port properties. Otherwise the port will try to be an IO controller on the cross-link subnet, defeating the purpose of the isolated link.
• If the two CPUs sit on machines with different ground references, use an industrial Ethernet cable with built-in isolation, or insert a PROFINET switch with galvanic isolation on each side of the cross-link.
• For PROFINET IO controller-to-controller via a PN/PN coupler (6ES7158-3AD10-0XA0), the link is deterministic but the coupler itself must be powered and present. A PN/PN coupler is therefore a poor choice for a mobile link.
• Do not assign the cross-link port a PROFINET device name via DCP if you intend to use plain TCP. The DCP name lookup is irrelevant to TCP and may confuse the diagnostic tools.
• Update the IM 151-8 PN/DP firmware to at least V3.0.3 if you observe sporadic STATUS W#16#80C3 events under heavy PROFINET IO load; Siemens firmware notes for the IM 151-8 confirm the V3.0.3 release stabilized the TCP connection-establishment path.
• If you need PROFINET IO over a wireless bridge, confirm the bridge supports PROFINET IRT cut-through; a generic Wi-Fi bridge will not provide deterministic cycle times and the IO subsystem will fail on every scan.

Frequently Asked Questions