This issue has come up a few times recently and the culprit has been found. This problem can be identified by mastercam rejecting arcs that are sitting in certain positions. If the arc is rejected at X2.01513 but fine if moved to X2.0151 then you are probably dealing with the following issue and the info below can help. See this illustration: {{:mp:image_1_.png?400|}} Control def setting highlighted below that can control the rejection or not of arcs "off the grid": {{:mp:image_2_.png|}} If "Maximum deviation in calculated arc endpoints from machine grid" tolerance is set to the NC precision tolerance, which is normal, any arc end point in between the grid will be rejected. Here's an example: "Maximum deviation in calculated arc endpoints from machine grid" = 0.0001 (pretty standard setting) NC Precision = 0.0001 (pretty standard setting) If you create an arc at exactly X2.0151, Y1.2152 and the radius is say 0.5, this arc will output fine. There is no "deviation from machine grid" as the start and end of this arc all lie in the machine grid. Basically the machine grid is the resolution of the machine, so in this case, the arc points have to be accurate to the 4th decimal place, or they are "off the machine grid" and mastercam will linearize the arc in the NC code. If you create a 2nd arc, same radius 0.5, but it's positioned at X2.01513, Y1.21522 this is shifted off the grid by X0.00003 and Y0.00002. So there is now deviation from the max resolution of the machine. This can't be cut accurately as the machine does not have enough resolution, so mastercam linearizes the arc and does not warn the user in any way. The backplot still shows the arc, but the NC code has point to point. To me "Maximum deviation in calculated arc endpoints from machine grid" = 0.0001 implies that the arc must be off the grid by more than 0.0001 to be rejected. However the tolerance does not seem to work this way. It seems to reject any arcs that don't land exactly on the 0.0001 resolution, so any points "off the grid" by 0.00001 or more it will reject and linearize. If a client wants these arcs to be allowed, even though they might cut slightly off the intended path, "Maximum deviation in calculated arc endpoints from machine grid" must be increased, to allow for more deviation before breaking the arcs. For the client yesterday, increasing "Maximum deviation in calculated arc endpoints from machine grid" to 0.0005 was enough to allow all arcs to pass successfully. Hopefully this helps in similar future situations