Re: Climb Milling (again)
Posted by
ballendo@y...
on 2001-06-05 18:57:23 UTC
Ron,List,
Your snipped quote below brings up a good point. Most software
backlash comp is done at the "mathematically correct" point.
I have turned off b/l comp in most pkg's I have used, but I got to
looking HARD at the problem when writing my own code.
I came to the conclusion that one of the problems is that the b/l
comp was being applied at this "mathematical" point, when in fact,
the axis would not ACTUALLY change direction for at least a few more
steps. This often happens in arcs, since the finite set of points
"available" to the system do not often coincide with
the "mathematically correct" set of points for the curve.
This results in the backlash comp INTRODUCING a "bump" since it
applies the correction before the axis changes direction.
NOTE:If the cutter forces are strong enough, when compared to the
forces required to move the table; then the cutting forces WILL "take
advantage" of any backlash available in the machine. However, it is
good to remember that cutting is a dynamic action with many forces
and resistances at work, including mass, stiction, inertia and
momentum. In more than a few cases, these factors will(or can be made
to) work in FAVOR of the desired toolpath, even where backlash is
present on the mill.
Back to my point: One easy way to see this effect is to draw circles
arbitrarily on graph paper, then use the vertices of the graph paper
as "achievable" points in the system, and draw the "best"
approximation of the circle (the one first drawn) that you can.
Not only will this be an eye-opener for many OUTSIDE of the b/l comp
implications, it will show that the mathematically correct point
(where the s/w typically inserts b/l comp) is NOT the same place as
the change of axis direction!
One way to "fix" this is to set a flag (in the s/w code) when a
quadrant boundary is crossed, but NOT to APPLY the b/l comp UNTIL the
dir bit changes... I can state that this DOES do a better job on
arcs; compared to simply adding steps in at the quadrant boundary.
Admittedly, there are still going to be problems with any "loose"
machine. But we need to look at how we can BEST compensate for such
limitations (including using the s/w), rather than just calling the
whole thing "bogus", IMO. And as I mentioned previously, not all
machines controlled by these s/w pkgs. are "milling", and/or working
against(relatively) high cutter loads...
Hope this helps.
Ballendo
Your snipped quote below brings up a good point. Most software
backlash comp is done at the "mathematically correct" point.
I have turned off b/l comp in most pkg's I have used, but I got to
looking HARD at the problem when writing my own code.
I came to the conclusion that one of the problems is that the b/l
comp was being applied at this "mathematical" point, when in fact,
the axis would not ACTUALLY change direction for at least a few more
steps. This often happens in arcs, since the finite set of points
"available" to the system do not often coincide with
the "mathematically correct" set of points for the curve.
This results in the backlash comp INTRODUCING a "bump" since it
applies the correction before the axis changes direction.
NOTE:If the cutter forces are strong enough, when compared to the
forces required to move the table; then the cutting forces WILL "take
advantage" of any backlash available in the machine. However, it is
good to remember that cutting is a dynamic action with many forces
and resistances at work, including mass, stiction, inertia and
momentum. In more than a few cases, these factors will(or can be made
to) work in FAVOR of the desired toolpath, even where backlash is
present on the mill.
Back to my point: One easy way to see this effect is to draw circles
arbitrarily on graph paper, then use the vertices of the graph paper
as "achievable" points in the system, and draw the "best"
approximation of the circle (the one first drawn) that you can.
Not only will this be an eye-opener for many OUTSIDE of the b/l comp
implications, it will show that the mathematically correct point
(where the s/w typically inserts b/l comp) is NOT the same place as
the change of axis direction!
One way to "fix" this is to set a flag (in the s/w code) when a
quadrant boundary is crossed, but NOT to APPLY the b/l comp UNTIL the
dir bit changes... I can state that this DOES do a better job on
arcs; compared to simply adding steps in at the quadrant boundary.
Admittedly, there are still going to be problems with any "loose"
machine. But we need to look at how we can BEST compensate for such
limitations (including using the s/w), rather than just calling the
whole thing "bogus", IMO. And as I mentioned previously, not all
machines controlled by these s/w pkgs. are "milling", and/or working
against(relatively) high cutter loads...
Hope this helps.
Ballendo
>--- In CAD_CAM_EDM_DRO@y..., ron ginger <ronginger@r...> wrote:
>After all the good explanations and horror stories of the results of
>climb miling and backlash let's hear from the guys that think
>software compensation for backlash is a good, or even useable thing!
>Sure, the software can cause the motor to backup to the right
>mathematical spot<snip>
>A great bit of proof why Ive always maintained software compensaton
>for backlash is bogus.
Discussion Thread
ron ginger
2001-06-04 15:35:10 UTC
Re: Climb Milling
ballendo@y...
2001-06-04 17:57:33 UTC
Re: Climb Milling
dougrasmussen@c...
2001-06-04 20:28:45 UTC
Re: Climb Milling
Jon Elson
2001-06-04 21:59:59 UTC
Re: [CAD_CAM_EDM_DRO] Re: Climb Milling
yahoo@a...
2001-06-05 05:32:00 UTC
Re: Climb Milling
Alan Marconett KM6VV
2001-06-05 10:58:00 UTC
Re: [CAD_CAM_EDM_DRO] Re: Climb Milling
Jon Elson
2001-06-05 11:30:52 UTC
Re: [CAD_CAM_EDM_DRO] Re: Climb Milling
Hugh Currin
2001-06-05 12:30:11 UTC
Re: Climb Milling
Rich D.
2001-06-05 12:38:26 UTC
Re: [CAD_CAM_EDM_DRO] Re: Climb Milling
Fred Smith
2001-06-05 15:14:44 UTC
Re: Climb Milling
RC
2001-06-05 15:35:17 UTC
Re: [CAD_CAM_EDM_DRO] Re: Climb Milling
dave engvall
2001-06-05 16:13:45 UTC
Re: [CAD_CAM_EDM_DRO] Re: Climb Milling
dave engvall
2001-06-05 16:16:45 UTC
Re: [CAD_CAM_EDM_DRO] Re: Climb Milling
ballendo@y...
2001-06-05 18:57:23 UTC
Re: Climb Milling (again)
Smoke
2001-06-05 19:22:34 UTC
Re: [CAD_CAM_EDM_DRO] Re: Climb Milling (again)
Sven Peter, TAD S.A.
2001-06-05 19:29:40 UTC
Re: [CAD_CAM_EDM_DRO] Re: Climb Milling
yahoo@a...
2001-06-05 19:46:12 UTC
Re: Climb Milling
Tim Goldstein
2001-06-05 19:50:35 UTC
RE: [CAD_CAM_EDM_DRO] Re: Climb Milling (again)
dougrasmussen@c...
2001-06-05 19:53:22 UTC
Re: Climb Milling (again)
ballendo@y...
2001-06-05 20:10:17 UTC
Re: Climb Milling (again)
ballendo@y...
2001-06-05 20:26:41 UTC
Re: Climb Milling
ballendo@y...
2001-06-05 20:29:03 UTC
Re: Climb Milling (again)
ballendo@y...
2001-06-05 20:33:01 UTC
re:backlash comp was Re: Climb Milling (again)
Chris Stratton
2001-06-06 04:48:36 UTC
Re: [CAD_CAM_EDM_DRO] re:backlash comp was Re: Climb Milling (again)
ballendo@y...
2001-06-06 05:25:57 UTC
Re: Climb Milling
yahoo@a...
2001-06-06 05:32:56 UTC
re:backlash comp was Re: Climb Milling (again)
ballendo@y...
2001-06-06 06:18:16 UTC
re:backlash comp was Re: Climb Milling (again)
Smoke
2001-06-06 12:05:16 UTC
Re: [CAD_CAM_EDM_DRO] Re: Climb Milling (again)
Smoke
2001-06-06 12:05:38 UTC
Re: [CAD_CAM_EDM_DRO] re:backlash comp was Re: Climb Milling (again)