A fixed PROFINET topology can commission a replacement ET 200SP interface module by its physical position, but the evidence shows a different result when two already configured modules exchange positions during a power-off restart. Separate these cases before changing the PLC program or calling ReconfigIOSystem.
Define the Replacement Case
| Case | Observed result | Engineering implication |
|---|---|---|
| Insert an unconfigured spare at the original position | The controller recognized the new module and assigned the correct device name. | Fixed-topology replacement worked as intended. |
| Move the removed module to another position | The controller assigned names correctly in the reported test. | A previously used module can be accepted at a new position under some replacement sequences. |
| Swap two configured modules while powered off | The system reported a topology error and did not reassign their names at startup. | Do not assume cold-start commissioning will overwrite two retained configurations merely because their physical positions changed. |
| Disconnect and reconnect the upstream PROFINET cable while powered | The topology was reapplied and the names were assigned correctly. | A new link event changed the outcome in the tested system; this is an observed recovery action, not proof of the internal cause. |
Distinguish Fixed Topology from Dynamic Reconfiguration
The operating requirement is position-based replacement: every conveyor and remote I/O station is present during production, while an identical spare can replace a conveyor at the same physical point in the chain. That requirement fits a fixed daisy-chain topology better than an optional-device topology that changes at every startup.
ReconfigIOSystem was part of the earlier dynamic design, but the later scenario no longer required devices to remain absent. The source also reports that topology changes ultimately resolved the application without ReconfigIOSystem, although it does not provide enough configuration detail to reproduce those changes. Do not infer an undocumented block sequence or setting from that result.
Account for the Hardware Evidence
The final test used an ET 200SP CPU 1510SP with three IM155-6PN ST modules: two operational modules and one spare. An earlier statement identifies the stations as IM155-6PN BA. Because those identifiers conflict, verify the exact interface-module variant installed before comparing results or escalating the behavior. The evidence does not establish that BA and ST variants behave identically in this scenario.
The configured chain in the final test was CPU -> IM155-6PN position 1 -> IM155-6PN position 2. In the larger proposed installation, CPU port 2 connected to port 1 of the first IM155-6PN, and each module's port 2 connected to port 1 of the next module. Port identity therefore belongs in the topology definition and in the cable labels.
Configure and Commission the Fixed Chain
- Confirm that all required remote stations are installed and that the physical port-to-port chain matches the intended order.
- Before enforcing the topology, bring the complete PROFINET system online and confirm that every device communicates in its current wiring arrangement.
- Use online diagnostics to record each device and the ports through which the controller sees it. Build the configured topology to match those observed connections.
- Enable Support device replacement without exchangeable medium and Permit overwrite of device names of all assigned IO Devices in the CPU advanced options.
- Download the fixed topology, then validate it incrementally. Establish correct operation between the CPU and the first station before extending verification down the chain.
- Label the upstream and downstream cables consistently so maintenance personnel return each connection to its configured port.
The evidence does not show a separate IM155 parameter that explicitly enables acceptance of automatic commissioning. It also does not show a configured MAC-address field in the hardware project. Avoid inventing either requirement; use the controller options, fixed physical topology, and online diagnostic view that are actually documented in the test account.
Verify Replacement and Diagnose a Cold-Start Swap
- Start from a fully operational chain and confirm that every station is healthy and assigned the intended name.
- Power down, replace one station with the spare at the same position, restore power, and verify that the replacement receives the position's name and returns to operation.
- Repeat the test with the repaired station installed at another valid position. Record the device variant, retained name, physical ports, controller diagnostics, and resulting assigned name.
- If swapping two previously configured stations produces a topology error after restart, classify it separately from replacement by an unconfigured spare. The evidence supports retained device configuration or startup sequencing only as hypotheses, not as confirmed causes.
- In the tested configuration, disconnecting and reinserting the cable arriving from the CPU caused the topology and names to be applied correctly. If site safety and operating rules permit this test, perform it only after recording the startup diagnostics and identifying the upstream port.
- If the cold-start swap remains unacceptable, provide Siemens Support with the exact CPU, interface-module variant, project topology, startup diagnostics, and the difference between cold-start and live reconnection results.
Acceptance requires more than green device status after the first commissioning. Test a factory-default or otherwise unconfigured spare, a repaired module with a retained name, and a direct swap of two configured modules. Verify the assigned PROFINET names, physical topology, and I/O availability after every restart.
FAQ
Will fixed PROFINET topology rename an unconfigured IM155-6PN replacement?
Yes in the reported CPU 1510SP test: replacing the module at position 1 with the spare caused the correct name to be assigned. Confirm the result on the installed BA or ST variant before adopting it as the maintenance procedure.
Why are names not reassigned when two IM155-6PN stations are swapped?
The test showed a topology error after a powered-off swap of two configured stations, but it did not establish the internal cause. Treat retained configuration and startup sequencing as hypotheses and capture controller diagnostics before changing the network.
Is ReconfigIOSystem required for conveyor replacement?
Not for the described fixed-topology case in which every station is present during operation. The source reports a topology-based resolution without ReconfigIOSystem, but does not provide enough detail to reproduce the final topology modifications exactly.