-
Notifications
You must be signed in to change notification settings - Fork 32
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix Startup Crash Caused by Read() and Write() on Un-activated Etherc…
…at (#120) * Use at() instead of [], propagate activation failures, lock ethercat * Convert NULL domain debug to string, add additional NULL checks
- Loading branch information
Showing
4 changed files
with
65 additions
and
14 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
52be2c2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this fixbug , is about , when it start up , the motor would run to position 0 quickly ,
right?
52be2c2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi wei1224hf,
It should not change the behaviour of the motor at start-up.
What it does, is that the actual behaviour of the library is to initiate communication with the hardware in the on_activate step (https://control.ros.org/master/_images/hardware_interface_lifecycle.png) which does not respect the hardware interface lifecycle (should be in the on_configure state).
The library is actualing relying on going very quickly to the on_activate step as soon as the configure() call is made which hides the problem for most of the users (Alas! this does not work all the time, it is still cheating after all).
This good fix by tony-laza prevents some crash when communication is attempted before the true call to activate() is performed.
We have a plan to truly follow the hardware interface lifecycle, but in the meantime, this fix will do a good job.
I hope it answers your question.
If you experience new unexpected behaviour with this commit, please report it to us. We will be very eager to fix the issue.