can't apply crc on G2/3 move where cutter radius is >= 1/2 hole radius

[Daniel Rogge]

Trying to mill a 1" diameter hole with a 1/2" diameter endmill using G42 radius offset compensation:

%
G40 G49 G54 G80 G90
G10 L1 P1 R.25
T1 M6
G43 H1
M3 S750
G0 X0 Y-.25 Z0
G1 Z-.1 F10
G41 X0 Y.5 D1
G3 J-.5
G40 G1 X0 Y0
M5
%

Error message says "Arc move in concave corner cannot be reached by the tool without gouging"

Move is in fact valid (lead in move is greater than the cutter radius, entry and exit moves adhere to crc rules). The error message occurs a couple times in the code, but some digging isolates this particular instance in convert_arc_comp2 defined in interp_convert.cc:

if TOOL_INSIDE_ARC(side, turn) {
// tool is inside the arc
dist_from_center = arc_radius - tool_radius;
toward_nominal = cy + tool_radius;
double l = toward_nominal / dist_from_center;
CHKS((l > 1.0 || l < -1.0), _("Arc move in concave corner cannot be reached by the tool without gouging"));

cy is not current_y as it is elsewhere in the code:
cy = arc_radius * sin(beta - M_PI_2l);


Reading the code didn't get me very far - there's not much of a hint of the original intent of the calculation of beta, why cy differs here in the code than in other places or the rational behind the ratio check (-1 < l < 1). I'm hoping that the developer who wrote convert_arc_comp2 is listening to this list and can cast some light on these calculations.

Thanks!

Daniel Rogge

[Chris Radek]

Post by Daniel Rogge
Trying to mill a 1" diameter hole with a 1/2" diameter endmill using G42
%
G40 G49 G54 G80 G90
G10 L1 P1 R.25
T1 M6
G43 H1
M3 S750
G0 X0 Y-.25 Z0
G1 Z-.1 F10
G41 X0 Y.5 D1
G3 J-.5
G40 G1 X0 Y0
M5
%

At the risk of making a pun, this is a corner case for the entry move.
The CRC code tries to start at the given point, and over the entry
move it applies the full offset, ending inside the concave corner made
by the nominal entry move and the nominal subsequent move. By "inside
the corner" I mean tangent to both.

In the case you present, you don't really have that inside corner at
all - or you just barely do, depending on how you look at it: See my
picture of where the corner might barely be:

[The preview is showing the NOMINAL path because I disabled G41/G40
with block delete so it would load. Otherwise it is your program.]

Loading Image...

Now see what happens if I change your last G3 from J-.5 to J-.51,
enlarging that corner just a bit, so the tool definitely fits.
Reducing the tool diameter a tad would do the same thing. It does now
run, but you don't cut a full circle like you surely want.

[This is showing the compensated path now that it loads]

Loading Image...

If you must do your entry move inside what will eventually be the
hole, I recommend using tangent arc entry like this:

%
G40 G49 G54 G80 G90
G10 L1 P1 R.25
T1 M6
G43 H1
M3 S750
G0 X0 Y-0.1 Z0
G1 Z-.1 F10
G41 G3 J0.3 X0 Y.5 D1
G3 J-.5
G40 G1 X0 Y0
M5
%

Not only will you get your full circle cut, you'll also get much
better finish at the Y+ edge of your hole if you enter tangentially.
Ideally you'd exit with a tangent arc too, so you don't ever rub
against the edge of the hole.

Loading Image...

The docs cover this a bit:

http://linuxcnc.org/docs/html/gcode/tool_compensation.html#_overview

As you can see from the example, even if you're cutting an outside
profile, if you make a concave corner when you enter, you may not get
your full profile cut. A tangent arc entry could be used here too, in
the same way. Or, you could fix it by using a corner like in figure 4.

You might also want to see the hole milling subroutine in
useful-subroutines.ngc, which does CRC entry using a line above the
workpiece (which is probably the most standard practice) and avoids
making any concave corners at all. This makes it awfully foolproof.

It is safest to do your entry move totally away from the work, so
you are fully compensated before you come into contact with the
workpiece. Also, it's best to move fully away from the work before
you turn off compensation. The move immediately after turning off
compensation can be surprising because the tool must get back onto the
nominal path. Imagine you've cut an inside profile and then while
still against the work, turn off CRC and program a Z-only move upward.
The resulting move will slant "outward", so the endpoint is on the
nominal path again, centered above the edge you just cut (which now
has a little gouge in it).

Chris

[Daniel Rogge]

Chris,

Thank you for the detailed response.

Post by Chris Radek
If you must do your entry move inside what will eventually be the
%
G40 G49 G54 G80 G90
G10 L1 P1 R.25
T1 M6
G43 H1
M3 S750
G0 X0 Y-0.1 Z0
G1 Z-.1 F10
G41 G3 J0.3 X0 Y.5 D1
G3 J-.5
G40 G1 X0 Y0
M5
%
Not only will you get your full circle cut, you'll also get much
better finish at the Y+ edge of your hole if you enter tangentially.
Ideally you'd exit with a tangent arc too, so you don't ever rub
against the edge of the hole.

I'm surprised that LCNC will allow crc to be turned on during a G2/G3 entry move. Only G1/G0 are allowed as entry moves on Fanuc-type controls.

Post by Chris Radek
You might also want to see the hole milling subroutine in
useful-subroutines.ngc, which does CRC entry using a line above the
workpiece (which is probably the most standard practice) and avoids
making any concave corners at all. This makes it awfully foolproof.

I should have been more clear - this 1" hole is hypothetical. I'm more interested in the bug than in making a hole.

I doubt it's worth an extra check for this particular corner case, but the error message is misleading in this particular case. If you don't mind, I'll submit this as a (lowest priority) bug on the SF tracker, just so that I can remember it exists should I ever have the time to fix it.

Rogge

[Chris Radek]

Post by Daniel Rogge
Chris,
Thank you for the detailed response.

Welcome.

Post by Daniel Rogge
I'm surprised that LCNC will allow crc to be turned on during a
G2/G3 entry move. Only G1/G0 are allowed as entry moves on Fanuc-type
controls.

Yes we've had that feature for a very long time, and in the last
several years (since the 2.3 cutter comp rewrite) it's worked right,
too. I think it's really useful.

Post by Daniel Rogge
I should have been more clear - this 1" hole is hypothetical. I'm
more interested in the bug than in making a hole.

OK, I do understand that. The point still holds, though, that tangent
entry or entry at a corner is good practice if you want to get your
whole profile cut.

Post by Daniel Rogge
I doubt it's worth an extra check for this particular corner case,
but the error message is misleading in this particular case. If you
don't mind, I'll submit this as a (lowest priority) bug on the SF
tracker, just so that I can remember it exists should I ever have the
time to fix it.

I am not sure it's a bug. I think it is working as designed. Can you
say exactly what you think the bug is, now that I have explained the
designed behavior? I can see an argument for entry with a move that
makes a concave corner working completely differently: instead of the
end of the compensated entry move being beside the nominal entry move,
be ON the nominal entry move but beside the nominal subsequent move.
But there are a lot of situations to consider; I think that makes some
of them worse. We would need to carefully consider the tradeoffs.

[Daniel Rogge]

Chris,

Post by Chris Radek
I am not sure it's a bug. I think it is working as designed. Can you
say exactly what you think the bug is, now that I have explained the
designed behavior?

What I feel is a bug is:

1. That entry move works on other controls (sure, LCNC doesn't need to be everything to everyone, but I think it's nice when Fanuc programs run on LCNC)
2. The error message gives no indication as to why the code won't run. "Arc move in concave corner" makes no sense to someone who is trying to mill a circle - where's the concave corner? I understand that this corner is the corner made by the nominal entry move and the nominal subsequent move, but only after it was explained to me.

Post by Chris Radek
I can see an argument for entry with a move that
makes a concave corner working completely differently: instead of the
end of the compensated entry move being beside the nominal entry move,
be ON the nominal entry move but beside the nominal subsequent move.
But there are a lot of situations to consider; I think that makes some
of them worse. We would need to carefully consider the tradeoffs.

Agreed on that argument, but it doesn't sound like low-hanging fruit. More like "the guy whose complaining should do the work" kind of fruit.

Rogge

[Daniel Rogge]

More like "the guy whose complaining should do the work" kind of fruit
To be clear - I mean me!


-----Original Message-----
From: Daniel Rogge [mailto:DRogge-+***@public.gmane.org]
Sent: Thursday, November 08, 2012 9:03 AM
To: EMC developers
Subject: Re: [Emc-developers] can't apply crc on G2/3 move where cutter radius is >= 1/2 hole radius

Chris,

Post by Chris Radek
I am not sure it's a bug. I think it is working as designed. Can you
say exactly what you think the bug is, now that I have explained the
designed behavior?

What I feel is a bug is:

1. That entry move works on other controls (sure, LCNC doesn't need to be everything to everyone, but I think it's nice when Fanuc programs run on LCNC)
2. The error message gives no indication as to why the code won't run. "Arc move in concave corner" makes no sense to someone who is trying to mill a circle - where's the concave corner? I understand that this corner is the corner made by the nominal entry move and the nominal subsequent move, but only after it was explained to me.

Post by Chris Radek
I can see an argument for entry with a move that
makes a concave corner working completely differently: instead of the
end of the compensated entry move being beside the nominal entry move,
be ON the nominal entry move but beside the nominal subsequent move.
But there are a lot of situations to consider; I think that makes some
of them worse. We would need to carefully consider the tradeoffs.

Agreed on that argument, but it doesn't sound like low-hanging fruit. More like "the guy whose complaining should do the work" kind of fruit.

Rogge



------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Emc-developers mailing list
Emc-developers-5NWGOfrQmneRv+***@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/emc-developers

[dave]

Post by Daniel Rogge
More like "the guy whose complaining should do the work" kind of fruit
To be clear - I mean me!
-----Original Message-----
Sent: Thursday, November 08, 2012 9:03 AM
To: EMC developers
Subject: Re: [Emc-developers] can't apply crc on G2/3 move where cutter radius is >= 1/2 hole radius
Chris,

Post by Chris Radek
I am not sure it's a bug. I think it is working as designed. Can you
say exactly what you think the bug is, now that I have explained the
designed behavior?

1. That entry move works on other controls (sure, LCNC doesn't need to be everything to everyone, but I think it's nice when Fanuc programs run on LCNC)
2. The error message gives no indication as to why the code won't run. "Arc move in concave corner" makes no sense to someone who is trying to mill a circle - where's the concave corner? I understand that this corner is the corner made by the nominal entry move and the nominal subsequent move, but only after it was explained to me.

Post by Chris Radek
I can see an argument for entry with a move that
makes a concave corner working completely differently: instead of the
end of the compensated entry move being beside the nominal entry move,
be ON the nominal entry move but beside the nominal subsequent move.
But there are a lot of situations to consider; I think that makes some
of them worse. We would need to carefully consider the tradeoffs.

Agreed on that argument, but it doesn't sound like low-hanging fruit. More like "the guy whose complaining should do the work" kind of fruit.
Rogge

Hi,
As usual I take the simplistic approach to circular milling and helix
in. Since I'm not in a hurry I do a spring pass or two at the bottom of
the helix then G1 move off the circumference and retract.
More and one way to skin this cat.

Dave

Post by Daniel Rogge
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Chris Radek]

Post by Daniel Rogge
1. That entry move works on other controls (sure, LCNC doesn't need
to be everything to everyone, but I think it's nice when Fanuc
programs run on LCNC)

Understood. Do you know where the tool ends up after the entry move
on these controls? Is it like the alternative entry implementation I
described, or something else?

Post by Daniel Rogge
2. The error message gives no indication as to why the code won't
run. "Arc move in concave corner" makes no sense to someone who is
trying to mill a circle - where's the concave corner? I understand
that this corner is the corner made by the nominal entry move and the
nominal subsequent move, but only after it was explained to me.

I agree about the error and I would love for someone to figure out how
to make all the errors better. The errors talk about the geometry of
corners, since the code deals in the geometry of corners that are made
by adjacent moves. The code is very much "study corner situation" and
then "move the endpoints around" with a bit of "add extra moves"
thrown in. So errors are detected in these steps. But the user maybe
isn't even thinking of corners and endpoints - the user is thinking of
a part profile.

It's a common mistake programmers make: give errors that represent
what has gone wrong in the code, instead of what's wrong with the
user's request or intent. (But note this may require mind-reading.)

Input is welcome.

Chris

[Daniel Rogge]

Chris,

Post by Chris Radek
Do you know where the tool ends up after the entry move
on these controls? Is it like the alternative entry implementation I
described, or something else?

No - the behavior on a Fanuc control is very similar to the LCNC entry move (tool approaches the circle along a path that's at an angle from the nominal command).

It's not clear to me whether the error check is overly restrictive, or whether the entry move should be tweaked.

Rogge

[Jon Elson]

Post by Daniel Rogge
I'm surprised that LCNC will allow crc to be turned on during a G2/G3
entry move. Only G1/G0 are allowed as entry moves on Fanuc-type controls.

Many modern systems allow an arc move on entry to compensation, and a
lot of users
now use it that way.

Jon