Radius arc differs from start to finish

I need some help.

I'm puzzled as to how and why my CAM system and LCNC have come up with the following issue.

Error:
Near line 226
Radius to end of arc differs from radius to start
start= (X4.7073, Y0.3125)
center= (X4.7073, Y0.625)
end= (X4.9146, Y0.250)
r1 .3125 r2=o.4285 abs_error= 0.116
rel_error=27.0684 %

I don't see the error code text in the code, I must be missing something.

Here's the code in question.

N216G3X-7.8784Y-.1833I-.318J-.424
N217G2Y.1833I-.1216J.1833
N218G1X-7.8618Y.2083
N219G3X-7.2854Y.225I.2764J.4167
N220G2X-7.2104Y.25I.075J-.1
N221G1X4.0854
N222G3X4.2927Y.3125I0J.375
N223G2X4.7073I.2073J-.3125
N224G3X4.9146Y.25J.3125
N225G1X5.7104
N226G2X5.7854Y.225I0J-.125
N227G3X6.3618Y.2083I.3J.4
N228G2Y-.2083I.1382J-.2083
N229G3X5.7854Y-.225I-.2764J-.4167
N230G2X5.7104Y-.25I-.075J.1
N231G1X4.9146
N232G3X4.7073Y-.3125I0J-.375
N233G2X4.2927I-.2073J.3125
N234G3X4.0854Y-.25J-.3125
N235G1X-7.2104
N236G2X-7.2854Y-.225I0J.125

Thanks

For the N224 move:
The start is: (4.7073,0.3125) (e.g., the end of the preceding (N223) move)
The end is: (4.9146, 0.25)
The radius to center is hypot(0, 0.3125) = 0.3125
The center is: (4.7073 + 0, 0.3125 + 0.3125) = 4.7073, 0.6250)
The radius end to center is:
hypot(4.9146 - 4.7073, 0.25 - 0.6250) = hypot(0.2073, -0.375) = 0.4285

So as reported, the N224 move requests a radius for the end that differs from the radius for the start
(assuming G90 absolute distance mode, not evident from paste)

D,

Thanks for the explanation, what this tells me is the use of a "Generic Post" is screwing things up, I'll look into that.

Thanks again.

This issue comes up a lot in industry. I ran into this with an OKUMA and CamWorks some time ago. The control was giving an error, which said that the arc end point specified was outside of the tolerance for the control. It could be changed to accept a larger error, but the fix was to adjust the rounding in the software to post better code. This also came up with a problem where a very minor (.0002) error on an R value, caused a .014 elliptical error instead of a true circle when milling a .3940 spud. Also, you should use I, J, K values instead of R values, as some controls will choose the arc to generate from the available possibilities, and it may not match your desired value. I ran across this tonight on a FANUC control when someone was looking to keep the tool in contact with a sharp outside corner and programmed the move as as such:

G01 G41 Y5.9 D2 F1.4 ( turning on cutter comp in Y negative move, .500 cutter, wear comp of 0 in D register)
G01 X5.4 (move in X positive direction)
G02 X5.65 Y5.9 R.25 ( . 250 arc in .250 X length, 0 Y length with .250R cutter, was supposed to make .250 rad, 90 degrees keeping contact with sharp corner for burr control)
G40 G01 Y4.9 (turning off cutter comp and moving negative Y direction)


This made a nice move to Y5.9, then made a horizontal move to X5.4, where, instead of keeping cutter contact with the corner, it generated a convex hump between X5.4 and X5.65 while still ending at Y5.9, before completing the downward cut of the corner. Luckily this was an outside corner in free space, or it could have gouged the part. This was from someone adjusting a MasterCAM generated program, to change the corner point, and not looking at the code. If it had been an I,J Delta Start To Center code, it would have found the error and alarmed. Sadly, this program has been ran for several years, and none of the operators had watched the cutter and noticed the hump. Also worth noting is the G40 cutter comp off statement that works because they use wear comp, and none was applied, or it would have tapered on the last Y move.

Long explanation, but summary is, adjust your math filters to 5 or 6 decimal digits, .XXXXX or .XXXXXX (inch), use I,J,K curves instead of R values, and whenever possible, use lead in and lead out moves in free space to change cutter comp modes if you are using it. Cam systems often don't show errors like this, as they do not see the cutter comp values that the machine will see. This is why Vericut and other verification software are so critical to multi-axis machines where the software uses a reverse post processor to actually reverse engineer the cut path into a solid for comparison with an STL or other solid model file.

5 Axis,

This is deep for an uneducated hillbilly like myself, I do have a question.

As it pretains to your suggestion " adjust your math filters to 5 or 6 decimal digits, .XXXXX or .XXXXXX (inch), use I,J,K curves instead of R values".
Are the filters you mention in the CAM software? (I assume so).

Thanks for your insight.

BTW, I was surprised to see you're in my neighborhood (globally speaking).

When you go into the settings page in the CAM software, you can change the number of decimal places that it uses. In the post processor, you can set it to 4 places, which is usually what the machines (inch) use, but it helps to have them set tighter in the actual calculations inside the software.

Yes, globally speaking, just a mountain range away. Lots of good people on here from all over the world. Nice to see that Ronald Reagan put something in place that unified the world, at least in the CNC world. But that may be a little deep on the Linux CNC history.

Fred