Pluto_servo is an emc2 driver and associated firmware that allow the Pluto-P board to be used to control a servo-based CNC machine. The Pluto-P is an inexpensive ($60) FPGA board featuring the ACEX1K chip from Altera. Pluto_servo will be released under the terms of the GNU General Public License version 2. The pluto_servo system is suitable for control of a 4-axis CNC mill, a 3-axis mill with PWM spindle control, a lathe with spindle encoder, etc.
I have been working with Chris to switch from software PWM generation and encoder counting to the Pluto for his CNC lathe retrofit (he's still using his L298-based PWM servo amplifier, similar to the one shown here). The road has been a little rocky, but a version of pluto_servo has landed in emc2's CVS. You can read some more documentation and the manual page. Unfortunately, the pinout of the current firmare is special-purpose for Chris's lathe, and the corresponding verilog files aren't in CVS--in fact, the corresponding files are probably lost because I've edited the source code since that firmware was generated. For this reason, the current versions of pluto_servo_rbf.h are not GPL software and are not redistributable.
When it comes to running the X and Y axes, Chris reports that slow moves are smooth and nearly silent (thanks to the high-speed PWM) and resolution is much better than when he was using the quadrature divider. I assume that the GUI is also somewhat more responsive without anything running in the fast thread, though he hasn't mentioned any difference. (He's said on IRC "if the machine seems at all slower while emc is running, I complain", so I bet he was already using as big (slow) a BASE_PERIOD as he could)
Somewhere in there we lost a week of time because we believed we'd fried the only pluto-p board we had at the time, but it turned out that we were working with a bad firmware file, even though we also went back to what we thought was a known-good backup version. The pluto module and the parallel port are both fine, even after we had a parallel port pin and an FPGA pin both driving the same wire, something which resulted in the FPGA's VCC rising to 4V. When some other weird behavior appeared at the same time, we assumed it was hardware damage.
Besides fixing up the pinout and getting the verilog source in CVS, the main
thing that is keeping me from celebrating this project as "done" is that Chris
is still reporting problems with the spindle encoder. When he rotates the
spindle back and forth, the encoder counts get steadily larger instead of
tracking the actual rotation. The problems may simply be noise or circuitry
problems, or they may represent a problem in the FPGA firmware. After swapping
the spindle with another axis, both axes behaved reliably, so at the moment the
problem seems to be confined to the spindle encoder when it is on quadrature
channel 2, and not at any other time. I can't quite imagine what would cause
that behavior.
Entry first conceived on 18 December 2006, 3:20 UTC, last modified on 10 June 2014, 23:56 UTC
Website Copyright © 2004-2024 Jeff Epler