# [SOLVED] ros_canopen: "Did not receive a response message"

Hello!

I have established a working package that drives a servo motor through ros_canopen. The earlier problems with solutions is given in the question: here.

Even though i am able to both control the servo motor with a position_controllers/JointPositionController in required_drive_mode: 1 and read the actual position through the /joint_states topic,

it bothers me, that i get often (for example after 1 minute of testing the position controller) the following error messages in the terminal:

Did not receive a response message
abort1001#0, reason: Client/server command specifier not valid or unknown.
Could not process message
Did not receive a response message
abort606c#0, reason: Client/server command specifier not valid or unknown.
Could not process message
Did not receive a response message
abort606c#0, reason: Client/server command specifier not valid or unknown.
Could not process message
Did not receive a response message
abort606c#0, reason: Client/server command specifier not valid or unknown.
Could not process message


Nothing crashes, i am still able to control the motor continuously, but the aforementioned error messages pop quite often, and it bothers me a bit.

Can you help me what could be the problem that causes these issues?

Regarding the CANopen setup, i have:

sync: interval_ms: 100


I use only one TPDO and one RPDO:

RPDO1: 0x60400010, 0x607a0020

TPDO1: 0x60410010, 0x60610008, 0x60640020


I tried both with transmission type=255 and transmission type=1 (in 1400sub2, 1800sub2). In both cases the motor control works, and the aforementioned error messages pop frequently.

Thank you for the help in advance.

Best regards, Akos

edit retag close merge delete

Sort by » oldest newest most voted

As @Mathias Lüdtke wrote, the situation was that

606C is read via SDO and not PDO.

This was confirmed once i check the candump. Therefore i tried different ways to modify/update the PDO mapping, but no working PDO mapping combination was found for days beside the one that i posted originally in the question.

This was wrote by me earlier in the comment section:

I tried to map 606C two different ways: 1) if i put it in 1A00sub4 then the driver/init crashes. If i put it in TPDO1 (1A01sub1), i dont get joint velocity values in joint_states

Indeed, the 1) first option was not possible to be performed, cause that way the 8 byte limit is exceeded. (later i realized..)

The 2) second option should have worked from the begining, but unfortunately for days it did not work and i could not understand what makes the problem..

Finally, after spending lots of hours analyzing the candump, taking observations it was concluded that still something is wrong with the EDS file, namely the mapping we set is not received in ROS.

The errors were the following:

[1401sub1]
ParameterName=COB-ID used by PDO
DefaultValue=$NodeID+0x80000300 ----> THIS SHOULD HAVE BEEN: +0x300 [1402sub1] ParameterName=COB-ID used by PDO DefaultValue=$NodeID+0x80000400   ----> THIS SHOULD HAVE BEEN: +0x400

[1403sub1]
ParameterName=COB-ID used by PDO
DefaultValue=$NodeID+0x80000500 ----> THIS SHOULD HAVE BEEN: +0x500 [1801sub1] ParameterName=COB-ID used by PDO DefaultValue=$NodeID+0x80000280   ----> THIS SHOULD HAVE BEEN: +0x280

[1802sub1]
ParameterName=COB-ID used by PDO
DefaultValue=$NodeID+0x80000380 ----> THIS SHOULD HAVE BEEN: +0x380 [1803sub1] ParameterName=COB-ID used by PDO DefaultValue=$NodeID+0x80000480   ----> THIS SHOULD HAVE BEEN: +0x480


This was also confirmed by Mathias.

The realization of these errors were so so frustrating, since the CANopen manual provided by the manufacturer listed the right defaultValues, and we assumed from the begging (wrongly) that the EDS file is in harmony with the manual. It took us weeks to realize that the root of every question i posted here ( #q294210, #q294570, #q294869, #q295935)

was related to a wrongly written (or not checked, or idk) EDS file. Nevertheless, the lesson was learnt.

I want to thank again @Mathias Lüdtke the constant help, support, hints and answers.

Best regards, Ákos

more

This could be a bug. (Either in ros_canopen or the motor controller)

abort1001#0, reason: Client/server command specifier not valid or unknown.

Not sure why the controller aborts the read request.

Could not process message

This error was printed because of the abort. It's a little bit redundant.

An SDO message was received, but we did not expect one. Normally, this should not happen.

Please try to create a short candump log that contains the full communication.

abort606c#0, reason: Client/server command specifier not valid or unknown.

It looks like, 606C is read via SDO and not PDO. This might lead to problems because it blocks the control cycle. Please check your PDO mapping (again).

more

Hello Mathias! I will try to make a short candump, but the occurrence of the error is not deterministic, sometimes its after 30 sec, sometimes its after 100 sec. Before i make the candump, can we please talk once more about the PDO mapping? (Next comment)

( 2018-07-05 06:56:55 -0600 )edit

Currently 606C is not even mapped to TPDO. (But still i get the joint velocity through the joint_states topic). I tried to map it two different ways: 1) if i put it in 1A00sub4 then the driver/init crashes. If i put it in TPDO1 (1A01sub1), i dont get joint velocity values in joint_states

( 2018-07-05 07:03:07 -0600 )edit

Can you please recommend in what way to map 606C? Please take into account the current mapping that is given in the question. Thank you for your help

( 2018-07-05 07:04:38 -0600 )edit
1

You cannot add it to to TPDO0 because this exceeds the 8 bytes limits. TPDO1 seems to be deactivated by default (\$NodeID+0x80000280).

( 2018-07-10 15:31:43 -0600 )edit

Dear Mathias! Indeed that was the problem. We found this two days ago (sundday ~3AM nighttime) after spending 5 hours on debugging the candump. I did not have time to update this post, but now i am doing it. I want to thank you again the help, the responses and the hints. Best regards, Ákos

( 2018-07-11 02:59:01 -0600 )edit