Ros-CanOpen Initialization Fails

asked 2020-01-15 12:06:27 -0500

JadTawil gravatar image

Hello, I have a SV2D10-C-CE CanOpen Controller from Applied Motion: https://www.applied-motion.com/produc...

I am attempting to use it with ros-canopen. I have mapped the following PDOs, and i ensured that this is reflected correctly in the .eds file:

RPDO1: transmission: 255 mapped: 0x60400010 0x60600008

RPDO2: transmission: 255 mapped: 0x607A0020 0x60840020

RPDO3: transmission: 255 mapped: 0x60FF0020

TPDO1: transmission: 01 mapped: 0x60410010 0x60610008

TPDO2: transmission: 01 mapped: 0x60640020

TPDO3: transmission: 01 mapped: 0x606C0020

When I called the /drivier/init service, the following error is displayed:

[ INFO] [1579109777.314460976]: Using fixed control period: 0.010000000
[ INFO] [1579109830.961996313]: Initializing XXX
[ INFO] [1579109830.962750802]: Current state: 1 device error: system:0 internal_error: 0 (OK)
[ INFO] [1579109830.963268901]: Current state: 2 device error: system:0 internal_error: 0 (OK)
[ERROR] [1579109836.659053103]: Transition timeout
[ERROR] [1579109841.659389982]: Transition timeout
[ INFO] [1579109841.663667053]: Current state: 2 device error: system:125 internal_error: 0 (OK)
[ INFO] [1579109841.663777128]: Current state: 0 device error: system:125 internal_error: 0 (OK)
[ INFO] [1579109841.663908567]: Current state: 0 device error: system:0 internal_error: 0 (OK)
[ERROR] [1579109841.663994661]: CAN not ready
[ INFO] [1579109841.664163760]: Current state: 0 device error: system:0 internal_error: 0 (OK)

I have figured out why this is occuring, to explain, please see the following output of the candump:

  can0  701   [1]  7F
  can0  000   [2]  82 01
  can0  701   [1]  00
  can0  601   [8]  2B 17 10 00 E8 03 00 00
  can0  581   [8]  60 17 10 00 00 00 00 00
  can0  000   [2]  01 01
  can0  701   [1]  05
  can0  080   [0]                     #This block repeats (Sync+PDO transmit) until timeout occurs
  can0  181   [3]  00 14 00
  can0  281   [4]  00 00 00 00
  can0  381   [4]  00 00 00 00        #End of block
  can0  080   [0] 
  can0  181   [3]  00 14 00
  can0  281   [4]  00 00 00 00
  can0  381   [4]  00 00 00 00
  can0  701   [1]  05
  can0  601   [8]  2B 17 10 00 00 00 00 00
  can0  581   [8]  60 17 10 00 00 00 00 00
  can0  000   [2]  02 01

As you can see, the first tpdo transmit, which is mapped to the status word, is returning the the value 0x1400, which corresponds to the "NOT READY TO SWITCH ON" State. When the device is in this state, the ros-canopen driver waits until the controller automatically transitions to "SWITCH ON DISABLED", from which the ros-canopen driver begins to write the control words necessary to transition up to "OPERATION ENABLED". At first i thought there is a problem with my controller firmware/hardware, that was preventing it from transitioning to "SWITCH ON DISABLED" on power up. However, after inspecting this with SDO requests for the status word, I realized that the controller was properly transitioning to "SWITCH ON DISABLED" on power up. I then realized that the ros-canopen driver was doing something that the controller did not like, and which was preventing it from re-transitioning to the "SWITCH ON DISABLED" state. After inspecting the above candump ... (more)

edit retag flag offensive close merge delete