Monday, May 13, 2013

Rutex drives, and why I don't use them anymore.

November 2012-March 2013



Since the Lagun mill didn't have any drives when I brought it home, I originally thought I'd be using Geckodrives to power my mill project, because a lot of other people have had success using them. They're cheap, effective, well supported and have a lot of dedicated followers on CNCZone and elsewhere. I had been using ebay to scope out my options as far as servo drives go and stumbled across a set of 3 Rutex 2010 drives really cheap ($60/ea) and that upset my initial plans, because I thought I could save some money and time in getting my mill from its unfinished state to making chips. Unfortunately it didn't work out, and I have written up some praise and criticism of the Rutex R2010's for the sake of anyone who is considering them. When I was searching out the pros and cons of using them there was not any such information out there for me to use and I hope that by sharing what I've found that I'll save someone else some hassle.

On paper, the Rutex drives are great - for a comparable price the R2010s handle more voltage than the Geckos, offer software based tuning that doesn't require an oscilloscope, and offer a modular main board and differential line drivers that interconnect simply.

Before I completely tear into Rutex for their products, I will give them a few praises for things they did right. On their software, the whole auto-reverse to tune works great, and now that I'm tuning with HALScope on LinuxCNC, I have a better appreciation for how good it does work.

I also like that the R2XTuneVB6 software had up/down buttons on the variables for P, I, D, etc and that the changes to variables was "live" and didn't require a keystroke or mouse-click to download the changes to the drive.

That said, I'll bullet a few points that I think Rutex needs to address in order to make their drives a viable option for the DIY CNC crowd:

- Ditch the SPI protocol. Rutex uses SPI to tune, and as far as I can tell its as buggy as can be. The R2XTuneVB6 software apparently can't properly calculate overshoot if there's a serial interruption or error, so instead of displaying a correct overshoot number it automatically jumps to a number over 32000.

- The R2XTuneVB6 software can't really deal with communication outages, and this wouldn't be so frustrating if it didn't reset all the variable values to zero when that happens.

I tried to brainstorm a number of things that could be causing the problem (for whatever reason it was worst on my Z-axis) and tried the following to make the tuning communication problem go away:
Swap differential line drivers
swap cat5 cables
swap encoders
swap PC's
swap motors
check grounds on PC, power supply, mainboard
change shielded cable on motor
change cat5 cable with another brand
swap a custom made tune cable for an R2110 mainboard

Needless to say none of these things worked, and I had to endure nonstop resets and infuriating loss of variables in order to even get close to a tuned axis.

- Fix your broken documentation. One of my motors had a CUI capacitive encoder on it, and after trying for many hours to figure out why it wouldn't play nice with the drive I called and talked to Rutex USA, who told me that CUI capacitive encoders have known problems with their drives. Yet the rutextest.doc document I downloaded from their website mere days before the phone call showed an identical encoder mounted on a Keling motor. Their tech docs and phone support have conflicting information spread across several documents. Additionally their documents are in several formats (!) and there is not a single document that shows how their "system" is supposed to work or integrate.

As of writing there's no explanation on the website or support documentation as to what the difference is between the different polarized and non-polarized motherboards that Rutex USA sells.

I also ran into problems early on getting bidirectional communication to work at all, and it was a bios setting problem but none of the suggestions in the R2000setup document fixed it. I suspect this may be a difference inherent to Dell bios but as many people are repurposing Dell machines as CNC controllers its probably worth mentioning.

- Sell breakout & interconnection hardware, don't force people to hunt thru digikey and ebay to get things like DB-25 and DB-15 cables and IDC connectors.

- Sell breakout boards, or put screw-type headers on your main boards for limit switch and estop connections. I don't believe that very many CNC retrofit projects work without changing things up from their original "plan" and screw terminals make changing plans much easier than re-soldering a DB style connector.

- Get rid of the cat5 encoder interconnects. Originally I though that this was a great idea and so much simpler than stringing wires, until I realized that TCP/IP comm over cat5 is designed around resilience to packet loss and signal degradation, and an RS-422 line driver has no such safeties against lost signals. Additionally most cat5 cable isn't designed to be flexible and without additional punchdown tools and extra ends, isn't easily run thru a strain relief to keep from damaging the drives or line drivers.

In conclusion, I eventually did what I should've in the first place and dumped the Rutex drives, main board, breakout hardware, encoder line drivers and cables on ebay to someone else with more patience than I have. I then called Mesa and did what I should have done in the first place - bought a 5i20 FPGA card, 2x 7i29 H-bridge drives, 2 interconnection flat cables, mounting hardware and a 7i37TA interface daughterboard.