Welcome to our website.
To view product availability in a specific country, select from the country list below. For Investor Relations, please visit our global site.
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:
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:
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.
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:
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:
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.
Results and conclusions
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.
Powered by ContentStream®