First, let me say that I am glad to see work going forward on comp. That is what I have had the most problems with. It is useable for me, but only if I manually go into the gcode and add a custom lead-in for each circumstance. Also the comp would often do odd things where arcs came together without a straight section in between. If I added a tiny straight section, one problem (mismatched endpoint vectors) would go away and another (pausing at the tangent) would replace it. I look forward to having the new code to play with!
I just want to weigh in on the cutter vs inside radius debate. As one who has written a fair amount of code with higher level math, I can tell you that a .5" cutter cannot cut a .25" inside radius as far as the computer is concerned if a check is first made using a "<" comparo. i.e. the radius of .500000000000000000000000 is NOT LESS than .25000000000000000000000.
That being said, I don't see why "< -or- =" could not be used in comparing the cutter dia with the smallest inside radius. If there is some program reason that this is not possible, surely adding a 1 at the highest precision to the inside radius or subtracting it from the cutter would not result in any appreciable error. If internally, you are out 16 places (or more), methinks that this amount of error would be imperceptible except by a scanning electron microscope. This 'trick' could easily be done inside or outside of the comp processing, unless I am really missing something. If inside, then a simple switch could turn it on or off so that people machining to a millionth of an inch would not suffer
Seems moot now since I gather from reading the posts that something has been done to resolve this? As a matter of curiosity, I would be interested in what method was chosen.