The runtime hosting your PROFINET device refused the address write your controller sent. Enable IP-address updates for the interface named in the error, in the runtime's cfg file, then make the station names identical in both projects and import a freshly generated GSDML file. The device showing in the network scan is discovery only; it says nothing about the configured connection.
The error message names its own fix: the runtime hosting your PROFINET device refused the address write, and the permission it needs is a setting in the runtime's *.cfg file. Enable IP-address updates for the interface the error names and restart the runtime, and the message stops. The two red triangles in the controller project then have two remaining causes, in a fixed order: a station name that differs by one character between the two projects, and a GSDML device description that no longer matches the I/O configured in the device. A hit in the network scan changes none of this. Discovery and configuration are separate steps in PROFINET, and only the second one is failing.
What the error message means
The controller owns addressing in a PROFINET cell. When it connects, it writes the station name and the IP address to the device itself, in one request, using the DCP configuration protocol. DCP frames ride a fixed EtherType, 0x8892, so the write needs no IP route to reach the device; a factory-fresh device with no address accepts one. Current controller stacks send name and IP together in a single request, and a controller can rewrite the address later from the user program while the line runs.
Your device runtime refused that write. The refusal is a permission, not a network fault: the interface the runtime uses for PROFINET is configured to keep its address fixed. One setting in the cfg file turns the refusal into acceptance. Budget about 5 minutes for the cfg edit, the runtime restart and one repeat download; the name check below takes another 2 minutes with both projects open side by side.
Symptoms and what each one points to
- "IP-Change not enabled on specified interface" at connect or download: the cfg file denies address writes on the interface named in the message. Clear this first; nothing downstream connects while it stands.
- Red triangle on the device: identity. The controller cannot match the device on the wire to the device in its project, by name, by address or both.
- Red triangle on the I/O definition: the module list. The imported GSDML file describes different modules or different process-data lengths than the device project now holds.
- Device visible in the network scan: cable, connector and link are good. The scan answers discovery only, so it clears wiring from the suspect list and points back at configuration.
- Error on some downloads and not others: the controller re-applies the address on connect while the device falls back to its own saved address. Check how the controller's device editor treats address assignment on reconnect.
Enable the address write in the cfg file
- Read the whole error line and write down the interface it names, for example eth0. The permission belongs to that one interface, not to the runtime as a whole.
- Open the cfg file of the running runtime, the instance your device project downloads to. The PROFINET section of your runtime's documentation prints the exact key and the section it belongs in for your version. Use that line exactly; keys invented into a cfg file create the next fault.
- Save the file and restart the runtime so it re-reads the configuration, then download the device project again. A restart typically takes under 1 minute; give the runtime that long before judging the result.
- While you are in the controller's device editor, check what it does with name and IP on reconnect. Some stacks load the stored device data only on the first connection, so a device that lost its address never gets re-addressed. Set the editor to re-apply the address on every connect.
If the same error comes back after two downloads, so after about 10 minutes of work, you edited the cfg of a different runtime instance. Confirm the runtime path in the device editor before changing anything else; a second edit to the same file achieves nothing.
If this device carries a safety profile, its addressing is part of the safety configuration. Make address changes with the machine stopped.
Match the station name character for character
The station name is the identity the controller connects by, and the write sets name and address together, so the name deserves the closer look. Under the PROFINET naming rules, device names allow lowercase letters, digits and hyphens, with dots splitting the name into labels. Each label holds up to 63 characters and the whole name up to 240. No capitals, no underscores.
Open the device project and the controller project side by side and compare the strings one character at a time. The common fault is three characters: a capital first letter and mixed case in the suffix, typed into the controller project by hand. Correct the controller project to the spelling the device project generates, then download both. A name retyped only in the controller project holds until the next regeneration of the device project puts its own spelling back.
Regenerate the GSDML file and reconcile the I/O
The controller project knows your device only through its GSDML file. The GSDML naming convention puts the version and an 8-digit date in the file name, in the form GSDML-V2.31-vendor-device-20250115.xml, so a stale import is visible at a glance: compare that date with the last change to the device project's module configuration.
Regenerate the file from the current device project and import it into the controller project, letting it replace the old description. Then compare the module lists. Every input and output configured on the device side needs a matching entry on the controller side with the same data length; a process image that differs by one word, 2 bytes, keeps the red triangle on the I/O definition. When the configured points themselves disagree after a clean import, the fault has moved into the project, and fixing a PLC runtime device mismatch covers that ground.
Example: device press01-io at 192.168.0.10 refuses its address
Inputs:
- Controller address 192.168.0.1 with mask 255.255.255.0, read from the interface properties in the controller project.
- Device boots on its saved address 192.168.0.8, the value the device stack falls back to from its own settings.
- Station name generated by the device project: press01-io, 9 characters, all lowercase. The controller project shows Press01-IO.
- The error names interface eth0.
- Mask 255.255.255.0 gives 254 usable host addresses on network 192.168.0.0, room enough for both stations with no gateway in between.
The rules in words: two stations exchange cyclic I/O only when their addresses, masked with the subnet mask, give the same network. A station name matches only when every character and its case are identical, within the 240-character limit the rules allow. The address write lands only when the runtime permits it on the interface the error names.
The arithmetic:
- 192.168.0.1 masked with 255.255.255.0 gives 192.168.0.0.
- 192.168.0.10 masked with 255.255.255.0 gives 192.168.0.0.
- Same network on both sides, so once the device holds 192.168.0.10, cyclic I/O has a route with no gateway.
- press01-io against Press01-IO: 9 characters against 9 characters, with 3 differing in case only, at positions 1, 8 and 9.
With the IP update enabled for eth0 in the cfg file and the name corrected to press01-io, the controller's single DCP request writes the name and the address 192.168.0.10 to the device on the next download. Both triangles clear when the project goes online, and the whole recovery from cfg edit to green link runs about 15 minutes.
The decisions: if the two masked networks had differed, the address plan would be the fault and no cfg setting would fix it. If the write still fails after two downloads with the permission in place, the runtime you restarted is not the runtime the device editor downloads to; settle that path before touching the name or the GSDML file.
How to confirm the fix
- The runtime log at download shows no IP-change message.
- The device status in the controller project shows the configured station name and the written address, 192.168.0.10 in this example.
- Both triangles are gone and the input and output counts read the same on both sides of the link.
- Cycle the device power once. Wait about 30 seconds for the boot. It comes back, is re-addressed, and reconnects without a download, because the controller re-applies name and IP on every connect.
Recommendation: Work every case of this error in the same order: the cfg permission on the interface the error names, the station name compared character by character, then a regenerated GSDML file with the I/O lengths checked on both sides. If all three are clean and the connection still fails after 10 minutes of retries, capture the diagnostic text from both sides before changing anything else; the next two causes in line are a second runtime instance and a device editor pointed at the wrong interface.
When the link feeds a floor display
Plenty of these cells exist to drive a status board. Putting the live values on the operator screen or on a separate board the crew reads from the floor is a real decision with its own trade-offs, and live factory data on a dashboard or a sign works through it. Where a separate board wins, the shop-floor screen category covers the sizes, mounting and power that hold up on a floor.
Questions
Why does the device show up in the network scan but never connect?
The scan and the connection use different mechanisms. The scan asks who is on the network and the device answers with its current name and address; the controller then connects by the name configured in its project. A scanned device still reporting a factory-default name never matches a project expecting your configured name, so read the name shown in the scan result and compare it with the project before changing anything else.
What characters are allowed in a PROFINET station name?
Lowercase a to z, digits 0 to 9 and hyphens, with dots separating labels. Each label holds up to 63 characters and the whole name up to 240. No capitals, no underscores, and a label cannot start or end with a hyphen. The underscore is the classic import error: an engineering field accepts it, the device stack rejects it at connect.
Do I need to regenerate the GSDML file every time I download?
No. Regenerate when the device project's module configuration or process-data lengths change, including input and output counts, and import the new file into the controller project before the next download. If nothing in the module list changed, the existing import stays valid. When in doubt, compare the 8-digit date in the file name against the last change to the device project.
Can I set the IP address at the device instead of letting the controller write it?
Some device stacks offer exactly that: an option to hold the address set directly at the device. If you use it, configure the controller side to skip address assignment, because a controller that writes name and IP in one request keeps trying and the runtime keeps refusing. For a fixed cell with one controller, letting the controller own the address is the cleaner arrangement.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.