Improving motion network noise immunity
Automatic retry can double the noise immunity of real-time industrial Ethernet-based motion networks.
Most modern motion control systems employ Ethernet-based networks to transmit data among various electrical and electronic components. The electrical noise immunity of these networks is critical to operation, as are the methods employed to deal with interruptions in data transmission due to electrical noise and other factors.
Designers of real-time motion control systems expect Ethernet-based motion networks to transport cyclic command and feedback data at specified intervals with perfect data integrity. The designer’s selection of the motion control system’s gains and trajectories is predicated on this fundamental assumption.
But in many industrial applications, Ethernet cabling must be located in the presence of electrical noise caused by power switchgear, large motors, or other electrically noisy equipment. If such noise interferes with the network and causes data loss, the designer’s assumptions are invalid and the system will not behave as designed. Problems such as control loop instability and tracking errors can result, as can other operational issues.
To optimize system performance when real-time Ethernet networks must be operated in electrically noisy environments, potential data loss due to noise must be characterized and accounted for in the system design.
One strategy to reduce data loss is to use a network protocol that incorporates retry, which is a mechanism for automatic retransmission of corrupt or missing data within the same transmission cycle. If retry is built into the network hardware, no explicit action is required by master or slave to detect errors or trigger data retransmission.
This article quantifies the contribution of retry to improved noise immunity by testing the noise immunity performance of two real-time industrial Ethernet protocols and comparing the results. The two real-time industrial Ethernet protocols are Mechatrolink-III, which includes retry, and network X, which does not. Although the trade name of network X isn’t specified in this article, its noise immunity performance is similar to other Ethernet-based motion control networks that don’t incorporate retry.
Factors that influence the noise immunity of a motion network include:
- The noise immunity of the physical layer. Relevant design factors include properties of the network cabling (shielding), the signaling scheme (single-ended vs. differential), and details of the transmit and receive circuitry (isolation, impedance, filtering, etc.).
- The noise immunity of the communication protocol. Relevant design factors include the protocol’s error detection and correction mechanisms.
Most real-time industrial Ethernet protocols use the same physical layer, specifically 100Base-T Ethernet. For networks based on similar 100Base-T hardware, the physical layer is not a differentiating factor for differences in noise immunity performance. However, because Mechatrolink-III and network X nodes are implemented on different application-specific integrated circuits (ASICs), it was not possible to test both networks on exactly the same hardware.
In this investigation, differences between the Ethernet physical layer implementations for the Mechatrolink-III and network X networks tested included:
- Different Ethernet connectors and cables
- Different Ethernet physical layer circuitry and printed circuit board layouts
- Different Ethernet communication ASICs.
The Mechatrolink-III protocol includes checksum and watchdog mechanisms for detection of corrupt and missing cyclic data, as well as a retry mechanism for automatic retransmission of corrupt or missing data within the same transmission cycle. When enabled, retry is a fully automatic feature built into Mechatrolink-III hardware, so no explicit action is required by master or slave to detect errors or trigger data retransmission (see Figure 1).
The network X protocol uses checksums to detect data corruption, but provides no mechanism for automatic retransmission or retry within the same cyclic update period. If a cyclic data packet is missing or is corrupt, the master or slave must go without its command or response data until the next cyclic data packet arrives successfully.
This lack of retry is a fundamental difference among real-time industrial Ethernet network protocols. In the case of Mechatrolink-III, there are dedicated time slots for each node, which makes per-node retry feasible. By contrast, many other Ethernet-based protocols prioritize data throughput above allocating bandwidth to a retry mechanism, making the implementation of a retry mechanism infeasible.
Mechatrolink-III and network X motion networks were set up a in a noise-testing laboratory. A noise simulator was used to inject electrical noise into the motion network cabling while each network was in operation. During testing, both master and slaves were observed for indications of data loss on the motion network. The overall goal of the testing was to determine, for each network configuration, the lowest magnitude noise voltage level (positive and negative) that caused data loss.
The simulated noise that was used in this investigation is called impulse noise. This method of generating noise is commonly used to simulate noise encountered in industrial environments. Associated industrial standards include Nippon Electric Control Equipment Industries Association guideline TR-28 and Japan Electrical Manufacturers' Association guideline JEM-TR177.
Each test run consisted of injecting noise for 10 minutes, or until data loss was observed (see Table 1). The test configuration for both motion networks consisted of a master commanding two servo amplifiers (see Figure 2). The master sent data to the amplifiers at a cyclic update rate of 4 kHz. Power supply, I/O, and earth ground connections for both the master and amplifier hardware were made according to the manufacturer’s installation instructions. Accessory noise filtering devices, such as ferrite cores, were not used on the motion network cabling.
The Mechatrolink-III and network X motion network configurations that were tested are shown in Tables 2 and 3, respectively.
Different configurations of the Mechatrolink-III master were tested. In the first configuration, retry was disabled. In this configuration, lost cyclic data packets are not resent. In the second configuration, retry was enabled. In that configuration, the master triggers the resending of up to one lost cyclic data packet per transmission cycle.
The motion network master and slaves were observed for signs of data loss during each test run. For Mechatrolink-III, the following indicators of lost data were checked:
- Controller alarms or warnings related to lost or unexpected Mechatrolink data.
- Drive alarms or warnings related to missing or unexpected Mechatrolink data
- Interrupted motion.
Because the Mechatrolink-III master and slaves that were tested are designed to raise an alarm whenever loss of cyclic data is detected, drive and controller alarms are sufficient indications of data loss on the motion network.
For network X, the following indicators of lost data were checked:
- Cyclic redundancy check error counters (count of incidences of data corruption on the network)
- Lost frame counters (count of lost Ethernet data frames)
- Transmit/receive error counters (count of errors when communicating with the PC Ethernet adapter).
- Drive alarms or warnings related to missing or unexpected data
- Interrupted motion.
Note that, unlike the Mechatrolink-III network that was tested, the designer must take explicit steps to monitor error counters on network X. Otherwise, undetected data loss may occur.
The Mechatrolink-III network was tested with retry disabled, and with retry enabled, which is the normal setting. Data loss with retry disabled occurred at -2,500 V and +2,000 V. With retry enabled, data loss occurred at -3,000 V and +3,000 V (see Table 4). This indicates that retry improved MECHATROLINK-III noise immunity by up to 1,000 V.
By default, the Mechatrolink-III slaves that were tested generate alarms if data loss occurs that cannot be corrected by the retry mechanism. In the absence of these alarms, the application engineer is assured that data loss has not occurred.
Network X data loss was observed at -2,000 V and +1,500 V (see Table 5). The Network X slaves that were tested did not, by default, generate alarms in the case of data loss. For slaves such as these, the application engineer must either change configuration parameters or implement controller software to monitor internal counters to determine if data loss has occurred.
Therefore, the Mechatrolink-III network implementation that was tested in this investigation, when configured to use retry, had twice the noise amplitude range with no data loss compared to network X (see Figure 3).
Ethernet-based motion control networks designed to incorporate retry have significantly better performance when transmitting data in the types of electrically noisy environment typically found in industrial plants and facilities. This superior performance is delivered at a price point similar to networks that don’t incorporate a retry feature.
Derek Lee is a motion product engineer with Yaskawa America Inc., and has held this position for 8 years. He is based at Yaskawa's headquarters in Waukegan, Ill., and is a representative of the U.S. branch of the MECHATROLINK Members Association.
Ted Phares is an embedded systems development manager and has been with Yaskawa America Inc. for the last 6 years. He is based at Yaskawa's development office in San Francisco and has 15 years of experience in the industry.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.