Legacy Forum: Preserving Nearly 20 Years of Community History - A Time Capsule of Discussions, Memories, and Shared Experiences.

Minimal USB to Dynamixel interface

Bioloid robot kit from Korean company Robotis; CM5 controller block, AX12 servos..
12 postsPage 1 of 1
12 postsPage 1 of 1

Minimal USB to Dynamixel interface

Post by billyzelsnack » Mon Dec 27, 2010 12:10 am

Post by billyzelsnack
Mon Dec 27, 2010 12:10 am

http://www.youtube.com/watch?v=1lWwNVFtRKI

I tried the Hylands half-duplex trick of just tying together tx and rx with a UM232R. It appears to work. It basically creates a loopback where any data that is sent is received back immediately. Due to the delay in the dynamixel(s) response it is able to have the packet consumed before the response arrives. That's the theory at least.

Pros: Less parts.
Cons: Extra software required to ignore sent packets.

The big question is whether this is a good/safe idea? A secondary question is how is performance effected due to the extra data being looped back.
http://www.youtube.com/watch?v=1lWwNVFtRKI

I tried the Hylands half-duplex trick of just tying together tx and rx with a UM232R. It appears to work. It basically creates a loopback where any data that is sent is received back immediately. Due to the delay in the dynamixel(s) response it is able to have the packet consumed before the response arrives. That's the theory at least.

Pros: Less parts.
Cons: Extra software required to ignore sent packets.

The big question is whether this is a good/safe idea? A secondary question is how is performance effected due to the extra data being looped back.
billyzelsnack
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 618
Joined: Sat Dec 30, 2006 1:00 am

Post by Fraser » Mon Dec 27, 2010 3:19 am

Post by Fraser
Mon Dec 27, 2010 3:19 am

Its nice to know that trick works. I'd be tempted to just trash the echoed loopback data, but maybe it should all be parsed before chucking it, just in case?
Its nice to know that trick works. I'd be tempted to just trash the echoed loopback data, but maybe it should all be parsed before chucking it, just in case?
Fraser
Savvy Roboteer
Savvy Roboteer
Posts: 84
Joined: Tue Nov 30, 2010 2:16 pm

Post by billyzelsnack » Mon Dec 27, 2010 4:37 am

Post by billyzelsnack
Mon Dec 27, 2010 4:37 am

I guess the loopback data might be good for something. I dunno.

Oh.. For fun I tried it out with the dynamixel wizard. It was not too happy with the ping back data!
I guess the loopback data might be good for something. I dunno.

Oh.. For fun I tried it out with the dynamixel wizard. It was not too happy with the ping back data!
billyzelsnack
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 618
Joined: Sat Dec 30, 2006 1:00 am

Re: Minimal USB to Dynamixel interface

Post by Fraser » Mon Dec 27, 2010 12:35 pm

Post by Fraser
Mon Dec 27, 2010 12:35 pm

billyzelsnack wrote:http://www.youtube.com/watch?v=1lWwNVFtRKI
Due to the delay in the dynamixel(s) response it is able to have the packet consumed before the response arrives. That's the theory at least.
...
The big question is whether this is a good/safe idea? A secondary question is how is performance effected due to the extra data being looped back.


Yes, it might have problems if something replied very quickly, the only way to know is set up an AX12 or CM5 to byte echo (using interrupt for lowest delay) and then send a single byte out the rs232 hack, see what you get back.
billyzelsnack wrote:http://www.youtube.com/watch?v=1lWwNVFtRKI
Due to the delay in the dynamixel(s) response it is able to have the packet consumed before the response arrives. That's the theory at least.
...
The big question is whether this is a good/safe idea? A secondary question is how is performance effected due to the extra data being looped back.


Yes, it might have problems if something replied very quickly, the only way to know is set up an AX12 or CM5 to byte echo (using interrupt for lowest delay) and then send a single byte out the rs232 hack, see what you get back.
Fraser
Savvy Roboteer
Savvy Roboteer
Posts: 84
Joined: Tue Nov 30, 2010 2:16 pm

Post by i-Bot » Mon Dec 27, 2010 12:51 pm

Post by i-Bot
Mon Dec 27, 2010 12:51 pm

The trick from Jon takes advantage of two key features of using the interface on the AVR rather than a USB interface.

The first as you identified is that he has full control over the receive path and the receive software. So he can either disable the receiver while transmiting, or discard the transmited bytes as they are received. With the UM232R there is buffering, so you only have the choice to discard the transmitted bytes. This is OK with your own software, but may not work with existing software.

The second feature of the AVR is the capability to tri-state the transmit output. This allows the dynamixels to safely drive the bus when they want to transmit. For the UM232R it appears the transmit is an output without tristate. Thus when the dynamixel sends the reply both the UM232R output (high) and the Dynamixel output (high with low pulses) are on the bus at the same time. It is likely the stronger low drive of the dynamixel will overide the UM232R, but not with reliable operation. One or other driver could get damaged, but that is not too likely.

This means a minimal UM232R interface must have a tristate buffer on the output, and preferably on the input too if you want to use standard software. The UM232R does bring out the /TXEN signal from the FTDI chip which can be used as the enable for a 74HC125 output buffer to control the transmit, and optionally a 74HC126 output buffer for the receive. These buffers are available in DIP packages and also in SMD as a single gate. If you are happy to use SMD, then the http://www.fairchildsemi.com/ds/NC/NC7WZ241.pdf is a single TX/RX pair in one package as used on the USB2dynamixel. They can be powered from the 5V output of the UM232R.
If /TXEN output does not work it may be that you need to configure it on the UM232R using FTPROG.
The trick from Jon takes advantage of two key features of using the interface on the AVR rather than a USB interface.

The first as you identified is that he has full control over the receive path and the receive software. So he can either disable the receiver while transmiting, or discard the transmited bytes as they are received. With the UM232R there is buffering, so you only have the choice to discard the transmitted bytes. This is OK with your own software, but may not work with existing software.

The second feature of the AVR is the capability to tri-state the transmit output. This allows the dynamixels to safely drive the bus when they want to transmit. For the UM232R it appears the transmit is an output without tristate. Thus when the dynamixel sends the reply both the UM232R output (high) and the Dynamixel output (high with low pulses) are on the bus at the same time. It is likely the stronger low drive of the dynamixel will overide the UM232R, but not with reliable operation. One or other driver could get damaged, but that is not too likely.

This means a minimal UM232R interface must have a tristate buffer on the output, and preferably on the input too if you want to use standard software. The UM232R does bring out the /TXEN signal from the FTDI chip which can be used as the enable for a 74HC125 output buffer to control the transmit, and optionally a 74HC126 output buffer for the receive. These buffers are available in DIP packages and also in SMD as a single gate. If you are happy to use SMD, then the http://www.fairchildsemi.com/ds/NC/NC7WZ241.pdf is a single TX/RX pair in one package as used on the USB2dynamixel. They can be powered from the 5V output of the UM232R.
If /TXEN output does not work it may be that you need to configure it on the UM232R using FTPROG.
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by billyzelsnack » Mon Dec 27, 2010 6:16 pm

Post by billyzelsnack
Mon Dec 27, 2010 6:16 pm

My original interface used the tri-state setup, but I was just experimenting to see if it would work. I can care less if I damage the UM232R. My concern is the possibility of damage to a dynamixel and the understanding why it can be damaged.

Does the UM232R RX pin or the Dynamixel signal line during RX ever go high? What I am assuming is that only the UM232R TX pin goes high during transmit from the UM232R and the Dynamixel signal pin only going high during transmit from the Dynamixel. The rest of the time it is low. Is this not the case?
My original interface used the tri-state setup, but I was just experimenting to see if it would work. I can care less if I damage the UM232R. My concern is the possibility of damage to a dynamixel and the understanding why it can be damaged.

Does the UM232R RX pin or the Dynamixel signal line during RX ever go high? What I am assuming is that only the UM232R TX pin goes high during transmit from the UM232R and the Dynamixel signal pin only going high during transmit from the Dynamixel. The rest of the time it is low. Is this not the case?
billyzelsnack
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 618
Joined: Sat Dec 30, 2006 1:00 am

Post by i-Bot » Mon Dec 27, 2010 10:28 pm

Post by i-Bot
Mon Dec 27, 2010 10:28 pm

On the normal Dynamixel bus the steady state is high, pulled up by a resistor. When either the controller or a dynamixel transmit they are enabled onto the bus and actively drive the bus low or high for the duration of the serial data stream only.

In your configuration the bus is actively held high by the UM232R except when driven low by the UM232R transmit serial stream. When the Dynamixel transmits it actively tries to drive the bus low and high. So it is fighting against the UM232R as it drives low. Levels and switching times on the bus are indeterminate and may vary between different devices.
On the normal Dynamixel bus the steady state is high, pulled up by a resistor. When either the controller or a dynamixel transmit they are enabled onto the bus and actively drive the bus low or high for the duration of the serial data stream only.

In your configuration the bus is actively held high by the UM232R except when driven low by the UM232R transmit serial stream. When the Dynamixel transmits it actively tries to drive the bus low and high. So it is fighting against the UM232R as it drives low. Levels and switching times on the bus are indeterminate and may vary between different devices.
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by billyzelsnack » Wed Dec 29, 2010 5:50 am

Post by billyzelsnack
Wed Dec 29, 2010 5:50 am

I decided to just go back to the regular way of doing things..

http://billyzelsnack-robotics.blogspot. ... mixel.html
I decided to just go back to the regular way of doing things..

http://billyzelsnack-robotics.blogspot. ... mixel.html
billyzelsnack
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 618
Joined: Sat Dec 30, 2006 1:00 am

Post by i-Bot » Wed Dec 29, 2010 12:57 pm

Post by i-Bot
Wed Dec 29, 2010 12:57 pm

Probably best. I have used a schottky diode and a pullup resistor (1K0) for driving a single Dynamixel, but that is maybe unreliable at high data rates, long wires and high noise.

On a related topic of USB to RS485 servos (DX, RX, AX). The manual for these servos shows a MAX485 driver without bias resistors for the RS485. I don't have any Robotis RS485 servos, but when we tried this circuit on some clones (SR518) it didn't work. The reason for this was that the RS485 D+ and D- lines needed biasing with external resistors. I see the USB2Dynamixel actually uses the MAX3443E IC which has internal biasing.

Does anybody have the MAX485 circuit from the manual working on RS485 dynamixel ? Or is the manual wrong ?
Probably best. I have used a schottky diode and a pullup resistor (1K0) for driving a single Dynamixel, but that is maybe unreliable at high data rates, long wires and high noise.

On a related topic of USB to RS485 servos (DX, RX, AX). The manual for these servos shows a MAX485 driver without bias resistors for the RS485. I don't have any Robotis RS485 servos, but when we tried this circuit on some clones (SR518) it didn't work. The reason for this was that the RS485 D+ and D- lines needed biasing with external resistors. I see the USB2Dynamixel actually uses the MAX3443E IC which has internal biasing.

Does anybody have the MAX485 circuit from the manual working on RS485 dynamixel ? Or is the manual wrong ?
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by maltejahn » Sat Nov 10, 2012 4:10 pm

Post by maltejahn
Sat Nov 10, 2012 4:10 pm

Hi,

even when this thread is quite old, i think i have the same question.


I got two dynamixel RX-28 Servos, but till now no USB2Dynamixel USB -> RS485 converter.
Now i tried to build one myself. I have here a FT232R and a MAX3430.

I connected it like in this Application Note from FTDI:
Cant post URL link .... Google for FTDI RS485
FT232R -> MAX3430
TXD -> D
RXD -> R
CBUS2 -> DE
CBUS4 -> RE

Using the FTPROG Tool from FTDI i did the following settings:
CBUS2 as TXDEN
CBUS4 as PWRON#
Question: it should be possible to connect CBUS2 to both DE and RE cause RE is inverted??
Do i have to do more settings?
I see a communication on the RS485 Bus (oscilloskop) but RoboPlus Manager could not find any servo device.
Do i have to name my FTDI in any special way, tried this without success:
Google for tekkotsu ftdi usb

I also placed a 130 Ohm resistor between A-B (didnt had an 120 Ohm).

Anyone has a schematic or the FTDi settings? Or any other suggestins?

Thanks
Malte
Hi,

even when this thread is quite old, i think i have the same question.


I got two dynamixel RX-28 Servos, but till now no USB2Dynamixel USB -> RS485 converter.
Now i tried to build one myself. I have here a FT232R and a MAX3430.

I connected it like in this Application Note from FTDI:
Cant post URL link .... Google for FTDI RS485
FT232R -> MAX3430
TXD -> D
RXD -> R
CBUS2 -> DE
CBUS4 -> RE

Using the FTPROG Tool from FTDI i did the following settings:
CBUS2 as TXDEN
CBUS4 as PWRON#
Question: it should be possible to connect CBUS2 to both DE and RE cause RE is inverted??
Do i have to do more settings?
I see a communication on the RS485 Bus (oscilloskop) but RoboPlus Manager could not find any servo device.
Do i have to name my FTDI in any special way, tried this without success:
Google for tekkotsu ftdi usb

I also placed a 130 Ohm resistor between A-B (didnt had an 120 Ohm).

Anyone has a schematic or the FTDi settings? Or any other suggestins?

Thanks
Malte
maltejahn
Newbie
Newbie
Posts: 2
Joined: Sat Nov 10, 2012 3:20 pm

Post by i-Bot » Sat Nov 10, 2012 4:40 pm

Post by i-Bot
Sat Nov 10, 2012 4:40 pm

The USB2Dynamixel uses a MAX3443 which is good up to 10Mbps, the MAX3430 is only good to 250kbps.
The DE and /RE should be connected together and this should be driven by TXDEN.
You might need a pullup (10K on the RO to RXD line).
The USB2Dynamixel uses a MAX3443 which is good up to 10Mbps, the MAX3430 is only good to 250kbps.
The DE and /RE should be connected together and this should be driven by TXDEN.
You might need a pullup (10K on the RO to RXD line).
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by maltejahn » Sat Nov 10, 2012 6:47 pm

Post by maltejahn
Sat Nov 10, 2012 6:47 pm

Hi,
thanks for your reply. But, it also should work with the "slow" version. I only work with 57k6 at the moment.
I found a schematic here:
Google: 3in1 converter – USB to RS232, RS485, UART

So, the physical connection RS485 should work this way, there is also the pullup you mentioned.
I will try it tomorrow, maybe.

Thanks for your help!
Hi,
thanks for your reply. But, it also should work with the "slow" version. I only work with 57k6 at the moment.
I found a schematic here:
Google: 3in1 converter – USB to RS232, RS485, UART

So, the physical connection RS485 should work this way, there is also the pullup you mentioned.
I will try it tomorrow, maybe.

Thanks for your help!
maltejahn
Newbie
Newbie
Posts: 2
Joined: Sat Nov 10, 2012 3:20 pm


12 postsPage 1 of 1
12 postsPage 1 of 1