Last night I had the opportunity to test pluto-step, first with an oscilloscope and second running chris's "maxnc 10" mill. Aside from two trivial bugs (one FPGA register was never being written, and "too long" timing values wrap around) everything I tested worked the first time. With some limitations, it works.
With the scope, I first verified the correct functioning of the steplen, stepspace, and dirtime parameters. This is when the two bugs turned up: at first, the 'out' instruction to write the stepspace, dirtime, and step polarity registers to the fpga wasn't there at all, so these parameters had no effect. Second, I discovered that values larger than the hardware could accept were wrapped around rather than being clamped at the largest possible value. (only the first of those two bugs is fixed in CVS as of this moment, but the second can be trivially fixed as well)
Next I jerry-rigged a connection from the first pluto stepgen to chris's maxnc mill. After changing the pluto_inch inifile to use the same values as his existing configuration, the mill (or one axis of it, anyway) moved. All in all it ran OK but the sound was not quite as good as with software stepgen.
In effect, I had discovered some shortcomings of the pluto-step firmware that can't trivially be remedied. Because there are so few distinct speeds that can be commanded (about 1000 speeds with the fastest being 300kHz and the slowest just under 1kHz---max's top speed is so low that only about 1% of this range was actually useful) the commanded speed tends to oscillate between two adjacent values at about the EMC servo rate. At low speeds, this oscillation is between "stopped" and "slowest speed possible", and the steps were somewhat irregularly spaced (each time a "slowest speed possible" is commanded, it moves a fraction of a step, so sometimes the step comes after 2 nonzero commands and sometimes it comes after 1; this is the cause of the irregular sound). The error introduced by the irregular spacing of steps at low feedrates is small in physical terms: only 1.25μm on the maxnc with INPUT_SCALE 6400, and even less with higher SCALEs.
These two behaviors are a direct consequence of the trade-offs I had to make to get the everything to fit on the small pluto-p FPGA. I might be able to incrase the resolution of speed commands by a factor of 2 or 4, but I'm not sure that this will make the effect of irregular speeds imperceptible or not. (emc's software step generator has slight irregularities too, but they are down at the BASE_PERIOD rather than the SERVO_PERIOD -- a lot less noticible to human ears and presumably to machinery) Still, if you require step rates above that which software step generation can deliver, pluto-step is probably going to be fine for you. With bigger INPUT_SCALEs, higher stepping rates in Hz, and microstepping, everything improves right up until you hit the speed limit of 312.5kHz---contrast this to software step generation which is likely to stay below 50kHz no matter what PC you are running emc on.
Another idea that comes to mind is whether it's possible to displace the "ones digit" of the fractional position. For example, different settings might give max speeds of ~300, ~150, ~75, or ~37kHz, allowing a greater fraction of the speed range to be useful on a given machine. This might be easier on chip resources than adding two more bits to a bunch of internal registers and adders. I'll have to give that idea a try as well.
(originally posted on the AXIS blog)
Entry first conceived on 24 July 2007, 11:20 UTC, last modified on 10 June 2014, 23:55 UTC
Website Copyright © 2004-2024 Jeff Epler