Chris is "successfully" running his lathe with a firmware. I used the scare quotes because there have been a few problems, not all of which have been resolved. But he reports that he was able to get better tuning, quieter moves, and of course higher resolution without the /16 quadrature divider.
The most perplexing problem we've run into is that of reliably resetting the pluto. On my laptop, it "just works": when the pluto_servo component unloads, the device unconfigures and will nicely reconfigure at the next run. On his machine, we have to do a silly sequence instead: exit emc2. unplug pluto from the parallel port, then unplug the wall-wart. wait a few seconds, then re-plug wall-wart first, then parallel, then re-start emc2. I don't yet know why this is. At present, I have two theories: First, that the device isn't successfully deconfiguring, so that the next configuration attempt can't succeed. Second, that whatever happens on the parport after the deinitialization actually sends a few bits down the wire and so the next upload of the firmware data seems to be invalid. Because the pluto_servo HAL driver works fine with a device that was already configured when it starts up, I lean towards the explanation that the ACEX has been deconfigured but something is preventing the next configuration attempt from working.
The next to most perplexing problem turned out to be a result of noise introduced by the spindle motor and seen on the spindle index pulse. Before, the index pulse was read by the (slow and probably higher-capacitance) parallel port directory. Now, the index pulse is read every 25ns by the ACEX which seems to have much more noise sensitivity. With a small-value capacitor across the index line, things are better but I still don't trust it yet. I hope Chris will do a fresh design with a Schmitt trigger to improve noise immunity--or even go all the way and use one of these "26LS32 differential receiver" chips that jmk mentioned on IRC (the spindle encoder has differential outputs, but the X and Z axis servos don't). I've been spoiled by the Schmitt triggers on all AVR pins! (as well as by the higher minimum voltage for a 'high' input when running 5V logic)
The IRC discussion also helped me finally understand what the phrase "nasty metastability issues" means (I think, anyway). I had occasionally seen a behavior where the count-after-index would be around 16384 instead of around 0. The logic if(Z) index_count <= count; was based on a non-registered Z, which was not guaranteed to be stable while the logic was being evaluated, so weird stuff could happen (like only half the bits from count being copied into index count). I've now added a 3-stage register for the index input, which should not only let me avoid the "metastability" problem, but also lets me filter out spikes shorter than 3 clocks long (75ns @ 40MHz). I haven't tested this change yet, but I'm hopeful it will improve the behavior of the index pulse.
I'll be putting a new version of the pluto_servo firmware and HAL driver online in a few days. This time with nice shiny GPL notices in the source files! One roadblock is not being exactly sure what files I need to include...
The feature list has changed a bit since I last wrote about the servo firmware. Mostly for the better, but sometimes for the worse:
- EPP communication with the host, about 100 microseconds communication time. (this is not an increase: the 45uS figure from the old post was just inaccurate)
- 4 quadrature channels, sample rate 40MHz to a 14-bit counter (expanded to 32 bits in software), index pulse supported. The axis with index pulse must have less than 8192 (2^13) counts per revolution
- 4 PWM channels, "up/down style", 2048 duty cycles, PWM period approximately 20kHz (still need to implement the min-dc and max-dc parameters from pwmgen)
- 16 digital outputs: 10 dedicated, 6 shared with PWM function
- 20 digital inputs: 8 dedicated, 12 shared with Quadrature function
- 531 of 576 logic elements used (92%) -- running out of room for added features
Chris ordered two more plutos--one for him, and one for the inevitable "oops, I just fried it". I successfully resisted the urge to try one of their more powerful boards (which are serial or USB connected)--when I outgrow the pluto-p I think I'll go straight to the mesa 5i20, unless I decide to go nuts and design my own parport-connected fpga board.
In fact, I'm very tempted to do a board of my own. Contrary to everyone's
belief, the inexpensive servo machine is possible. For the cost of a Pluto
board and a 3-axis L298 setup (no L297s), you can drive a 3-axis servo system.
The sweet deals on the DC servos are out there. And you can only do it with
EMC2!
Entry first conceived on 4 December 2006, 2:39 UTC, last modified on 10 June 2014, 23:55 UTC
Website Copyright © 2004-2024 Jeff Epler