When using TwinCAT software to perform communication configuration on the Solidot EtherCAT Junction, during configuration of the XB6S-EC2002 Coupler and the servo drive, the following phenomenon occurred: all devices were in the normal OP (operation) state, but the input data was not being refreshed, and the input signal of the Coupler could not be uploaded to the PLC normally, while the output signal could still be controlled normally. To address the above problem, the following methods can be used for troubleshooting and resolution:
1. Check the device wiring
A comprehensive check of the relevant terminal blocks can be performed. If the Indicator on the channel side is lit, this indicates that the physical connection of the signal input path is normal. If all signals in the input data Area are still "0" at this point and the channel status never changes, proceed to the next troubleshooting step.
2. Check whether the Coupler is in an abnormal operating state
When the Coupler is in SaveOP or another abnormal operating state, it may allow only output control while being unable to read input data. You can switch the communication state of the Coupler via the TwinCAT state machine and observe the status of its Communication LED. If the Coupler responds normally to state switching and the Communication LED indicates normal operation, confirming that it is not in an abnormal operating state, then the possibility of a Coupler failure can be ruled out, and you can proceed to the next troubleshooting step.
3. Check whether the Coupler itself has a hardware problem
After ruling out wiring and communication problems, further confirm the functional integrity of the Coupler by isolating it from the current EtherCAT topology and connecting it to a test environment on its own. If testing shows that the Coupler can upload input data normally, this indicates that it is fully functional with no hardware damage, and you can proceed to the next troubleshooting step.
4. Check potential problem slave devices one by one
Given the characteristics of the current problem — all input signals fail to refresh while output signals can still be controlled normally — it is suspected that the problem may involve the entire EtherCAT bus input link. For this reason, input data read tests were performed on the connected slave devices such as the servo drive, and the results likewise showed that the input data was not updated. Based on this, it can be confirmed that the input data of the entire bus system cannot be refreshed while the output control function is normal, indicating that the root cause of the problem lies at the bus input data flow level.
Based on the above troubleshooting steps, the scope of the problem was determined. On the premise that a single Coupler can communicate normally, the remaining slave devices on the bus were checked using a segment-by-segment isolation method. The other slave devices were disconnected one by one except for the XB6S-EC2002 Coupler, and changes in the bus communication state were observed. Ultimately, it was found that after disconnecting one particular slave device, the bus input data resumed refreshing. Further inspection confirmed that this slave device was faulty and caused the interruption of the input signal across the entire EtherCAT bus.
5. Summary of solutions
In an EtherCAT network, an abnormal slave device (e.g. due to a link topology or device configuration problem) can cause bus data transmission errors, preventing input data from being refreshed. Even if the slave device is in the OP state, a fault in another slave device can still affect the entire network. An error state of any slave device (such as ERRINIT) will interfere with PDO data upload and affect the stability of the entire system. Therefore, slave device status monitoring and Troubleshooting must be strengthened to ensure network reliability.
The above are the troubleshooting and resolution methods for the problem of no input data refresh for devices in an EtherCAT bus network. Thank you for watching!