Controlling a Dynamixel RX-24F (RS-485 coms)

Lawson

I'm trying to control a Dynamixel RX-24F servo. I haven't found an object for it. I have found two objects to drive the Dynamixel AX series servos. (this and this ) But the RX-24F uses RS-485 physical signaling so the drivers need to use a direction pin along with separate TX and RX pins. Beyond that, the manual says the protocol is the same.

Lawson

P.S. I haven't been able to find a serial object that supports half-duplex RS485 either.

JonnyMac

I do a lot of RS-485 stuff; mostly DMX, but have done MODBUS and custom protocols, too. I've attached my half-duplex driver for RS-485 which includes a schematic.

[Edit] Removed code with typo -- replace with new (working) version in post below.

Lawson

Thanks! Figured somebody had made the mods to a serial object to do RS485.

Lawson

Lawson

@JonnyMac: I think there's something fishy with your driver. I'm still trying to get the RX-24F to work and I think one of the problems is that "jm_hd485" isn't transmitting bytes in the TX buffer. Do I have to use something other than "tx()" to output bytes? The current symptom is that I can call "tx()" 128 times, then the code hangs waiting for the buffer to clear. Details in attached code.

Marty

Lawson

It moves! Since the RX-24F defaults to 57142baud I tried using FullDuplexSerial and manually manipulating the direction pin. Had to add a "TxFlush" method to FDX that waits for the TX buffer to clear. I also needed to run FDX in inverted mode, and change the RX pull-up to a pull-down. @#$%#& Robotis labeled the pins of the max485 in the schematic in this order. 1,2,3,4,5,7,6,8.... (minimum working code attached) I'll fix that error and post new code.

Now to wrap this minimum code into an object so I can complete the rest of this project. Later I'll come and port the protocol layers from the other DX series objects to use the RX signaling. Then maybe I'll post an object on OBEX.

Lawson

JonnyMac

I've used the code in many projects without incident -- will have a look to see what's up.

Lawson

@jonny: I figured the code had been used a while. Either I'm missing something, the file got corrupted, or who knows.

Here's the working test code. It still works after I fixed the output circuit and switched FDX back to non-inverted TX and RX. (D+ and D- were swapped due to a poor schematic)

Lawson

JonnyMac

One of the hardest things to track down is an errant label -- somewhere in the melee "rxserial" became "txserial" and the PASM code got trapped in the TX loop. As I was in it, anyway, I unrolled the receive and transmit code so that it can operate as fast as the connected RS-485 chip will allow. I also added some formatted rx routines that I use in simple protocol projects.

The attached code is working in both TX and RX mode. Perhaps you'll find this version useful.

Lawson

Just tested the updated code JonnyMac. Works exactly as expected. Looks like the driver will even support the 1 mega-baud max speed of the RX-24F. (not tested!)

Attached is a bare-bones minimum driver for the RX-24F. All it will do is send position update packets to any servo ID on the buss and listen for the return status packet/byte. At the default 57142 baud it should be fast enough to update 8-10 servos at about 60Hz. (it'll run more at a higher baud rate) For now all configuration and discovery will need to be done with the software and PC dongle from Robotis.

I'll mark this thread as solved and update it with a full driver later.

Lawson

JonnyMac

Looks like the driver will even support the 1 mega-baud max speed of the RX-24F.

Nope -- testing shows that the configuration I use (checking TX buffer while the RX line is idle) limits the throughput to about 800K -- and this is tested using two UARTs inside the Propeller with direct pin-to-pin connections. Using actual wiring would probably reduce that. I'm content with the driver as is; 250K is plenty fast for what I do.

Lawson

Have you actually tested the code at over 1Mbaud? It looks like the receive code could start having problems with consecutive bytes above 1Mbaud. This would be due to the number of instructions between getting the last bit and synchronization with the next start bit. The TX code looks like it has similar limitations, so testing should be done with code that can tight pack bytes at over 1Mbaud. (though at these bit-rates block moves or assembly is needed to keep up with the serial code)

Lawson

JonnyMac

It may not run that fast in the configuration that supports RX and TX in one cog. Perhaps separate RX and TX cogs are best for that kind of speed. I have given you plenty of code for you to work with -- time to step up and write your own now. Show us how it's done.

Update: It seems that the code configuration use where the TX buffer is checked while waiting on a start bit does in fact limit the throughput to about 800K baud. I would suggest you take this code and split it into separate RX and TX cogs to get the maximum possible speed. Come to think of it, that's what happens in Tachyon, the program that inspired me to unroll the RX and TX loops.