G41 and G42 Input path error

Well, I had issues also with this, and I understand that this is not a error, but I also understand that the "desired" toolpath is a full circle before the retract movement.
If you program a bit more of the circle after the full circle, then you will have the problem solved.
For me, it should not be considered a bug.

Since 1992 I have programmed CNC machines, A programmer should only worry about the path he wants to generate, and not be solving situations that the CNC is working on. Fanuc, Fagor, Siemens, have no problem, since 2008 I am reporting this very big mistake. A CNC should not miss traces of the path one wants to generate with or without G41-G42. Your comment is incorrect, I'm sorry. Thank you !!!!

I spent a little time pouring over some Fanuc manuals, on the subject, and I think I see the difference in how Linuxcnc and Fanuc is handling the initiation of the G41/42 offsets. Linuxcnc is handling any corners created between the lead-in move and the following cut moves, the same as any corners that come after initialization of cutter compensation. So the starting point of the cut is offset by the tool radius from both the tool path and the lead-in move. Fanuc is treating that starting point differently, only applying the offset perpendicular to the cutting vector at the starting point.

The programmers of Linuxcnc were trying to prevent over-cutting when starting at an inside corner, and it does just that. But it is causing an undercut in the situation you are describing. If you programed a cut, starting at an inside corner, the Fanuc control would over-cut the starting move. (As far as I can see they both behave the same at the end of cutter comp and both would over cut there.)

I could not tell you how hard it may be to change this behavior. But I am pretty sure it was the intended behavior by whomever programmed it, so it's technically probably not a bug. The harder trick will be convincing the developers that the behavior should be changed.

The simplest work around is to either always program an over lap greater than your tool radius or make sure your lead-in move is tangential to your cut.
So your above inside circle cut would be something like this.

Thank you very much for reading and writing in this post. I am raising this situation for a long time (years !!). The developers do not think this is a problem, but for example, try to create a postprocessor for any cam system that can solve the entry to the path with G41-G42 in the way that Linuxcnc poses it's impossible !!!! ). Fanuc and others have solved this complexity in a very simple way. For adjustments works with pressure is very important. Keep trying, for me is a big mistake as it should work, Linuxcnc should take as an example other controls like Fanuc, Fagor, etc, thank you very much !!

In order to be able to visualize the erroneous way in which linuxcnc generates an input path, I leave a basic example of parametric programming so that it can be understood how complex and unnecessary it can be to perform auxiliary input motions. My intention is that this conceptual error be corrected by linuxcnc developers.

The image shows the actual programmed path that should be generated by Linuxcnc when using G41, but because they do not have the intelligence to enter a path, it is lost due to the tangency of the tool.

Adding one line of g-code to your program will make it run the way you wished it to. It's only a work-around, but it will get you where you want to go.

Another example a more complex level of parametric programming where I return to show the path loss that linuxcnc generates in the input by the tangency of the tool. With these examples I hope to show you the importance of linuxcnc conceptual error when using G41-G42.

dear Mr. Todd Zuercher. I am showing basic levels of parametric programming. As a programmer I should not have to generate any extra movement to generate a path. Only Linuxcnc requires it, no other cnc requires it, I try to ask developers to correct the way linuxcnc enters a path. thank you very much for writing regards

The exact same line of code I suggested above would work the same with that (if the #100 variable is changed to #110)