EtherCAT has higher transmission efficiency and flexibility. After more than a decade of development, EtherCAT technology has become one of the mainstream real-time Ethernet fieldbuses worldwide. At the same time, EtherCAT technology is fully open. Therefore, whether domestically or internationally, more and more devices are adopting EtherCAT as the bus interface.
In the domestic automation market, as the complexity of machines continues to increase, PC-based control technology and EtherCAT bus control architecture have gradually become the top choice for system integration. Moreover, the scale of EtherCAT control systems is growing larger, often encountering applications where different brands of EtherCAT devices operate within the same EtherCAT system. Therefore, when choosing an EtherCAT control system, is it enough to simply select products that clearly indicate support for EtherCAT technology to ensure interoperability? Here are a few points to emphasize:
01
The Master Must Support the Functions Required by the Slaves
EtherCAT technology has very good consistency; since its launch in 2003, the EtherCAT protocol mechanism has been very stable. In principle, EtherCAT devices developed today can communicate smoothly with devices developed over a decade ago. However, EtherCAT has different application layer communication protocols (Profiles). When a vendor implements EtherCAT devices, they can choose to implement different application layer communication protocols. Therefore, we categorize EtherCAT master devices into Class A and Class B. Different categories of devices represent different levels of implementation of the EtherCAT application layer protocol (as shown in Figure 1: Figure 1 shows the differences between Class A and Class B masters (partial)). For example, some EtherCAT masters only support CoE and do not support SoE, meaning they cannot connect to servo drives that only support SoE. In other cases, some servo drives perform file exchange or configuration through EoE, while a simple EtherCAT master does not implement EoE, and thus cannot connect.
Therefore, when choosing your master, in addition to performance requirements for control tasks, you must also consider whether the master can support all slaves’ application layer communication requirements.
Figure 1. Functions of Class A and Class B Masters (Partial)
02
Consistency Requirements for Slaves
Consistency is crucial for an open technology. Device providers ensure product consistency, which is their responsibility towards the final application. According to the ETG’s Vendor ID Policy, all EtherCAT devices must guarantee consistency. Therefore, during system integration, you need to confirm whether the EtherCAT slave devices meet consistency requirements. So how can you confirm that the slave devices you purchase meet the consistency requirements? Mainly through the following two ways:
A
Request the device supplier to provide an officially issued consistency test certificate
If they can provide an officially issued consistency test certificate from ETG, it indicates that the product has passed authoritative certification, and the product is marked with the “EtherCAT conformance tested” logo. Device suppliers can test and certify at ETG-authorized EtherCAT Test Centers (ETC). After passing the test, ETG headquarters issues the certificate (an example of the official certificate is shown in Figure 2).
Figure 2. Example of Certificate Passed by ETC Consistency Test
EtherCAT consistency testing is conducted according to ETG standard document ETG.7000-2 Conformance Test Record. The test content includes not only items tested automatically by consistency testing tools but also manual tests such as ESI checks, slave status indication tests, device identifier display tests, distributed clock tests, miscellaneous, semiconductor device regulations tests, device identifier tests, interoperability tests, and more.
This method of obtaining a consistency test certificate through official certification is very efficient. Presenting it to system integrators or machine manufacturers can demonstrate that the device has good EtherCAT consistency.
It should be noted that the consistency test certificate corresponds to each version number of the device. When the device is updated, new testing is required to ensure that the updated device maintains consistency. Therefore, please pay attention to whether the product number and serial number indicated on the certificate match the devices being used.
Additionally, ETG-authorized test centers have an interconnection testing environment that includes products from multiple device suppliers, allowing for better testing to see if the device can work with others. Moreover, the EtherCAT experts at the authorized test centers are more professional, and the test results are more authoritative. ETG encourages device suppliers to test at ETG-authorized test centers.
B
Request the device supplier to provide self-completed test results
Device suppliers must guarantee the consistency of their EtherCAT products. Therefore, they must hold valid consistency testing software and conduct self-consistency tests. The test results clearly show which items passed and which did not, as shown in Figure 3.
Figure 3. CTT Self-Consistency Test Results
In addition to using CTT software for testing, suppliers also need to self-test other items specified in the ETG standard document ETG.7000-2 Conformance Test Record and keep testing records.
The above considerations should be taken into account at the beginning of system design. Besides specific considerations for master functions and slave consistency, the design of machines and cabinets, wiring, and other electrical safety characteristics should comply with GB/T 5226. A compliant design will reduce unnecessary debugging and maintenance work in installation, debugging, usage, and maintenance, as well as associated hidden costs.
For any system integration, choosing products from the same brand for integration poses the least risk and higher reliability. At least when problems arise, the manufacturer of that brand will be responsible for all system issues. However, sometimes due to cost requirements or the lack of a complete product line from a certain brand, it is necessary to purchase products from different brands for system integration. In this case, the risk will be borne by the system integrator or machine manufacturer. For Ethernet fieldbuses, because EtherCAT has high performance and flexibility advantages, along with full openness, more device manufacturers support it. Therefore, when products from different brands are integrated into the same EtherCAT system and communication failures occur, facing numerous EtherCAT device providers, system integrators or machine manufacturers should follow the two steps mentioned above, namely, first confirm the master’s functions and the slaves’ consistency issues, and then proceed to other checks.
1
-END-
