PROFINET Diagnostics and Topology: What's Really Going On

PROFINET diagnostics sit in the strongest tier among mainstream industrial fieldbuses, because they can locate down to port level: with the LLDP neighbour-discovery protocol, the controller knows who is connected to every port of every device. Comparing the actual topology with the configured topology, a broken cable, a wrong port or a neighbour mismatch can be pointed to directly. But this capability has a premise — topology configuration must be done. On a PROFINET network without topology, diagnostics fall back to the coarse grain of "a station has dropped". This article covers the 199PROFINET series; for configuration basics see PROFINET Basics: IRT and Device Name Assignment.

Topology configuration: the basis of diagnostics and replacement without programming

Topology configuration is drawing, in the engineering software, "which port connects to which port". Once done, three things follow:

• Port-level fault location: the alarm will state directly that "the link between port 2 of device A and port 1 of device B is interrupted", rather than a generic station fault.
• Device replacement without programming: after a new device is connected, the controller judges from its neighbour relationships which unit it ought to be, writes the device name automatically and downloads parameters. Replacing a sensor in the field does not require an engineering laptop — a high-value capability in production-equipment maintenance.
• Wiring errors are exposed early: plugging a cable into the wrong port makes the controller report a neighbour mismatch immediately, rather than waiting for odd behaviour in operation.

The cost is that the topology is frozen: any cable change must be accompanied by a configuration change and a download. In IRT mode the topology lock is stricter still, because time-slot scheduling depends on a determined transmission path. This trade-off should be decided at the design stage; see the choice between RT and IRT.

Three layers of diagnostic information

The recommended troubleshooting order is from the bottom up: first see whether the network layer has a link problem, then whether the station layer can establish a connection normally, and only then look at module-layer internal diagnostics. Starting the other way round with device fault codes often finds that the root cause was only a cable.

Frequent faults and how to handle them

A common mistaken question about terminating resistors

Engineers often ask: "Do both ends of a PROFINET segment need 120 Ω terminating resistors?" The answer is no. Terminating resistors are a requirement of bus-type physical layers such as CAN and RS-485 — several nodes hang on the same differential pair, so both ends must be impedance-matched to absorb reflections. PROFINET and EtherCAT are based on standard Ethernet and use a point-to-point link + switching/forwarding structure; each cable segment connects only two ports, impedance matching is provided by the PHY transformers and the cable specification, and there is no bus-reflection problem.

The direct consequence of mixing up the concepts is: putting resistors in series on an Ethernet port, or omitting termination on a CAN segment. For the differing matching requirements of the two physical layers see Terminating Resistors and Bus Length: Why It Has to Be 120 Ω. What really has to be controlled on the Ethernet side is single-segment cable length, cable category and shield treatment; over-long runs should switch to fibre or add a switch as a repeater.

For systematic troubleshooting of shield earthing and interference see Troubleshooting Fieldbus Interference: Grounding, Shielding, Topology; for general sensor-side fault criteria see Troubleshooting Magnetostrictive Displacement Sensors: Inaccurate Readings, Jumps, No Output; for product parameters see Series 199 PROFINET Explained; for a cross-protocol comparison see Comparing the Whole Fieldbus Range.