How to Diagnose PROFINET with LLDP Neighbors
PROFINET devices continuously tell each other who is plugged into which port using LLDP, and that neighbor data is the single most useful diagnostic on the network - it shows how the machine is actually cabled versus how the engineering says it should be. This page is for the engineer chasing a device that will not start, a topology mismatch, or a fast-startup that fails: it explains how to read LLDP neighbors, compare them to the planned topology, and pinpoint the wrong port or swapped cable.
PROFINET LLDP Diagnosis in one line: To diagnose PROFINET with LLDP neighbors, read each device's reported neighbor - the port name and device name of whatever is physically plugged into each of its ports - and compare that live neighborhood against the topology defined in the engineering. A mismatch names the exact port where the real cabling diverges from the plan, which is what blocks topology-based device replacement and fast startup. Fix the cabling or update the planned topology to match.
First Checks
Confirm the symptom points at topology. A device stuck in startup, a topology-mismatch diagnostic in the controller, or a device-replacement that fails to auto-assign a name are all classic signs that the physical cabling does not match the configured neighborhood. If instead you have random packet loss or jitter with correct topology, that is a different fault family. LLDP diagnosis is specifically for when the network is asking 'who is plugged in where' and getting an unexpected answer.
Read the controller's topology or neighborhood diagnostic first - most PROFINET controllers show detected topology graphically, drawing what LLDP actually reports. That view often exposes the problem immediately: a cable that should go from port 2 to the next device instead lands on port 1, or a device the plan expects is simply not seen. This ties into a full PROFINET device name mismatch workflow, since name and topology diagnostics frequently appear together.
Read Each Device's Reported Neighbor
LLDP works by every port periodically announcing its own identity - the device name and port name - and listening for the same from whatever is connected. So each device knows, per port, the name of its neighbor and which of the neighbor's ports it is talking to. Read this neighbor information from the device or the controller diagnostics: for each port you get the connected device name and the connected port. This is ground truth about the physical wiring, independent of what the engineering intended.
Walk the chain port by port. In a line topology, device A port 2 should report device B port 1 as its neighbor, device B port 2 should report device C port 1, and so on. Where the reported neighbor is empty (nothing detected), the cable is unplugged, broken, or the neighbor is unpowered. Where the reported neighbor is the wrong device or wrong port, you have found a swap. Writing down the actual neighbor of every port is what converts a vague 'topology mismatch' into a specific cable to move.
Compare the Live Neighborhood to the Planned Topology
Lay the LLDP-reported neighborhood next to the topology configured in the engineering tool. The engineering defines an expected neighbor for each port; LLDP reports the actual neighbor. The mismatch is wherever expected and actual disagree, and it points at exactly one of two fixes: either the cable is in the wrong place and must be moved to match the plan, or the plan is wrong and the as-built cabling is actually correct and the engineering must be updated.
This comparison is what topology-based features depend on. Device replacement without an engineering tool, and fast startup, both rely on the controller trusting that the device on a given port is the one the plan expects. When the neighborhoods match, those features work; when they do not, the controller cannot safely assign a name to a replacement or trust a fast-startup sequence. So resolving the mismatch is not cosmetic - it restores the automation the topology was configured to enable. If you decide the plan is wrong, correct the configured topology to match what LLDP reports and download it.
When to Escalate
Escalate to the OEM or engineering owner when the as-built cabling is deliberately different from the delivered project and you are unsure which is authoritative - changing cabling to match an outdated plan can be worse than updating the plan. Also escalate when the mismatch involves a ring or media-redundancy topology, because ports have specific roles in the ring and moving a cable can trigger a media-redundancy event or break the ring's recovery behavior.
Bring in a network specialist if LLDP reports a neighbor that should not be possible - a device seen on a port with no cable to it, or a neighbor that flickers - which can indicate a switch loop, a mislabeled patch field, or a non-PROFINET device injecting LLDP. And follow site change control before moving any live cable on a running machine, since a wrong move on a line topology can drop every device downstream of the break.
Frequently Asked Questions
What does LLDP actually tell me on a PROFINET network?
LLDP tells you, for every port on every device, the name of the device and port physically connected to it. Each port announces its own identity and listens for its neighbor's, so the network builds a live map of how it is really cabled. That map is independent of the engineering plan, which makes it the ground truth you compare against. When a device reports an unexpected neighbor, or no neighbor where one should be, LLDP has pointed you at the exact port where the physical wiring diverges from the design.
Why does a topology mismatch stop a device from starting or being replaced?
PROFINET features like topology-based device replacement and fast startup rely on the controller trusting that the device on a given port is the one the engineering expects there. That trust comes from LLDP neighbor data matching the planned neighborhood. When the actual neighbor disagrees with the plan, the controller cannot safely auto-assign a name to a replacement device or trust a fast-startup sequence, so it flags a mismatch and holds the device out. Aligning the live neighborhood with the plan restores those features.
The cabling is correct but the plan is wrong - what do I change?
Update the configured topology in the engineering tool to match what LLDP reports, then download it to the controller. The mismatch always resolves one of two ways: move the cable to match the plan, or fix the plan to match the as-built cabling. If site standards and the physical installation are correct and only the engineering is out of date, correcting the plan is the right fix. Just confirm first that the as-built cabling really is intended, especially on ring topologies where port roles matter.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.