[PaulMakesThings]

I’m looking at using Dimension Engineering Sabertooth drivers paired with their Kangaroo 2x motor controllers for a light duty CNC machine. I know these aren't industrial shop grade, but I have most of the parts to try it out with 2 axis (1028 line encoders, DC gear motors, Kangaroo units) so it seems worth testing. What I’m wondering is if there is a good way to synchronize these, and what interface hardware and machine control software I can use with them. They use RS-232 to take move commands consisting of a position and a speed. Each one runs 2 motors, and I would like to run a 3 units driving 6 motors, so I will need a way to communicate with several at once and synchronize them. On the hardware end should I install PCI serial cards in my PC, use a multi output USB to RS-232 adapter, or use some other kind of interface board? On the software end, can anyone recommend machine control software that will send G-code over RS-232? I've read that Mach 3 and EMC 2 do not.
Thanks!

[Al_The_Man]

I would think that RS232 is not a very good medium, it is one of the slower protocols out there.
Al.

[PaulMakesThings]

I thought speed might be a hang up of using these controllers. Unfortunately the only other communication methods they support are analog and RC style PWM. Their maximum speed for 232 is 115.2 kbaud. it seems like it would mainly become a problem when describing curves in which several small segments would be sent rapidly, but I'm not really sure how high of an update rate is typically needed.

[laserted]

Paul - 115Kbaud would be "workable" on the Kangaroo for things like a stylus drawing in sand, or an etch-a-sketch - you didn't really describe your application. Neither USB (anything) or PCI/onboard serial ports are considered real-time, thread-safe or time-domain safe* (although the pci-based serial ports do tend to be a bit more stable), so in a multi-port configuration you may get lucky and have pseudo-coordinated motion, but most likely not. Potentially, you could miss one axis of output altogether, whoops. USB just isn't the savior of the world. (*in LCNC or a Win-based Mach setup.)....You will sacrifice precision and speed here immediately.

Let's get the advertisements out of the way: I am a LCNC and Mach guy, although I lean very heavily towards the LCNC for my more 'serious' work, and when that isn't appropriate, I'm opening boxes with Fanuc and Siemens labels on them (and occasionally heeding Al's advice on the Fanuc stuff - Hi Al!)

I have used DE's products (not yet the Kangaroo, but Sabretooths a bunch) in our RC controlled roving vehicles that have close proximity work to theme park guests. I trust them, they are a very nice product, and running them from Futaba-style PPM as intended works very well. I power them via car batteries, and they typically have slower acceleration / deceleration curves that a closed-loop servo drive, so I cannot speak for how well it handles any type of back-drive energy. DE has always been very proud of their 'milliohm mosfets' and derating, so maybe it's a non-issue by luck or design. To be fair, I also use similar products from 3 other manufacturers (Vantec, InnovationFirst and RoboteQ) and have been able to blow up controllers from two out of that list. When a motor decels quickly, that energy has to go somewhere....again, that tends to be more of an application-specific concern, many times (in the RC land) it doesn't cause a problem.

DE notes encoders up to 1000 ppr, that's ok for a small dc servo drive on a leadscrew. Micron-level repeatability will be out of reach, but slow moves the controller and Kangaroo could likely handle. Their documentation advertises that the auto-tuning is really simple (push a button and walk away, with no future tweaking) however my instincts tell me that this setup would have a different response under cutting loads, another point that would keep your travels slower. Perhaps not a big issue for a desktop router with a dremel spindle cutting balsa wood. Surprisingly, they show a linear slide example, so it wasn't just closed-loop-battlebot drive applications they were planning for. Due to the non-real-time nature of the serial port drivers (either control) you would likely not succeed at reading back the status from the Kangaroo - stick with just outbound streaming, and get the feedback into the control another way (like raw encoder counts).

However, if you're considering Mach or LCNC as your control, why not look into a compatible path for the system? example, Gecko 320 drives are ready-to-go drives in either control platform. Their cost is slightly less than double the DE path, so if cost is an issue, that's understandable. Your personal time and attempts to develop and the frustration that may accompany it may offset the dollars difference. If you're not "Developer-inclined" with either control platform, it's unlikely you can get much farther - in both camps the primary developers will not be too engaging on implementing an immediate solution for you in this particular circumstance (my opinion). But then again, neither would Fanuc or Siemens.

If the hobby and learning experience is really in your blood (and of course it must be if you're here!) then getting a single axis going first (or axis set with the Kangaroo) would be a task I bet no one has ventured forward with yet and you're a trailblazer. (Stick with a motherboard that has multiple onboard serial ports so the addresses stay the same after a reboot, and pretend USB never existed) You're probably going to have to use the Kangaroo's "simple" protocol for speed, and do all the math and motion coordination in the PC.

Potential challenges:
Coordinating deceleration at a corner or chord-like-segment will be the key. LCNC's motion planner has no idea what you're doing, so you'd have to write a component to take the position command and convert it into an appropriate serial command. It looks like the Kangaroo's position destination register is either arbitrary or a 1:1 match for encoder counts. If encoder counts, that can be handled. If it's relative-arbitrary, then you're in for some fancy math. In LCNC, I'd prefer to keep the PID loop in the computer in this case, and regardless, it would be beneficial to copy the encoder signals back into the computer for a solid reference. Having two competing loops for position however can be a hassle, cause lots of grey hair, but can be done. (Of this I can attest, as I have lots of grey hair!) In regards to Mach, I believe it can be done via custom macros, as I've had one machine that sent a serial command for accessory control, the API is exposed just enough that it could be written, but to be honest, the last time I had to write macros from scratch Art was still (actively) working on the project. Either way, there will be latency and that will cause jitter you will have to filter out.

You should find a couple folks on the Mach forums that can give example snippets of taking an axis command and performing math, and someone else taking a variable and sending it out the serial port. And someone else giving an example of introductory macro programming. Likewise on LCNC's side, there are arduino connection projects that were using serial ports as userspace components or python scripts - the same trick - take snippets of examples and piece the necessary parts together.

I don't think there's a pulse-train macro for Mach out there that can do PPM, but there was a comp for LCNC that did it at one time - however IIRC, it was "official" 7 channel Futaba PPM, which is pretty low resolution. You would HAVE to use the Sabretooth in velocity/speed mode only (no Kangaroos) and bring the encoder back into LCNC where the PID loop would reside. I would be overjoyed if two axes garnered a cutting feed rate of much more than 0.1" per sec, though. Update rate at 20ms on 7ch ( a mere 50 hz) isn't really fast enough to keep up with a high-resolution encoder - lots of overshoot possibilities there.


Don't know if this has been of any help, but it could stand to be a fun project regardless!

Cheers,
Ted.