Skipped retractions with combing

[Piezoid]

Application Version

5.1.0

Platform

Linux

Printer

Creality Ender 3 V2

Reproduction steps

1. Import model with lot of "cells",
2. Ensure that Retraction Minimum Travel and Maximum Retraction Count won't cause skipped retractions,
3. Enable combing.

Reproduction 3MF project

Actual results

Some retractions are randomly skipped. 3 on this layer: Also, it seems to have missed some combing opportunities?

Expected results

All non combed travel should retract.

Checklist of files to include

• [ ] Log file
• [X] Project file

Additional information & file uploads

Reproduction 3MF project

[smartavionics]

Try setting Max Comb Distance With No Retract to a really small value. With it set to 1mm, this is what I get on my build (Cura 4 based)...

[Piezoid]

Try setting Max Comb Distance With No Retract to a really small value. With it set to 1mm, this is what I get on my build (Cura 4 based)... Thanks. Tried 1 mm, 0.01 mm, and 0.001 mm, it helps some, but still having these:

Beside, this is really not what this settings is supposed to do, it should only affect the combed portion of travels. I don't expect retracted combed travel would to happen after setting it to 0.001 mm, yet they do...

[GregValiant]

Thanks for the report. The model could use some repair. Even after repair I could not get the combing to look right and there were no retractions when there appeared that there should have been. Here is the repair report. Someone from the Cura team will take a look. --> 8 Naked edges (?) --> 2 Planar holes (?) -> Vertex count changed from 1137 to 1162 (+25) -> Triangle count changed from 2482 to 2536 (+54)

[Piezoid]

Thanks for the report. The model could use some repair.

Right. I should really get the habit of using FreeCAD mesher instead of the default export which use OCCT's viewport mesh. here's a better mesh

[smartavionics]

Beside, this is really not what this settings is supposed to do, it should only affect the combed portion of travels. I don't expect retracted combed travel would to happen after setting it to 0.001 mm, yet they do...

Not sure what you're saying there.

BTW, I actually created this setting (back in 2018) and I think it's being used appropriately.

[Piezoid]

Beside, this is really not what this settings is supposed to do, it should only affect the combed portion of travels. I don't expect retracted combed travel would to happen after setting it to 0.001 mm, yet they do...

Not sure what you're saying there.

I read "Max Comb Distance With No Retract" as the maximum length of a unretracted combed travel before switching to a retracted travel. And it being indicated to prevent oozing on top of the print. AFAIK this is also the interpretation in Settings Guide: I would expect a very small value to retract during combed travels over this distance and nothing more. This shouldn't influence the travels segments that cannot be combed and cross walls.

BTW, I actually created this setting (back in 2018) and I think it's being used appropriately.

I know and that is why I'm taking the opportunity to clarify its meaning with you. I'm sorry if that came across as offensive. It's not clear to me whether you are presenting it (in the context of this issue) as a workaround for the combing bug, or as a setting that should be set that way.

I concede that with the fixed mesh, it's now working correctly as a workaround with a max distance < 3.1mm. However I use combing for limiting retractions and improving print time. With this workaround, the print time is longer with combing enabled than with fully retracted travels.

BTW, Mainline cura outputs this: (combing all, Max Comb Distance With No Retract = 3.1 mm, estimated print time: 12min 2s)

It appears that mainline cura crosses walls instead of following the combed path, when switching a combed travel to a retracted one. Which is fine with me when I use "Max Comb Distance With No Retract" for its intended use of limiting misplaced material.

No combing: 11min 30s

[smartavionics]

With combing all, max comb dist... = 3.1, I get all combed travels over the walls. That's great but the print time is 41 mins! so not so good. BTW your images in your last response appear to use a different model then what's in the project file.

[Piezoid]

With combing all, max comb dist... = 3.1, I get all combed travels over the walls. That's great but the print time is 41 mins! so not so good. BTW your images in your last response appear to use a different model then what's in the project file.

It is the fixed mesh that I sent few message above. I send a project file based on standard profile for minimal reproduction. Mine use completely different velocity and accels settings.

[GregValiant]

I sliced the original model that I had repaired. Counting the occurrences of ";MESH:NONMESH" in the file I came up with only 14 combing moves. There are 317 retractions though. So there is about 1 combing move per layer and about 21 retractions per layer. Using my own settings profile I still only got 14 combing moves but 618 retractions. I would have thought the difference was "Max Combing distance with No Retract" which I had set to 3.0 but that doesn't appear to be true.

Finally, I scaled the model to 400%. Everything looks good at that scale. Once the model becomes more than just "Outer-Walls" it seems to work fine.

[Piezoid]

Thank you for investigating this.

I did a bit of debugging on the combing code a bit, and found that the problems might be caused by very thin combing boundaries. During the path generation PolygonUtils::getBoundaryPointWithOffset returns a point outside the boundaries.

aka, these asserts fail.

```diff diff --git a/src/pathPlanning/LinePolygonsCrossings.cpp b/src/pathPlanning/LinePolygonsCrossings.cpp index 4d5ef8d5d..3f9e20b4c 100644 --- a/src/pathPlanning/LinePolygonsCrossings.cpp +++ b/src/pathPlanning/LinePolygonsCrossings.cpp @@ -155,6 +155,7 @@ void LinePolygonsCrossings::generateBasicCombingPath(const Crossing& min, const ; point_idx = (point_idx < poly.size() - 1) ? (point_idx + 1) : (0)) { const Point p = PolygonUtils::getBoundaryPointWithOffset(poly, point_idx, dist_to_move_boundary_point_outside); + assert(poly.inside(p, true)); fwd_points.push_back(p); fwd_len += vSize(p - prev); prev = p; @@ -178,6 +179,7 @@ void LinePolygonsCrossings::generateBasicCombingPath(const Crossing& min, const ; point_idx = (point_idx > 0) ? (point_idx - 1) : (poly.size() - 1)) { const Point p = PolygonUtils::getBoundaryPointWithOffset(poly, point_idx, dist_to_move_boundary_point_outside); + assert(poly.inside(p, true)); rev_points.push_back(p); rev_len += vSize(p - prev); prev = p; @@ -196,6 +198,7 @@ void LinePolygonsCrossings::generateBasicCombingPath(const Crossing& min, const // use the points from the shortest path for (auto& p : (fwd_len < rev_len) ? fwd_points : rev_points) { + assert(poly.inside(p, true)); combPath.push_back(p); } combPath.push_back(last); ```

I tried applying a closing operation on the result of computeCombBoundary but this doesn't seem to help. So either these are not the same polygons or there is an issue with the computation of the outward normal that could originate from wrong winding direction. Time to output some SVGs :frowning_face: