PROFINET — Device Not Reachable / Not Found

intermediate · 25 min

You will be able to tell, in under five minutes, whether a missing PROFINET device is a cabling fault, a name mismatch, a duplicate name, or a topology problem — and fix each one without touching the IP address.

ℹ️ A PROFINET controller does not look for its devices by IP address. It looks for a device name, and it looks for that name using a protocol that runs directly on Ethernet with no IP layer underneath it. That single fact explains almost every "device not reachable" call: the IP is a result of a successful startup, not a precondition for one. Stop checking IP addresses. Start checking names.

What the controller is actually looking for

Every PROFINET IO device — a remote I/O head, a drive, a valve island, a barcode scanner — stores a device name in non-volatile memory. The specification calls it the Name of Station. That name is the device's identity.

The IP address is not. In the normal case the controller (the PLC) writes the IP into the device as part of startup. That is the default configuration — in TIA Portal, IP address is set in the project. A device can instead be configured for IP address is set directly at the device, or for DHCP, and then the controller does not assign it. Check which mode the device is in before drawing conclusions about its IP.

The mechanism is DCP — Discovery and Configuration Protocol. DCP rides directly on Ethernet under EtherType 0x8892; there is no IP header under it. The controller's Identify request goes to the multicast group 01:0E:CF:00:00:00; the device's answer, and the controller's subsequent Set and Get, are unicast to that device's MAC address. Two consequences matter on the shop floor:

• DCP cannot cross a router. A laptop or a PLC in a different broadcast domain will never see the device, no matter how the routing is set up.
• A device with a wrong IP is still findable. DCP works on MAC addresses.

Startup runs in this order: the controller sends a DCP Identify asking "who is called drive-01?" → the device with that name answers with its MAC → the controller sends DCP Set to write the IP if it does not already match → the connection is opened → cyclic I/O starts.

"Device not reachable" means nobody answered the Identify.

Tell the causes apart first

Four questions, in order. Each one eliminates a cause.

1. Is the link up? Check the LINK LED on the device's RJ45 port and on the switch port. Dark means cable, connector, or port. Stop here — it is not a naming problem.

2. Does the device appear in a DCP scan? Put a laptop on the same segment and scan. On Siemens: Online access → your PC adapter → Update accessible devices in TIA Portal, or the free PRONETA Basic tool, which scans with no PLC present. Vendor-neutral: Wireshark with the display filter pn_dcp.

3. Is the name legal and identical? Compare character by character against the project. The rules:

• 1 to 240 characters in total, divided into labels by dots, each label at most 63 characters.
• Only lowercase a–z, digits 0–9, and the hyphen -. No uppercase, no underscores, no spaces.
• A label may not begin or end with a hyphen.
• The name may not have the form of an IPv4 address — n.n.n.n is rejected.
• The name may not begin with port-xyz or port-xyz-abcde (digits in place of the letters); that prefix is reserved for port names.

Engineering tools usually convert a project name to a legal one silently; a name typed by hand into a device's own web page does not get that treatment, so the two ends drift apart.

4. Does the port report a partner? Only relevant if topology is configured. See below.

LLDP, neighbours, and "no partner port"

LLDP — Link Layer Discovery Protocol, IEEE 802.1AB — is how PROFINET learns the wiring. Each port periodically announces its own device name and port ID to whatever is directly attached, using EtherType 0x88CC and destination MAC 01:80:C2:00:00:0E. That address sits in the reserved range 01:80:C2:00:00:00–01:80:C2:00:00:0F that conformant bridges must not forward, so the announcement dies at the first switch.

That is the point: LLDP describes one cable, not the network. From it the controller builds a map — "port 1 of io-head-03 is wired to port 2 of drive-01".

"No partner port" (Siemens also words it "no neighbour could be detected") means the controller expected a specific neighbour's LLDP announcement on that port and did not get it, or got a different one. Common causes: the cable is in the wrong port, an unmanaged switch sits between two devices the project believes are directly connected, or the neighbour itself is dead.

Cheap unmanaged switches are a real source of this. Some of them forward frames sent to the reserved range in violation of 802.1D; the announcement then arrives at a port it was never meant to reach and the topology map is wrong rather than merely incomplete.

On its own this is usually a warning — cyclic I/O can run with a wrong topology. It is not harmless, because it disables automatic device replacement.

Automatic device replacement — and why it does not fire

Siemens calls it device replacement without exchangeable medium; the generic term is automatic device replacement. It lets you plug in a spare with no memory card and no laptop.

It works because the neighbours of the empty slot report, over LLDP, that their port is now connected to a device with no name. The controller matches that position against the configured topology and writes the correct name with DCP Set.

Four preconditions, all required:

1. Topology is drawn in the project — port interconnections, not just the network view.
2. The option is enabled on the controller's PROFINET interface (a checkbox in TIA Portal, on Siemens).
3. Both the controller and the device support the function — check the device manual.
4. The spare is in factory state, with an empty name.

Point 4 is where it fails most often. A spare that was bench-tested, or pulled from another machine, still has a name in it. The controller sees a named device it did not ask for and does nothing.

Step-by-step

Everything below touches a live network. A DCP Set is not access-controlled and takes effect immediately: writing a name or IP to a device that is currently exchanging cyclic data will abort its connection and drop its outputs. Work with the affected section in a known safe state, and confirm which physical device you are addressing before you write anything.

1. Check the LINK LEDs at both ends of the suspect cable. No link, no further diagnosis.
2. Scan with DCP from a laptop on the same segment. Use PRONETA Basic or Accessible devices.
3. Flash the LED before touching anything. DCP has a Signal service (a Set with the Signal suboption) that blinks the LEDs on one specific device. Use it to confirm which physical box the list entry is.
4. If the name is empty, assign it: in TIA Portal, Online & diagnostics → Functions → Assign PROFINET device name; or use PRONETA. Copy the name from the project exactly.
5. If the name is wrong, change the device, not the project. Renaming in the project breaks topology references and forces a download.
6. If the spare carries an old name, first confirm the four preconditions above actually hold. If topology is not drawn or the controller option is off, automatic replacement will not fire and you should simply assign the name by hand as in step 4. Only if all four hold is a DCP Reset to Factory on the spare worth doing — clearing its name and letting automatic replacement adopt it.
7. If two devices share a name, deal with them one at a time so that only one is powered on the segment while you rename it. Treat de-energising a station as a plant intervention, not a diagnostic step — the process it controls has to be in a safe state first.
8. Run a topology scan. In TIA Portal, the Topology view offers an online/offline comparison that marks each port as matching or not. PRONETA draws the topology it actually finds. Compare against the drawing.
9. If it still will not connect, capture with Wireshark. Filter pn_dcp and watch the controller's Identify requests go out unanswered — that confirms the name is the fault and not the connection setup.

Never do this

• Never write a name or an IP to a device that is still in cyclic exchange. A DCP Set terminates the connection and drops that station's outputs. Confirm the station is out of service, or that the section is safe, before you write.
• Never run "Reset to factory settings" from a device list you have not verified with the flash LED. The list is a set of MAC addresses. Reset the wrong one and you erase a working station's identity. How much else goes with it depends on the reset mode the tool and the device use — the service defines several, from communication parameters only through to all stored data — so on a drive you may be looking at a full re-parameterisation, not a rename.
• Never assign a device's name to a replacement while the original is still powered on the same segment. You create a duplicate name and take down a station that was working.
• Never fix the mismatch by editing the name in the project to match the device. It hides the real problem — usually the wrong spare — and it invalidates the topology.
• Never assume the two ports on a device are interchangeable. With topology configured, P1 and P2 are positions. Swapping them produces partner-port errors and blocks automatic replacement.
• Never chase the IP address. Setting a fixed IP on the device does not make DCP find it. If the device is configured to take its IP from the project, your setting will be overwritten at the next successful startup anyway.

A note on LEDs

PROFINET does not standardise LED names or colours. BF, ERROR/ER and RN below are Siemens conventions; another vendor's device will label the same conditions differently. Always read the LED table in that device's own manual.