PROFINET Device Name Mismatch After Replacement
A failed PROFINET device gets swapped for an identical spare, everything is cabled exactly as before - and the controller still reports the device missing, the bus fault stays on, and the new hardware sits there with no IP address. This confuses people coming from other protocols because the hardware is fine; the issue is identity. PROFINET addresses devices by station name, the name lives in the device rather than the project, and a factory-fresh replacement does not have one. This guide explains the naming model, the manual fix, and the automatic replacement mechanism that removes the manual step when it is configured ahead of time.
PROFINET device name mismatch in one line: A PROFINET device name mismatch after replacement happens because PROFINET IO identifies devices by their station name, assigned over the network via the Discovery and Configuration Protocol and stored in the device. The controller finds the device by name at startup, then assigns its IP address and establishes the connection. A factory-new replacement has a blank name, so the controller cannot claim it. The fix is assigning the configured name with an engineering or commissioning tool, or letting automatic device replacement do it - which works only if the project's port-level topology was configured so the controller can recognize the newcomer by its position and neighbors.
First Checks: What the Device Actually Believes
Use a commissioning tool or the engineering software's accessible-devices scan to see the replacement as it really is on the wire. The scan shows every PROFINET device reachable on the segment along with its current station name, IP address, and type. A factory-new unit typically shows an empty name and no IP - which, combined with a controller configured to expect a specific name, fully explains the missing-device fault. This one look distinguishes the naming problem from genuinely dead hardware or cabling faults, because a device that appears in the scan is alive and reachable.
While in the scan, check for the opposite problem too: duplicates. If the old device was not actually removed from the network - left powered in a cabinet, or its role migrated while it stayed connected - two devices can end up carrying, or claiming, the same name, and name conflicts produce connection behavior that looks random. The same applies to duplicate IP addresses from devices that kept a static assignment. The scan surfaces both conditions immediately.
The Manual Fix: Assign the Name via DCP
The direct repair is assigning the correct station name to the new device using the engineering tool or a standalone commissioning tool, which performs a DCP set-name operation over the network. The name must exactly match the one configured for that device in the controller's project - PROFINET station names follow restrictive, DNS-like lowercase conventions, and tools enforce the rules, but the match itself is your responsibility. Once the name is set, the controller finds the device on its next attempt, assigns the project's IP address for it via DCP, and establishes the connection without further intervention. No download to the controller is needed for a pure replacement, because the project already expects this name.
Two details catch people. First, the name is stored in the device, so a spare pulled from another machine may arrive carrying a name from its previous life - actively wrong rather than blank, and worth clearing or overwriting rather than assuming empty. Second, some device families store the name on a removable medium or memory module precisely so a replacement can inherit identity by moving the module across; if the failed device used one, moving it may be the intended repair and renders network renaming unnecessary. The device manual states which scheme applies.
The Designed Fix: Automatic Device Replacement
PROFINET has a mechanism intended to make the manual step unnecessary: device replacement without an engineering tool, driven by network topology. When the project includes the port-level topology - which device port connects to which neighbor port - the controller can identify a nameless factory-state device by its position among its neighbors, using LLDP neighbor information, and assign it the name the project expects for that position automatically. A maintenance electrician swaps the hardware, and the network heals itself without a laptop.
The mechanism has preconditions, and unmet preconditions are why it silently fails to trigger. The topology must actually be configured in the project and must match reality - port for port, because a device cabled into different ports than the topology records will not be recognized as the expected neighbor. The replacement must be in factory state with no name already set, which is why spares recycled from other machines defeat it. And the controller option enabling replacement without exchangeable medium must be active. Where a site relies on this feature, cabling discipline during the swap is the whole game: same ports, same order, factory-reset spare.
When to Escalate
If the name is verifiably correct, no duplicates exist, and the controller still will not connect, compare identities at the next level: the configured device type and version in the project against what the replacement reports in the scan. A replacement of a different hardware or firmware version than the project's configured module can refuse to connect even with a perfect name, and the resolution - updating the project's module version or the device's firmware - belongs to whoever owns the controller project. Vendor support conversations go faster with the scan output and the exact configured-versus-reported identity difference in hand.
Replacement pain is also a reason to monitor. A PROFINET network reporting device diagnostics into a SCADA or monitoring layer such as Merobix gives maintenance a live view of which devices are connected, faulted, or missing, so a swap that did not fully succeed is caught while the technician is still on site rather than on the next production run. The postmortem question after any confusing replacement is worth asking too: would configured topology and disciplined spares handling have made this a zero-touch swap?
Frequently Asked Questions
Why does a brand-new identical PROFINET device not just work after a swap?
Because PROFINET addresses devices by station name, and the name is stored in the device, not derived from the hardware. A factory-new unit has no name, so the controller - which looks for the configured name at startup - cannot claim it or assign it an IP address. Identical hardware is necessary but not sufficient; the device must also carry the expected name, assigned manually via DCP or automatically through configured topology.
What is needed for PROFINET automatic device replacement to work?
Three things. The project must contain the port-level network topology so the controller can recognize a device by its neighbors via LLDP. The replacement must be in factory state with no station name set, which excludes spares recycled from other machines unless reset. And the swap must reproduce the cabling exactly - same ports on the same neighbors - because position is how the newcomer is identified. Miss any one and the controller waits for a name that never comes.
The name is right but the controller still rejects the device - what now?
Compare what the project expects with what the device reports: exact device type, order number equivalence, and firmware version. Controllers can refuse a connection when the replacement's version differs from the configured module, even under the correct name. The accessible-devices scan shows the reported identity; the project shows the configured one. Aligning them - by adjusting the configured version or updating device firmware - is the remaining fix, and it belongs to the controller project's owner.
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.