Conveyor E-stop delay with EtherCAT working-counter errors
A conveyor network has four EtherCAT segments joined by three couplers. A SIL 2 emergency-stop function uses FSoE remote I/O on segment 4 and the FSoE master in the central PLC. The FSoE watchdog is 50 ms and the FSoE cycle is 5 ms. During commissioning, the measured time from pressing the E-stop to the contactors dropping is 120 ms. The requirement is 200 ms. The FSoE diagnostics show no CRC, sequence, or watchdog errors. EtherCAT diagnostics show working-counter errors on segment 3 that increase when the conveyor runs. The maintenance team proposes replacing the FSoE slave on segment 4. The safety PLC log shows the FSoE connection for segment 4 remains in Data state throughout the test.
1. Where would you focus fault tracing, and why?
Read the worked answer
I would focus on segment 3 and its couplers, not on the segment 4 FSoE slave. The FSoE connection stays in Data state, and there are no CRC, sequence, or watchdog errors, so the safety protocol is not reporting a loss of safety data. The working-counter errors are EtherCAT physical-layer or forwarding errors, and they increase with conveyor motion. That points to cables, connectors, shielding, couplers, or termination on segment 3. The 120 ms measured time is still within the 200 ms requirement, but the errors are a reliability warning and may become a delay or a dropout later. Replacing the segment 4 slave would not address errors on segment 3 and would waste a known-good device.
2. What tests would distinguish an FSoE protocol problem from an EtherCAT physical-layer problem?
Read the worked answer
I would separate the measurements. For FSoE, I would log the state machine, the frame counter, CRC errors, sequence errors, and watchdog trips during repeated E-stop tests. For EtherCAT, I would read the per-port error counters, working-counter errors, and link status on each segment before and during conveyor motion. I would swap a suspect cable or coupler with a known-good one and see whether the errors move. I would also run the conveyor with the drives disabled, then with one drive at a time, to see whether the error count follows a specific load. A scope or cable tester can show noise, reflections, or shield problems. If the FSoE log remains clean while the EtherCAT counters change, the fault is in the physical layer, not the FSoE protocol.
3. What conformance and validation evidence would you require before accepting the line?
Read the worked answer
I would require a clean EtherCAT error-counter log over a defined run period, including the worst-case conveyor speed and load. The FSoE configuration record should show the watchdog, cycle time, FSoE addresses, and safe input and output mapping. The validation record should include repeated E-stop tests with measured time from actuation to contactor drop, not just one pass. I would require a fault-injection test that breaks the EtherCAT cable or removes the FSoE connection and confirms the fail-safe reaction within the 200 ms requirement. The conformance evidence should include the device certificates and the network configuration check. Finally, the maintenance procedure should specify which counters to review and what action to take if working-counter errors return.