Radio Telemetry: Use CPU PN Ports, Not CP 443

Which interface carries the cross-site link?

Follow the packet. A value leaves the master CPU of station A through the integrated PROFINET interface, crosses the local switch, enters the Ethernet port of the radio modem, occupies air time over the 10 km hop, lands on the far radio, crosses the switch at station B and terminates in the master CPU there. Nothing on that path requires a communications processor. The integrated PN interfaces on the are S7 communication endpoints in their own right. A CP 443-1 pair on the redundant rails is an option that buys specific things, not a prerequisite for the link.

The radio equipment carries no vendor requirement. The telemetry path only has to deliver IP unicast in both directions with a stable MTU and low enough packet loss; any transparent bridge or router that meets that will do. What must be true is that the two stations can reach each other at Layer 3.

One boundary matters more than the interface choice: the redundancy of each H station is local. The two CPUs of one station synchronise through fibre-optic sync modules inside the station itself, and that synchronisation never travels over the telemetry path. Splitting the two racks of a single H system across 10 km is a different project — dedicated long-distance sync modules on dedicated single-mode fibre — and the maximum span comes from the sync module technical data, not from the radio datasheet.

CPU PN port or CP 443: what separates them?

Start with the CPU PN ports. Three findings justify adding the CPs afterwards, and only those three: NetPro refuses to build a fault-tolerant S7 connection over the integrated interfaces in your STEP 7 version; the CPU connection resource count is already consumed by PROFINET IO, HMI and PG connections; or the CPU interface is already loaded with local PROFINET IO and you want the WAN traffic off it. Read the CPU's maximum S7 connection resources from its technical data and subtract what is already configured before deciding.

When NetPro does build the fault-tolerant connection, it creates one partial connection per usable interface pair between the two H stations. Read the count NetPro displays — that number, not the module type, is what tells you the link survives a redundancy switchover.

Why does PROFINET IO stop at the radio hop?

Two separate mechanisms kill it. PROFINET RT frames are Layer 2 with Ethertype and no IP header — a router will not forward them at all. Even across a fully transparent Layer 2 radio bridge, the IO watchdog is the update time multiplied by the accepted number of missed update cycles, which lands in the low milliseconds. A 10 km RF hop delivers jitter and burst loss orders of magnitude above that. The controller will drop the device and the station will go into IO fault on the first fade.

DCP, the discovery protocol behind "Accessible nodes" and PN device naming, is also Layer 2 multicast. It does not cross a routed hop and is worth filtering even across a bridged one. Plan engineering access over IP or S7 routing instead, and never name or commission a remote PN device through the radio.

TCP/102, or open user communication over TCP or UDP. Those tolerate retransmission and hundreds of milliseconds of RTT; PROFINET IO does not.

Layer one first: what to prove before opening NetPro

1. Read the Ethernet counters on both radios and both switches. Speed and duplex must match at each end. Any CRC errors or late collisions after an hour of traffic are a cabling or duplex fault — fix them before touching the PLC configuration.
2. Check surge protection and bonding on the antenna feed and on the Ethernet run to the radio. The radio is the first thing a strike finds.
3. Establish the path MTU. Send an unfragmented ping with a 1472-byte payload. If it fails, the radio path is below 1500 bytes — record the real value, keep telegram lengths under it or enable MSS clamping on the radio.
4. If the radios bridge at Layer 2, mirror a port and count broadcast and multicast frames crossing the RF hop. Air time spent on flooded broadcasts is air time your process data does not get.

Configuring the two stations

Decide the radio's forwarding mode first, because it fixes the addressing.

For a 10 km telemetry hop, route. It keeps the broadcast domain local and makes the traffic that crosses the air explicit.

1. Assign IP address, mask and gateway on the integrated PN interface of every CPU — both racks at both stations, four addresses in a distinct block per site. Download to both racks.
2. Prove TCP/102 reachability from a laptop on each site's subnet to each remote CPU address before opening NetPro. If the socket does not open, the problem is the radio, not STEP 7.
3. In NetPro, insert the partner H station and create the connection between the two stations. Select the fault-tolerant S7 connection type if the list offers it, and note the local ID for the block calls.
4. Program the exchange with SFB12 BSEND / SFB13 BRCV for block-oriented data, or SFB8 USEND / SFB9 URCV for short unacknowledged updates. If you use open user communication instead of a configured S7 connection, use FB65 TCON, FB63 TSEND, FB64 TRCV and FB66 TDISCON.
5. Add an application heartbeat in each direction — an incrementing counter and a timeout sized from the logged worst-case RTT plus margin for a redundancy switchover. Seconds, not milliseconds.
6. Synchronise time across the link so alarms from both sites timestamp consistently.
7. Define the fail-safe behaviour explicitly: remote values marked stale on timeout, no latched outputs derived from a stale value.

Verification and the failures that repeat on this link

Four failure modes account for most of the callbacks on cross-site H links: a plain S7 connection where a fault-tolerant one was intended, so every master/standby changeover drops the data; an attempt to run PROFINET IO or a PG discovery across the hop; a bridged radio saturated by broadcast traffic that only shows up under plant load; and an application that latches on the last received value instead of flagging it stale. Test for all four before handover.

1. Open the connection status in NetPro at both stations. Every partial connection must show as established, not just one.
2. Force a redundancy switchover at station A and watch the heartbeat at station B. A fault-tolerant connection carries through; a plain S7 connection drops and re-establishes. Log the gap and compare it against your timeout.
3. Remove one rack at each station in turn. The connection must stay up on the surviving CPU.
4. Interrupt the RF path. Confirm the timeout fires at the designed time, stale flags set, outputs go to their defined state. Restore the path and confirm the connection re-establishes with no manual reset.
5. Read the diagnostic buffer of all four CPUs after the soak. No communication error entries, and no unexplained redundancy events, closes the job.

FAQ