-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot Enable eRob [ZeroErr CIA402 Motor] DC Mode and Random OP State Entry with ethercat_driver_ros2
#154
Comments
ethercat_driver_ros2
ethercat_driver_ros2
I have preliminarily resolved the issue where the ethercat_ros2 interface fails to bring eRob into the OP (Operational) state. The detailed solution is provided in the following project: Project Link. |
Hello ZeroErrControl, Improving the behaviour of the distributed clock is in our development plan, and we could use your use case to make progress on this point. The cia402 drivers that we've been able to test (technosoft, elmo, synapticon, maxon) so far haven't any problems for switching to operational mode in DC mode. Would it be possible to access your servomotor for testing purposes (remotely, for example)? Your kernel logs in experiment 2 show ethercat frame losses (DATAGRAM timed out and DATAGRAM unmatched). Could you test the branch Could you also send me your kernel logs for experiment 3? |
Dear Philippe, Thank you very much for your detailed response and for seriously considering my suggestions. Based on your feedback, I have formulated the following experimental plan: Comparison of DC Performance: Testing the Humble-issue-147 Branch: Kernel Logs for Experiment 3: These experiments will require some time to complete, but I will ensure the results are well-organized and sent to you as soon as possible. Thank you again for your support, and I look forward to continuing this collaboration! Best regards, |
We've carried out some tests, and it's possible that we've found the source of the clock synchronisation problem. |
Dear Philippe, Your identified issue indeed matches the problem we've observed. When the DC mode fails to initialize, the slave falls back to SM mode, and it seems the slave's configuration gets reset. Thank you very much for pinpointing the issue, and we look forward to your solution. Best regards, |
Description
Environment Details
I am using
ethercat_driver_ros2
to integrate ZeroErr's eRob servo motor (compliant with the CIA402 protocol) with MoveIt for motion control. However, the following issues were encountered:These issues prevent the seamless use of
ethercat_driver_ros2
to control the eRob motor.Experiments and Observations
Experiment 1: Removing DC Configuration Code
I removed the following code block from
ec_master.cpp
:Results:
eRob successfully entered OP state.
Running
ethercat upload -p0 0x1c32 1
returned:This indicates that eRob remained in Sync Manager (SM) mode rather than DC mode.
Conclusion:
Removing the DC configuration allows eRob to enter OP state but prevents DC mode activation.
Experiment 2: Forcing DC Configuration
I removed the condition
ethercat_driver_ros2/ethercat_interface/src/ec_master.cpp
check and forced the DC configuration code to execute:Results:
eRob successfully entered DC mode.
Running
ethercat upload -p0 0x1c32 1
returned:0x0002 2
This confirms that eRob was in DC mode.
However, eRob failed to enter OP state and remained in Safe OP + Error state.
Kernel logs showed the following messages:
Conclusion:
Forcing DC configuration enables DC mode but causes synchronization errors, preventing OP state entry.
Another observation: When forced into DC mode, the six-axis system can successfully enter DC mode and transition to OP state, but the single-axis and two-axis systems cannot enter the OP state.
Experiment 3: Using IGH EtherCAT Master
I used a custom IGH EtherCAT master implementation (code link )to control eRob.
Results:
Successfully enabled DC mode.
eRob entered OP state without errors.
All functionalities worked as expected.
Conclusion:
Using the IGH EtherCAT master confirms that the issue is specific to ethercat_driver_ros2.
Analysis
DC Configuration Implementation:
The interval_ parameter and the shift_time calculation in ecrt_slave_config_dc might be incorrect, leading to timing mismatches.
The master application time (ecrt_master_application_time) may not align with the slave's reference clock, causing synchronization issues.
The DC configuration might fail to fully activate all required SYNC managers (e.g., SYNC0).
Synchronization Errors:
Kernel logs show AL status message 0x001A ("Synchronization error"), indicating that the master and slave clocks are not properly synchronized.
Contrast with IGH EtherCAT Master:
The same hardware and configuration worked perfectly with the IGH EtherCAT master, suggesting that ethercat_driver_ros2 has issues in handling DC mode and synchronization.
Recommendations
Verify and Fix DC Configuration:
Ensure interval_ and shift_time parameters are correctly calculated based on the desired cycle time and reference clock.
Check that ecrt_master_application_time properly aligns with the slave's reference clock.
Confirm that both SYNC0 and SYNC1 are properly configured.
Improve Synchronization Logic:
Add debug logs to verify the execution and effects of ecrt_master_sync_reference_clock and ecrt_master_sync_slave_clocks.
Validate that the master application time is set before attempting synchronization.
Enhance Compatibility:
Review and ensure ethercat_driver_ros2 fully supports CIA402-compliant devices like eRob.
Add configuration options or examples specifically tailored for CIA402 motors.
The text was updated successfully, but these errors were encountered: