Every time I try to go to GitHub and report bugs, I can’t find it. I’ve finally thought to report stuff here, I hope it helps.
If I’m trying to make a part and I need to work near the edge, the scan will go over the edge of the part. When rastering, the laser head follows this Z value if the laser is operating or not. This can lead to situations as (poorly) illustrated below. It is an attempt to show two passes of the laser. The laser is on during the green segments. The laser (focal spot) is traveling in the red areas, though no cutting is done. This leads to many semi-violent Z travels at best. At worst, a part will refuse to run because this sudden dive risks crashing the laser head.
The top image is the current operation, note the purple ellipse designating the motion I am describing.
The lower image shows my proposed solution: Use a “floor” for all the covered travel (this will allow full overscan and hopefully no large code changes), so that the head will not drop below the Z position of the last value it had when it left. If a change needs to happen, you can do it at the turn around point, adopting the Z of the fist laser-on position. Something like:
Z (X for >X(laser-off)) = floor(X(laser-off),scan’s Z(X))
Obviously bumps sticking up at the toolhead would still need dodging, in some cases, but any value less there’s no reason to move saving wear and time.
Ideally, non-focused bumps could be discarded the same way, but this would help a lot.
The other huge improvement from this - in those cases where I have a bowl shape on the slats, the drop from the upper lip of the bowl, past the edge, past the slats to the metal bed surface is too far, and the machine will very frustratingly refuse to cut a nearly flat surface, which this would catch.
One