When positon mode, driver run previous position instead of the current position set on 0x607A

[clm330]

When I sent position command to driver in position mode, the motor always rotate to previous position set on 0x607A.

ros-canopen version: kinetic controller:joint_state_controller/JointStateController

Graph: See the graph. When 0x6040 rising delay, the driver always run to previous position.

It seems when rising delay, the 0x607A still not update. I try to set a delay at the rising delay to solve this problem but it seems no effect.

cpp file: canopen_402/src/motor.cpp function: Motor402::handleWrite(LayerStatus &status, const LayerState &current_state)

            if(okay) {
                // --------add delay------------
                if(this->mode_id_ == 1){
                    sleep(0.1);
                }
                // --------add delay------------
                std::cout<<"~(1<<Command402::CW_Halt) : "<<std::hex << static_cast<int>(~(1<<Command402::CW_Halt))<<std::endl;
                control_word_ &= ~(1<<Command402::CW_Halt);
                std::cout<<"drive_id :"<<this->name<<" control word :"<<std::hex << static_cast<int>(control_word_)<<std::endl;
            }

Maybe I added the delay in the wrong place, can tell me where to add the delay. It may help debug. Thanks.

[mathias-luedtke]

See the graph

Are you sure that the motor does not just drive into the wrong direction? Could you prepare a graph that steps the position up?

I try to set a delay at the rising delay

If you add a delay to handleWrite, you prolong the communication cycle. These function should never block like this.

[clm330]

@ipa-mdl

Are you sure that the motor does not just drive into the wrong direction? Could you prepare a graph that steps the position up?

See this gragp. I sent the position first time, but nothing happened. It can prove that the driver always goes to the previous position.

This graph is candump -td about 401(mapping 0x607A), I sent 3.3(1487) to 0x607A. Does time affect the program??

This is graph is candump -ta about 401. This graph show sent control_word(201) less than one millisecond after sending position msg. According to the figure above, the total time to send the position is 98 ms. Can the driver receive the position correctly msg before running the command?

If you add a delay to handleWrite, you prolong the communication cycle. These function should never block like this.

About delay. Sometime I found 0x6040 rising delay before position cmd 0x607A changed.

I think it may be that when the position information is rising delay(0x6064), 0x607A has not received the latest location information, so the driver always runs to the previous position. Can I add a delay to control_word (0x6040) for bebug ? If can add, where I should add a delay in source code?

[clm330]

In velocity mode, I find similar phenomenon. I set interval_ms to 500. See the graph.

The actual velocity 0x606C begen to change from 0 after two time interval_ms, even if set interval_ms to shorter time interval.

Is this problem same with the above?

[clm330]

Set the Transmission type to 255, it works normally.