One quick fix, I think, to what you’ve described is to start clearing with the smallest (usually centermost) polygon regardless of whether that’s the closest next poly to clear. The current strategy incorrectly optimizes for overall path length and fewest moves.
Disabling “depth first” eliminates the code that has had potential crashes in the past.
Um. Actually, starting with small/center first is a (lesser) problem that I propose is a bug, and suggest the climb-right/conv-left scheme as a “quick” fix. Making some assumptions along the way.
I’ve been beating on depth-first roughing for a few days. Today I’ve thought myself into thinking of solving depth-first by way of first improving non-depth-first roughing.
Below there is a feature request for non-depth-first roughing and a couple of idea for the depth-first algorithm.
I’m struggling with vocabulary. So I’ll use:
Please let me know what you call these things.
Here’s a non-depth-first layer:
In the center there are two groups and a single loop. Around the outside are six round nests each including a linked group of two and a single loop. Between those are six trapezoid-ish (trapezoidoidal?) nests of two loops, one of which is linked.
Here’s the same with moves:
The resulting tool path
That a lot of extra moves, each of which either adds two slow Z moves or plows through the layer at G1 speed. (or crashes trying to G0 without lifting but that’s a bug vs non-optimal function)
S.l.o.w. Hence my interest in depth-first.
Here’s the same slicing again, previewing the beginning of a depth-first path:
While it got ahead of itself with the outer roundy bits, within this layer it’s done some things right:
In my experience so far, the depth-first code always gets those things right within each layer.
What remains ambiguous is the direction of the stepover moves - which manifests as groups running inward or outward. Because the code already has cw/ccw right, and knows climb/conventional preference, I think it looks like stepover direction can be determined directly:
(More succinctly: climb=step right; conv.=step left. But I don’t assume that right and left are easily determined in the code)
So…
…how about doing just that much “depth-first” path sorting within each layer of non-depth-first roughing?
That would hugely improve non-depth-first roughing!
Better non-depth-first roughing would take pressure off the depth-first problem.
And today I started thinking that would also simplify solving depth-first.
It looks like the depth-first code already links up these linked groups within each layer and keeps them together, so I assume they are somehow identified as units in the code.
For each such unit, the perimeter(s) of cut area can be determined by a tool radius offset outward from the outermost loop - and inward from the inside loop if it’s not a terminal inner loop. (orthogonal to the large offset/inside corner problem).
Testing for overlap of whole areas should avoid precision problems, no? (assuming your polygon library does that) If potential overlap at edges of two areas is ambiguous within small uncertainty, then it’s probably harmless. Alternative to that assumption, two areas could be determined: one slightly oversize for comparing required area upward and one slightly undersize for comparing safe area downward. Optimistically, the extra polys won’t hurt because there will be fewer “units” than loops.
It seems like that could simplify sorting groups into a depth-first toolpath.
Also a safe/conservative half-way depth-first proposal:
I think that would safely snag some low-hanging fruit for constructing a depth-seeking tool path.
The example figure, by the way, is a 3Dified interpretation of the logo of the amazing “hackerspace” Pumping Station: One in Chicago that I made up (the figure) as a demo for this somewhat silly project. (in a nutshell) That spawned a follow-on project which is exceeding my expectations apart from documentation. Maybe I’ll post those under Showcase.
Ah. Found the depth-firsting code. That should cut down on the speculating.
Something is obviously flawed in the non-depth-first code. Probably broke a while back and I never noticed. Should be easy to find and fix.
Related, in the FDM code I just patched up what’s called “thin-wall” detection. The same helper code I wrote to make that work will also detect CNC uncut regions from tool offsets > 50%.
found and fixed. pushed to the dev branch.
Got it. Will have a look.
…meanwhile…
This looks suspect:
It appears to return true if both polygons wind clockwise.
/**
* @returns {boolean} true if both polygons wind the same way
*/
PRO.sameWindings = function(poly) {
return this.isClockwise() === poly.isClockwise();
};
returns true if the windings of both polygons match, as designed
Oh yeah - that’s a big step in the right direction.
…in fact that is, in CAMotics, <1% slower than depth-first. Win.
Will pick nits later.
You get a super like for your very well formatted and organized post:
Of course. I should have gone to bed.
Golly. Glad you liked it.
@pmc can you check out today’s 2.3.D1 release and see if it handles roughing sequencing better? The path algorithm as well as the collision detection were both totally rewritten.
Over here:
(20 chars)
