I was fooling around with CC and stumbled upon this, after forming the union of two circles and generating a v-carve toolpath (also happens for advanced v-carve):
The single circle is cut with a single plunge as expected but the joined circles result in a crazy imprecise path. I would’ve expected a straight line from center to center.
I saw this behaviour before, mostly at round/circular contour parts and I wonder if this can be somehow prevented? In most cases the final result still looks good. But this kind of pathing really increases the cutting time.
Is there some information available on how the path is generated in CC under the hood, like morphological skeletonization or whatever technique?
My understanding is the fix is what is done in programs which don’t have this problem: Use curve geometry, and define movements in terms of G2/G3 arcs approximating the curves, see Vectric Vcarve’s implementation for example.
While that is a good idea, it doesn’t seem to help as much as one would want in practice (might w/ Advanced V carving?) and usually isn’t helpful for desired cutting geometry, moreover CC still has to render to polylines to make toolpaths.
Doing the vector work in a 3rd party application may help (conversion to polyline is better than that from Boolean in CC), or may hinder (there may be a limit on how many lines are used in the polyline conversion which a series of Boolean operations will bypass).
it’s a complicated issue; the technical “solution” likely (based on having to fight this in software I’ve been playing with) is to 1) make CC not create these “lines” if the angle is, say, 175 degrees or more, and then 2) make the poly lines fine enough that for circles, all poly line segments are at > 175 degree angles
@DAH, yes that’s true, but it was only meant as a simple example. The issue also appears on more complex geometry.
@WillAdams Are G2/G3 arcs not also made up from linear segments?
I know it’s kind of futile to discuss, because we won’t solve the problem just like so, but I’m curious .
Does CC use something like a Straight Skeleton? In that case, one could optimize out references to some contour vertices based on a heuristic like @fenrus suggests. You would trade precision for shorter toolpaths then.
My understand is that (in addition to compactness) arcs give the gcode interpreter the ability to use very small line segments. These could be as small as a single step, as close to a perfect circle as the hardware’s capable of.
That was an interesting read (I skipped the math, though) and seems to be a good starting point to find more recent papers, thanks!
However, as far as I understand this one is more about finding a parametric path representation that is derivable and thus allows for better local discrete approximation. They do mention that this presented representation is better to find the offset path that a tool has to follow in order to cut an input path.
But, I don’t quite see how this helps in the generation of centerline paths (as in v-carve). Maybe I can find something, following citing articles (Maybe this one about trimming offset curves).
Guess your point is that if you have a CAD software that works on the basis of parameterized curves, it can use algorithms that find clean centerlines. Whereas CC works on polylines, introducing the above issue.
.