I believe JanneK and thomas-huber are looking for a
PATH "mode" switch, which will generate the
cutter-contact path as output, instead of
cutter-center path as output, for gcode generation.
Conceptually, without having seen source-code, I can visualize that the "edge/contact" path definition might be an essential middle step in the current approach, and therefore I think it should be relatively straightforward to extract, before the core logic moves on to the generating, thru transformation in direction of contact normals and tool radius, the final tool-centered path we now get for the current style of PATH output.
Such an "edge/contact" path would imitate the CNC controller's logic where it basically uses part geometry for cutter path and does all the offset internally, based on the code selection for which side is cutting metal (relative to direction) to do actual cutter radius offset. While I have never been a fan of letting machine-tool controls perform the
tool-radius-standoff "
live", if that is what machine-shop owners and machine-tool operators want ... and are prepared to accept the full risk, ... that is for them to decide.
However, ... if the "actual" cutter path is not fully calculated by the CNC as a separate step, and not stored/reviewed before initiating the metal cutting process, then I have to say that the manufacturer is complicit in pushing an approach which, at face value, appears to be time-saving and simpler ... but is, in reality what I call, without hesitation,
a categorically reckless approach which has great implicit, if not frequent, potential for damage to operator/part/cutter/machine ... depending on how extreme the "glitch" could show itself to be, as confirmed by
thomas-huber wrote: ↑Tue May 10, 2022 2:07 pm
Yes I can see why It can be dangerous. eajmarceau explained a issue that I already ran into but did not fully understand to this point. ...(snip)
From a standpoint of risk-avoidance ... in a hi-pot environment ... without mentioning potential legal liabilities if someone gets hurt, or business loss if equipment is damaged, I think it is best to avoid adopting such an approach ... and stick to cutter-center programming approach.
For me, such a post-processor implementation must involve a conscious, documented, mode selection ,
performed manually via interraction at the GUI, so that it can be recorded in the reports (or gcode comment)
who made that option selection along with date and time. (Yes, I am aware of how extreme and over the top that
may sound to others.)