The math algorithm behind cutter compensation G codes

[Dave Erce]

As I code my homebrew CNC software in C++, for some reason I have had a long
standing mental block on how to code the cutter compensation moves. Do I
have to look forward and handle the current and next G code move statements
as a pair to get the proper offsets?

Anyone figure this out and willing to share?

[Matt Timmermans]

Post by Dave Erce
As I code my homebrew CNC software in C++, for some reason I have had a
long standing mental block on how to code the cutter compensation moves.
Do I have to look forward and handle the current and next G code move
statements as a pair to get the proper offsets?

You can calculate the paths one move at a time, except:

- on a sharp corner away from the cutter, you have to move the cutter in a
circular arc to get it in position for the next segment.

- you have to decide what to do about sharp (even sharp and shallow) corners
toward the cutter, and arcs tighter than the cutter diameter. It's OK to
disallow blatant offences, but you should tolerate the sorts of things that
might be introduced by rounding errors in the tool path generating software.

--
Matt

[Robin S.]

I *think* some controls will prevent a toolpaths that resemble pockets with
openings to outside walls where the opening is smaller than the tool being
used (causing a gouge when the tool exits the pocket through the opening).
This could be thousands of blocks ahead...

Regards,

Robin

[footy]

If you are doing cutter compensation, you are going to have to take into
account the next move. This applies whether you are doing linear or
circular interpolation. And it applies whether you just do straight
moves or roll the cutter around corners to keep the tool in contact with
the corner. For example, assume you are cutting around the outside of a
polygon. Assuming you don't need to keep the cutter in contact with the
corner, you need to figure out how much farther than the end of the
current line you need to move before starting the move in the next
direction. For a square, this is easy. You just need to move past the
end of the current line by 1/2 cutter diameter before starting the next
move at 90 degrees to the current one. If you need to keep the cutter
in contact with the corner, then you need to figure out the arc to
follow. For corners that aren't right angles, you have to use
trigonometry to figure out how far to extend the current move before
starting the next one, or how big an arc. You might want to get ahold
of a copy of Computer Numerical Control by Warren S. Seams or something
similar.

[Neat Trick]

On Tue, 09 Aug 2005 22:30:29 -0700, footy <***@foott.com> wrote:

[snip]

Post by footy
starting the next one, or how big an arc. You might want to get ahold
of a copy of Computer Numerical Control by Warren S. Seams or something
similar.

His name is Warren S. Seames and the book is more of an applied CNC book than a
CNC systems engineering book. The OP is looking for algorithms to be applied
inside the CNC system for cutter compensation look-ahead. Most of this kind of
information is considered proprietary to the systems that are commercially
produced and there is not much documentation to be found about how they do it.
You are correct about how look-ahead will be a big part in how cutter
compensation is handled in outside and inside corners and the need for fill-in
blocks to perform arcs around points of tangency etc. I would be very interested
to see how Siemens handles it inside their 840D system.

[Cliff]

Post by Neat Trick
[snip]

Post by footy
starting the next one, or how big an arc. You might want to get ahold
of a copy of Computer Numerical Control by Warren S. Seams or something
similar.

His name is Warren S. Seames and the book is more of an applied CNC book than a
CNC systems engineering book. The OP is looking for algorithms to be applied
inside the CNC system for cutter compensation look-ahead. Most of this kind of
information is considered proprietary

Simple analytic geometry? Done by a simple computer?

Post by Neat Trick
to the systems that are commercially
produced and there is not much documentation to be found about how they do it.

Because it's so trivial.

Post by Neat Trick
You are correct about how look-ahead will be a big part in how cutter
compensation is handled in outside and inside corners

The inside (concave) has no options.
There are probably two ways to handle outside
(convex), depending.

Generally, just follow curves offset from the toolpath or
programmed motion/geometry by the value of the radius
comp.
IF the programmer needs circular interpolation about
a sharp external (convex) corner then a small radius
should be in the geometry. Than it becomes automatic
and NOT something for the control to randomly guess at
(programming intent).

Post by Neat Trick
and the need for fill-in
blocks to perform arcs around points of tangency etc.

See WSP posts.
Chmfers are also programmable by default in some
cases (control parameters).
Often used by 2D MDI programmers ...

Post by Neat Trick
I would be very interested
to see how Siemens handles it inside their 840D system.

Probably as mentioned above <G>.

[PrecisionMachinisT]

Most of this kind of information is considered proprietary to the systems

You might want to just download emc--the source code is in the public
domain, having been developed by NIST.

http://www.linuxcnc.org/

--

SVL

[Neal]

Post by Dave Erce
As I code my homebrew CNC software in C++, for some reason I have had a long
standing mental block on how to code the cutter compensation moves. Do I
have to look forward and handle the current and next G code move statements
as a pair to get the proper offsets?
Anyone figure this out and willing to share?

Dave--
Remember that cutter comp "says" to the control,"place the tool
tangent to the NEXT entity" there for the control must know where it is
and where it is going.

Neal

[Proctologically Violated©®]

I read your Q to a friend who did this in C++. The answer was "yes".
Too bad he don't know cadcam.... :(
----------------------------
Mr. P.V.'d
formerly Droll Troll

Post by Dave Erce
As I code my homebrew CNC software in C++, for some reason I have had a
long standing mental block on how to code the cutter compensation moves.
Do I have to look forward and handle the current and next G code move
statements as a pair to get the proper offsets?
Anyone figure this out and willing to share?

[Dave Erce]

First I would like to thank all who answered my ? in such an extraordinary
fashion! All the answers are right in your posts with special thanks to
Kevin for the .ppt file also.

I started this project just about 20 years ago, and the Bridgeport has been
running in a 2D simple way for about 7 years. At the last compile, there
were 121,000 lines of code that got crunched. Sorry to say this mental
block did not allow me to prescar the code to look ahead.... so a major
rework will be in order.

Again, my thanks to all who contributed to getting me over the hump. I
sincerely appreciate it!

Regards,
Dave

PS: Here's a pix of the mill with the system
Loading Image...

Then I took the technology and applied it to a printed circuit board
fabrication router, much like an LPKF machine:
Loading Image...

And then took the same core software and applied it to a CO2 Laser Engraver
with a 50 watt Synrad laser, but not fully operational at this point in
time:
Loading Image...

[Cliff]

On Wed, 10 Aug 2005 19:28:08 -0400, "Dave Erce"

Post by Dave Erce
I started this project just about 20 years ago, and the Bridgeport has been
running in a 2D simple way for about 7 years. At the last compile, there
were 121,000 lines of code that got crunched. Sorry to say this mental
block did not allow me to prescar the code to look ahead.... so a major
rework will be in order.

That sounds like WAY too much code.
What all does it do?

BTW, Just stuff the entities in machining sequence into
an array (or arrays), check for direction of cut (reverse
entity directions as needed), process the array(s)
(depending, probably only lines & arcs which could have
an integer falag for data type and a "common" format in the
array otherwise) in sequence, finding endpoints
(intersections) as you go & calculating the offset
curves after that.
A bit more complex if non-planar (surfaces) but ....

Now, what are you doing <G>?

[John Scheldroup]

First I would like to thank all who answered my ? in such an extraordinary fashion! All the answers are right in your posts with
special thanks to Kevin for the .ppt file also.
I started this project just about 20 years ago, and the Bridgeport has been running in a 2D simple way for about 7 years. At the
last compile, there were 121,000 lines of code that got crunched.

Object code or lines of code ?

Sorry to say this mental block did not allow me to prescar the code to look ahead.... so a major rework will be in order.
Again, my thanks to all who contributed to getting me over the hump. I sincerely appreciate it!
Regards,
Dave
PS: Here's a pix of the mill with the system http://www.mtggraphics.com/temp/mill.jpg
http://www.mtggraphics.com/temp/pcbdrill.jpg
And then took the same core software and applied it to a CO2 Laser Engraver with a 50 watt Synrad laser, but not fully operational
http://www.mtggraphics.com/temp/laser.jpg

John

[Dave Erce]

Post by John Scheldroup
Object code or lines of code ?

The 100K + lines of code includes all .h files, c++ files, and included
libraries. The PC operates in real time and controls all accel/decel
timings directly. Also all three applications that I described are compiled
into one program, because I couldn't keep the configuration control updated
correctly on three individual programs and after a few years just gave up
and combined them all... ;-(

[John Scheldroup]

Post by John Scheldroup
Object code or lines of code ?

The 100K + lines of code includes all .h files, c++ files, and included libraries. The PC operates in real time and controls all
accel/decel timings directly. Also all three applications that I described are compiled into one program, because I couldn't keep
the configuration control updated correctly on three individual programs and after a few years just gave up and combined them
all... ;-(

Ok, well all I can think of is, do these libraries speed up your work in any way ?

John

[Anthony]

Post by Dave Erce
As I code my homebrew CNC software in C++, for some reason I have had
a long standing mental block on how to code the cutter compensation
moves. Do I have to look forward and handle the current and next G
code move statements as a pair to get the proper offsets?
Anyone figure this out and willing to share?

Almost all CNC machines look ahead *at least* 3 lines during cutter comp
operation. Many, pre-process the entire program ahead of execution.