A PROFINET or PROFIBUS communication fault on a Siemens system is one of the most common calls we get, and one of the most commonly misdiagnosed. The reflex is to suspect the module. In practice the module is rarely the problem.
Below is the sequence we work through. It is ordered by how often each cause turns out to be responsible, weighted by how quickly it can be ruled out.
1. Read the diagnostic buffer first
Before touching cabling, go online and read the CPU diagnostic buffer. It carries time-stamped entries that tell you what the CPU saw and when. A station failure entry with a specific device number is worth more than an hour of cable checking.
Pay attention to whether the fault appeared once at start-up or repeats. A single entry at power-up usually means a device that is slow to boot. Repeating entries during production usually mean something physical or electrical.
2. Check whether the device is actually reachable
Use the online device view or a browse of accessible nodes. If the device appears but is not in the expected state, the problem is configuration. If it does not appear at all, the problem is physical — cabling, power, or address.
This single check splits the problem space in half and takes under a minute.
3. Look for a duplicated or changed device name
On PROFINET, devices are addressed by device name, not by IP alone. Replacing a failed module with a spare that still carries its previous name from another machine will produce exactly the symptoms of a cabling fault. This catches people constantly, and it is invisible unless you look for it.
Check the assigned name against the configured name in the hardware configuration. Also check that no two devices on the segment share a name or an IP address.
4. Then, and only then, look at the cabling
Physical faults are real but they are slower to investigate, which is why they belong here rather than at the top. Look at the connector first — a poorly terminated field-assembled RJ45 is more common than a damaged cable. Check whether the fault correlates with machine movement, which points at a cable in a drag chain.
Port statistics on a managed switch will show discarded and errored frames, which is the difference between a marginal link and a clean one. Unmanaged switches give you nothing here, which is one reason they are a poor economy on a machine network.
5. Consider electrical noise last
Noise is the answer people jump to and it is genuinely the cause less often than assumed. It becomes plausible when the fault correlates with a specific event — a large drive accelerating, a contactor pulling in, a welding operation. Check shield termination and whether the network cable is sharing a duct with motor cables. If the fault happens with the machine idle, noise is not your answer.
The general principle
Check what is cheap to check and eliminates the most possibilities first. The diagnostic buffer and an accessible-nodes browse take two minutes between them and will identify the cause in the majority of cases. Cabling investigation and noise hunting are hours of work, and they should be earned by eliminating everything else.