On Sat, 14 Dec 2013 10:15:36 -0800, John Larkin
<jjla...@highNOTlandTHIStechnologyPART.com> wrote:
>On Sat, 14 Dec 2013 09:54:22 -0800, Jeff Liebermann <
je...@cruzio.com> wrote:
>>I was admiring a Velleman 3D printer.
>><
http://www.frys.com/product/7725148>
>>I mentioned to the owner that it might be improved with anti-backlash
>>gears. I had to explain what they were, what they did, and why they
>>might be useful on the printer. His first thought was that he could
>>perform the same function in software. Sigh. If all you have is a
>>hammer, everything looks like a nail.
>You can do pretty good backlash compensation in software.
Yep.
<
http://en.wikipedia.org/wiki/Backlash(engineering)>
What the low end machines do is measure the backlash (gear slop),
store the value, and then tweak the travel distance by this amount.
That works just fine with most drives, but the worst case is what I
saw on the Velleman 3D printer. It was two spur gears, apparently
made on the 3D printer, with plenty of slop.
<
http://i1.ytimg.com/vi/MNEZLUXctf8/maxresdefault.jpg>
(The one I saw didn't look this good). I did a quick measurement with
calipers and determined that the big gear was slightly elliptical,
which produced different amounts of backlash at different positions of
the gears. Bleh.
A 3D printer is probably the best case machine for using
anti-backlash, spring loaded drive gears. The only load on the gears
is drag as it's not driving a cutter. Instead of compensation, just
eliminate the problem at the source.
My point was not about which solution for the backlash problem was the
correct solution. Rather, that I had to explain the basic principles
behind backlash compensation and some of the tricks used to eliminate
it. The owner of the Velleman machine was solving all his problems
with one tool (software) and making no attempt to become aware of
other possible methods or solutions. It's much like asking a group of
people how to solve a problem. They will invariably use solutions
derived from their experiences and background. It's a rare person
that can support a solution outside of their primary area of
expertise. The overall effect is that we're creating a nation of
specialists, able to do one thing very well, but little else. Of
course, you're not going to be paying a programmer to do machine
design, or a mechanical designer to write control programs.
I'm undecided as to whether this trend toward specialization is a good
thing. I've seen too many good people have their careers disappear
when their specialty became obsolete.
>I've written a few n/c
>compilers, for milling machines and one huge Whitney punch press (it shook the
>ground when it punched steel) and all included a backlash factor. Big machines
>have heavy-duty lead screws or recirculating ball screw things, and conventional
>anti-backlash gears don't work around those kinds of forces. They'd be fine in a
>3D printer where the forces are low.
Yep. I didn't know that Whitney made big punch presses. I have two
Whitney hand punches. Very useful for punching PCB's instead of
drilling.
>What surprised me is that I included a crude macro facility, "pat" for
>"pattern", in the compilers, and the machinists were soon using that to do very
>sophisticated programming structures.
Machinists that are used to scribbling their own G-code probably won't
have much difficulties with adapting macros to do some of the grunt
work. Until fairly recently, the computerization of the low end of
the CNC was a fairly crude affair[1]. A friend owns a local machine
shop. It's not beneath his dignity to edit the code or post processor
code directly. That's because the compilers tend to generate
sub-optimum code. However, the next generation of CNC programmers
probably won't be able (or willing) to hand edit the G-code.
[1] I stock a small collection of 386, 386SX and 486 motherboards to
replace the controllers in some CNC machines. It's not unusual to
find a $15,000 machine being run by what should have been ewaste long
ago.