XH430-W210-R horn not turning

Support DYNAMIXEL
1

Hello everyone,

I have a question regarding the manual control of a XH430-W210-R servo motor:

What does it mean if the red LED turns on (solid no blinking) when I enable the torque? How can I resolve the issue?

I have tried troubleshooting this issue myself but had no luck:

  • I am using the protocol version 2.0

  • I can successfully establish an RS485 connection to the servo motor. It also answers with the expected frames to all my requests.

  • I can even write commands to the RAM of the servo motor. For example I can enable the torque which results in the red LED being switched on by the servo motor. If I disable the torque the LED is switched back off. From what I can tell this tells me there is an error. But which one?

  • If I write for example the example write command (DYNAMIXEL Protocol 2.0 5.3.3) to the servo motor it does not move a bit. I suspect it is because of the error. Additionally if I read its current position it also hasn’t changed. I haven’t changed anything regarding the operating and drive modes but reading the corresponding registers gives me their initial default values from the manual.

  • The hardware error register is also 0 and the status packet of the goal position command is also without an error. It’s current position is 2056. With the goal position being 512 it should turn itself. Meaning I request a movement which is not stopped by the moving threshold.

  • When turning the servo on the LED blinks once. At the moment I don’t have a Robotis certified device for the USB connection from a windows machine to the servo motor.

  • I am using a STM Nucleo board attachted to an RS485 converter to communicate with the servo motor. But I think this is not the issue as I get the expected answers from the servo motor if I send a request fo it (as mentioned above).

Lastly I can send you the commands I send to the servo motor and the resulting answer from the servo motor:

Torque on:

PC: <0xFF><0xFF><0xFD><0x00><0x01><0x07><0x00><0x03><0x40><0x00><0x00><0x01><0x41><0x5d> (LED turns on)

Dynamixel: <0xFF> <0xFF> <0xFD> <0x00> <0x01> <0x04> <0x00> <0x55> <0x00> <0xA1> <0x0C>

Hardware Error Status:

PC: <0xFF><0xFF><0xFD><0x00><0x01><0x07><0x00><0x02><0x46><0x00><0x01><0x00><0x3c><0xa3>

Dynamixel: <0xFF> <0xFF> <0xFD> <0x00> <0x01> <0x05> <0x00> <0x55> <0x00> <0x00> <0x53> <0x21>

From what I can tell there are no error transmitted in the servos answers.

Thank you for your help!

2

It seems to me like this might be an overflow issue.

The example command listed on the DYNAMIXEL Protocol 2.0 page is also enabling the torque for the connected actuator.

image

You’ll see that the command is exactly one parameter shorter, with one less 00 byte in the parameter field.

The Torque Enable control table value is at position 64, while LED Enable is at the next position, 65.

What is likely happening is that sending the overly long packet is actually writing the additional <0x00> to the Torque Enable space in memory (disabling the torque), and overflowing the <0x01> into the LED Enable (enabling the LED).

The reason that you are not receiving any errors is likely because technically this is a valid command that is being executed as correctly as possible.

1 Like
4

As Jonathan said, your packet structure is “fine”, but does not correctly access the right address with proper length.

To activate the torque of DYNAMIXEL, The correct packet structure to write ‘1’ at Torque Enable is as follows–With extra explanation, you will get the better understanding of how to build the packet.

Header Header Header Reserved Packet ID Length1 Length2 Instruction Param1 Param2 Param2 CRC 1 CRC 2
0xFF 0xFF 0xFD 0x00 0x01 0x06 0x00 0x03 0x40 0x00 0x01 0xDB 0x66
DXL ID Length_Low Length_High Write Inst Data Addr_Low
(Dec 64)		 Data Addr_High
(Dec 64)		 Write 1 at 0x40 (Torque Enable), Lenght 1

if you would like to write both Torque Enable(64) and LED(65), the packet structure should be below (For ID1)

0xFF 0xFF 0xFD 0x00 0x01 0x07 0x00 0x03 0x40 0x00 0x01 0x01 0x42 0xDB

But as ROBOTIS already provides Indirect Address, utilizing Indirect Address gives better solution.

See Indirect Address utilizaion Byte Stuffung

1 Like
5

@Yogurt_Man @Jonathon Thank you for your very fast responses and the explanation of my error. Now the servo turn as expected and I understand the reasons behind it.

1 Like