Summarizing from practice, sharing in social circles,

creating the most down-to-earth public account

Abstract

Occasionally, during production, the EtherCAT network may experience a complete Init situation, requiring power cycling or reactivating the configuration to recover. How to diagnose which slave caused the network crash and what the possible reasons are? This article describes:

1. Reasons and parameter settings for the EtherCAT master returning to Init

2. Checking the number of connection losses for slaves

3. Possible reasons for slave connection losses

Keywords

EtherCAT, Master Init, Continuous Frame Loss, Network Interruption

Version History

This article references the existing technical document “EtherCAT Continuous Frame Loss Causing Network Interruption Troubleshooting Method.docx” and adds some content to the main text to help users understand sufficient information from a single document. The methods described in the article have been guided by ETG technical experts, and this is organized and published for user engineers to collect and share. For the latest version, please check the Beckhoff Virtual Academy’s “EtherCAT Diagnostic Cases”:

https://tr.beckhoff.com.cn/course/view.php?id=40#section-4.

Main Text

1 Reasons for EtherCAT Master Returning to Init

In TwinCAT settings, there is only one possibility for the master to enter Init by itself—when the data packets sent out cannot return for 10 consecutive times. According to the default configuration of TwinCAT, the master will enter Init and will no longer attempt to re-enter OP, requiring a restart or configuration activation to re-enter OP. If this is the reason, it is usually indicated in the TwinCAT Log that packets were lost 10 times.

1.1 Master’s ReInit Settings

Note: This setting is to ensure safety, as when packets sent cannot return, the master cannot determine whether the data sent to all slaves has been accepted, nor can it receive any data from the slaves. In such cases, a safer approach is to enter Init by itself, waiting for manual intervention to troubleshoot before restarting.

Only for troubleshooting should the master ReInit option be canceled. This way, even if packets do not return, the master will continue to maintain the OP state and keep sending packets. However, this poses potential risks, so it is not recommended to set this during normal production. By the way, some third-party masters do not report this error, which does not necessarily mean their masters are more stable; it may be that they do not have this protective function.

1.2 Slave’s ReInit Settings

If individual slaves experience momentary disconnections, causing packets to not return, and when the master continues to send packets, if that slave reconnects, whether it resumes communication depends on the slave’s ReInit settings:

The default is also checked. If unchecked, then even if the master sends data to this slave, it will not recover. This way, it can be immediately identified which slave caused the packet loss.

To make the system more robust, overcoming short-term (e.g., less than 10 times) disconnections to still be operational, it is usually recommended to keep the default configuration, which automatically reinitializes and enters OP communication after the fault point recovers.

2 How to Check Which Slave Had a Connection Interruption

There are two methods to check which slave had a connection interruption: one is in the EtherCAT Online interface, and the other is using the PLC program to read the slave’s Register.

2.1 Display Slave Connection Loss Count in EtherCAT Online Interface

EtherCAT slaves can independently record the connection loss count for each port. In the master’s Online View, select 0310‘Link Lost A/B’. Since servo, stepper, or EL modules only have AB ports. The low byte of 0310 indicates the connection loss count of Port A, while the high byte indicates Port B’s count.

Then on the Online page, you can see the value of Reg:0310:

In the above image, the address 1008 Term9(EK1100)’s Reg:0310’s current value is 5, which is due to 5 instances of unplugging the network cable during testing. Additionally, a few points need attention:

(1)Unplugging the Network Cable Only Affects the Following Slaves

If you unplug the incoming network cable from one EK1100, only the 0310 low byte of EK1100 itself will increase by 1, while the following EL module shows normal; if you unplug the cable connected to EK1110, it will still show that the 0310 low byte of EK1100 increases by 1, while the unplugged EK1110 will still show normal.

(2)Slave’s Reg Value Only Resets on Power Loss

Testing on the CX5130+TC3 platform shows that EK1100 slave power cycling does not cause this value to increase, as this value resets on every power loss. However, the Reg value of 0310 remains unchanged when the TC3 master restarts or when the TC3 development environment is closed and reopened.

(3) Diagnostic Data Can Be Exported as a .csv File

Although screenshots can also be analyzed, if there are many slaves, multiple screenshots would be needed. The EtherCAT Online interface provides an export function. In the right-click menu of the above image, select Export List to export diagnostic information to a .csv file. Open the .csv file in Excel, then in the main menu of Excel, select “Data” under “Text to Columns,” set the delimiter to “semicolon,” and you can see the data in each column:

2.2Use FB_EcPhysicalReadCmd to Read

If there is no engineer on-site to check the EtherCAT Online interface, you can write a PLC program to call the function block FB_EcPhysicalReadCmd to read the slave’s Register, for example:

Since the register value cannot be configured to ProcessData, it can only be read using FB. Do not read every cycle, as this will consume too much CPU and EtherCAT resources; it is recommended to trigger the read command when the WcState is Invalid. If the number of slaves exceeds a lot, it is better to read in groups.

2.3 Check the Slave’s Run Light

For slaves with data communication, both the connection light and the run light will be on. For slaves without data communication, the Run light will be off. However, this method is difficult to check one by one if the electrical cabinets are scattered on-site. Moreover, if the master stops communication after 10 packet losses, or if the problematic slave recovers communication within 10 times, then manual observation of the indicator lights will be nearly impossible. If the settings for both the master and slave are not to automatically ReInit, the indicator light of the problematic slave will differ from other normal slaves.

3 Why EtherCAT Connections May Be Lost

Possible reasons include: EMC interference, cable quality issues, loose network ports, loose network interfaces, poor contact in slip rings, damage to slave modules, and various other reasons. The most common issues are cable quality and connection problems; these should be the first to investigate.

3.1 Cable Quality

If it is a prefabricated cable, it is usually produced in batches by machines, and the crimping quality will be more stable. If it is handmade, the reserved length for cutting and crimping, force applied, whether the shielding layer and metal contacts are secure, all have variables. It is advisable to open a few connectors for inspection.

3.2 Connection Issues

Try gently shaking a network cable of a slave while monitoring EtherCAT Online to see if the Lost Frame count increases. If it does, it indicates that vibrations during production may cause packet loss. If it is identified that this node is faulty, check the RJ45 connector and port for looseness, damage, rust, etc. If conditions permit, the simplest solution is to replace the component.

END

If you like this article, scan the QR code to follow our public account