Thanks for checking it out, Gene.
So it seems that you confirm my expectation that G99 should traverse at the lower level. That's what I was looking for.
As I said, that path was created with modified drilling path code.
What your recompute did was rebuilt with the all the crazy stuff that came in a few years back to make G98 code behave like G99.
I'll bet if you examine your output you'll see the G98, G0XY move and the drop to start_depth + setupsheet.safetyOffset , then the g81. After that the G81 retracts to "current_z" which is now start_depth + setupsheet.safetyOffset, then another G0XY to next hole, so G98 ends up looking like G99.
My gcode , before recompute, does a G81 from z=35, so the final retract should be to z=35 for KeepToolDown=false ( and issues G98 ) and retracts to the R value and issues a G99 when KeepToolDown=True, as in this case. The code snip at the top
should traverse just above the surface (at z=3).
I am asking why 3Dview seems to be showing the move at z=35 between holes. This seems to indicate that 3dview is NOT taking into account the G99. While some code is included for G99 in Path WB, it seems it currently unused and maybe 3D view is not coded for it, or is wrongly coded.
I've been trawling the code to find out where paths are rendered in the 3D view but haven't been able to find it
This needs to be tidied up since it will be confusing to users even if the gcode comes out right.