Intermittent EtherCAT Communication Fault on NexBot Vision SD131-003 Servo Drive

Description

We have installed a new NexBot Vision SD131-003 Single-Axis Servo Drive to control the J3 axis on our R-50 robot. The drive is powered with 480VAC and is connected to our master controller via EtherCAT. We are experiencing intermittent communication loss. The drive will run for a period, sometimes hours, but then will fault, causing the entire production line to stop. The drive's status LED begins blinking amber, and our controller logs an E-2103 error, indicating a lost slave device. We have swapped the EtherCAT cables with known good ones and checked the connections at both the drive and the upstream device, but the problem persists. This is a new installation, replacing a previous drive that failed. All other drives in the daisy chain are functioning correctly. We need to determine if this is a configuration issue or a faulty drive before it impacts our production quota.

Symptoms

• Drive drops from EtherCAT network intermittently
• Controller logs a 'Slave device not responding' error
• Drive status LED blinks amber after faulting
• Causes unplanned production line stoppage

Resolution

The investigation determined that the customer was using an outdated EtherCAT Slave Information (ESI) file in their master controller project. The new NXB-SRV-SD131-003 drive was shipped with updated firmware that required a corresponding ESI file (v1.4) to correctly handle certain PDO mapping and watchdog timer settings. The older ESI file (v1.2) in the customer's project caused a configuration mismatch that would only manifest after extended operation. Guiding the customer to update the ESI file and refresh the device configuration in the project resolved the intermittent communication drops.

Resolution Steps

1. 1. Directed customer to the NexBot support portal to download the latest ESI file package for the NXB-SRV-SD131-003.
2. 2. Instructed the customer to open their controller's engineering software and import the new ESI file (version 1.4).
3. 3. Guided the customer to locate the problematic drive in the EtherCAT network tree within their project.
4. 4. Had the customer right-click the device and select 'Update Device Description' or 'Replace Device', pointing to the newly imported profile.
5. 5. Instructed the customer to perform a full project recompile and download the updated hardware configuration to the master controller.
6. 6. After a power cycle of the control cabinet, confirmed with the customer that the drive maintained a stable connection for over 24 hours of continuous operation.