RS485 servo drives

I have 3 BLuDC4-S servo drives from Applied Motion paired with some 200W servos to drive my micromill. They have a STEP/DIR interface, but also an RS485 command interface. They speak an Applied Motion proprietary dialect of commands that allow you to set acceleration/deceleration speeds, and a 'move N steps' command. There's some magic to synchronize the command streams across multiple drives. The only problem is that the interface doesn't go above 115200bps which means 14.4kB/s. The commands are a few bytes (4-ish) large, so 3600 commands per second is the theoretical max. Little bit of wet-finger work, but I think for most moves 3 commands are enough. Three drives, three commands, so we're looking at roughly 2.5ms to program all 3 axes for a move.

The commands buffer relatively deeply, but is there even a remote chance of this being a feasible interface? Effectively it's moving the stepgen off the host computer and into the drives.

My first question is why you would want this over step and direction commands?
Any buffering of commands is not a good solution for linuxcnc.
You would need to build a realtime component to convert linuxcnc's commands to serial commands.
I do not know of a realtime serial driver.
This seems like a lot of work for no advantage - unless you just want to do it as an exercise.

Chris M

Basically, I have to wire the RS485 links anyway as they give me helpful status from the drives (I'd like to know when a drive faults so I can shut everything down), and I was hoping to reduce the amount of wires I have to run. I'm not worried about writing the realtime component, nor am I worried about writing a 16550 serial driver. My main concern was the large latency from this rather low entropy protocol and the more I think about it the more it is (as you say) not worth it. Time to go wire up a BoB.