View Full Version : [Question(s)] Multiple USB2Dynamixels?

08-28-2010, 11:39 AM
I've set up a system where a PC controls 1 RX-64 via USB2Dynamixel. I've written a quick console program in visual c++ for the interface and this works great. Now I am trying to add a sensor that also has a USB to Serial interface, and I am having problems.

Two of the functions I was using (dxl_initialize and dxl_get_baud) don't seem to differentiate between the two USB to Serial devices and are even happy to return success when only the sensor is plugged in and the USB2Dynamixel is not. Two other functions (dxl_read_word and dxl_write_word) work fine when the USB2Dynamixel is plugged in alone, but stop working as soon as I plug the sensor in.

So my question is: how can I specify the port that these functions address? Has anyone succeeded in controlling multiple USB2Dynamixels from a single PC? I guess that would be equivalent to what I am trying to do.


08-28-2010, 11:47 AM
Assuming you are using windows, have you used device manager to see how they are handled and the comports assigned when plugged into the pc?

08-28-2010, 11:54 AM
I'm running XP. Device Manager sees them both as USB Serial Ports. One is COM18 the other is COM 19. I don't know how to leverage this in my program though?

08-28-2010, 04:14 PM
Since you mentioned dxl_read_word and dxl_write_word, I'm assuming you're using the USB2Dynamixel API. The API uses the FTDI's FTD2XX DLL not a virtual com port. You have to modify the implementation provided by Robotis.

Take a look in the dxl_hal.c file and find

ft_status = FT_Open( 0, &ghFt_Handle );
if( ft_status != FT_OK )
FT_Open takes a device index and a pointer to a handle of type FT_HANDLE. Notice that the device index is a hard coded 0. You can have another index 1,2,3... but this is not deterministic... you might not know which device you're connected to.

If you want to open a device by name use FT_OpenEX. ie. FT_OPEN_BY_SERIAL_NUMBER, FT_OPEN_BY_DESCRIPTION or FT_OPEN_BY_LOCATION.

08-28-2010, 05:26 PM
Ah, goto in C code.
It's been ten years since I saw one. :)

08-29-2010, 06:46 PM
@MikeG Thanks for the note. Upon further inspection, both devices are actually using FTDI chips, so I think using the higher level API for either device will likely result in crosstalk. I hope I can figure out how to accomplish everything using only the FTD2XX DLL functions. What a shame to have to abandon the functions from the USB2Dynamixel API that were working so nicely!

08-29-2010, 09:46 PM
If you want to use the API with 2 FTDI chips then you need to identify the FTDI device. You can do accomplish that with an index (FT_Open) or name using FT_OpenEX. The USB2Dynamixel API is just an open source wrapper for the FTD2XX DLL.

Otherwise, you can use the virtual comport. This is one of many Dynamixel APIs that use FTDI's VCP.

08-31-2010, 03:57 PM
Please correct me if you think I am wrong, but I think this means that if I want to use the USB2Dynamixel API then the best I can do is:

1) open the connection to the USB2Dynamixel using FTDI functions
2) talk to it as desired using higher level functions like dxl_read_word()
3) close the connection to the USB2Dynamixel
4) open the connection to my sensor
5) talk to the sensor as desired
6) close the connection to the sensor
7) repeat 1-6 as necessary

The reason for this is because functions like dxl_read_word() do not allow for a specific FTDI chip to be specified, so if both connections were open at the same time then either chip might receive the command.

08-31-2010, 04:51 PM
Here's an interesting result from my debugging attempts:

First, I am able to open and close both devices using the FT_OpenEX. Then with both devices closed, I open only the USB2Dynamixel connection. I call dxl_initialize() with dxl_hal_open() modified to address the USB2Dynamixel by serial number. All this works fine. But then when I call dxl_read_word() or dxl_write_word(), neither function works. If I unplug my sensor, both of these functions work just fine again.

So somewhere in dxl_read_word() and dxl_write_word() there must be a point where they fail to address the specific FTDI chip. I haven't found where yet. If anyone knows I'd really appreciate a pointer.

08-31-2010, 05:35 PM
They use a single global variable to store the serial handle that you open. As the code is written there is no way to address a specific FTDI chip. You'd either need to add a call to set the current/active serial handle or change the API calls to each to accept an abstracted serial handle.

08-31-2010, 08:57 PM
Or you could create a dynamic array of FT_HANDLE pointers. There's several ways to handle the situation all involve code updates but nothing major.