Spare FSoE slice with a duplicate FSoE address
On a packaging line, six FSoE slaves are configured with FSoE addresses 1 to 6. The zone 1 infeed uses address 1, and the zone 5 guard uses a remote safety I/O slice at address 5. After a slice failure, a spare is installed at zone 5. The technician sets the slice’s EtherCAT station address to 5 with the rotary switches but leaves the FSoE address at its factory default of 1. The line starts, and EtherCAT diagnostics show all slaves operational. The FSoE master reports a valid connection for address 1. When the zone 5 guard is opened, the zone 5 safe output remains energized, but the zone 1 infeed stops. No FSoE CRC, sequence, or watchdog error is logged. The safety PLC project still maps the zone 5 guard input and zone 5 safe output to FSoE address 5. The line has a 400 ms stop category 0 function and a 20 ms FSoE cycle.
1. What is the most likely cause, and why did the diagnostics not flag it?
Read the worked answer
The most likely cause is a duplicate FSoE address. The spare slice is answering as address 1 even though its EtherCAT station address is 5. FSoE routes safety data by the FSoE address and connection, not by the EtherCAT station address. Because address 1 is a valid, active connection, the master sees good frames and no CRC, sequence, or watchdog fault. The master cannot tell from the frame alone that a second device is also using address 1. The zone 5 guard status is therefore delivered under address 1, and the master reacts as if the zone 1 infeed input changed. Meanwhile the zone 5 output is not being controlled by the intended address 5 connection, so it does not drop as expected. This is a configuration and addressing fault, not a random communication fault.
2. What checks and corrections would you perform before restarting the line?
Read the worked answer
I would first compare the configured FSoE address list in the safety PLC with the actual FSoE address in every slave, including the spare. The EtherCAT station address is not sufficient evidence. I would correct the spare slice to FSoE address 5, power-cycle it, and confirm that address 1 and address 5 each have exactly one responder. Then I would verify the safe input and output mapping bit by bit, because the wrong address may have caused the project to accept wrong process data. I would test the zone 5 guard and confirm that only the zone 5 output drops, and that the zone 1 infeed is unaffected. I would also check whether the spare’s default address was used during earlier tests, because any validation done with that slice may be invalid. Restart should not occur until the address conflict is removed and the mapping is revalidated.
3. How would you prevent this recurrence in spare-parts handling and configuration control?
Read the worked answer
The spare-parts procedure should require setting both the EtherCAT station address and the FSoE address, and it should record them separately. A controlled address list should show every FSoE address, its device, its safety function, and its approved spare. The maintenance technician should not rely on rotary switches alone, because those may set only the EtherCAT address. The safety PLC should include a start-up check or diagnostic that compares expected FSoE connections with active connections, and it should alarm on duplicates or missing addresses if the platform supports it. Replacement slices should be kept at a neutral address or pre-addressed for a specific location. Finally, any address change should trigger a configuration checksum update and a targeted validation of the affected safety function.