"Avoid Crossing Perimeters" creates travel moves on top of perimeters, reducing surface quality

[robosteve]

Version

PrusaSlicer 2.3.0-rc2

Operating system type + version

Windows10

3D printer brand / version + firmware version (if known)

Prusa MK3S - 3.9.1

Behavior

The new avoid crossing perimeters algorithm routes travel moves along the perimeter. If the nozzle is slightly leaking, this can drag filament along the perimeter causing stringing along the edge and impacting surface quality.

It would be preferable if the travel moves happened inside the part (maybe on the infill, or at least on one of the inner perimeters?)

The screenshot is just a test part I mocked up real quick to illustrate the issue.

I'd upload the file that I actually printed where this was noticeable, but it's confidential. Let me play around to see if I can reproduce it physically with a non-confidential part. The stringing isn't too bad, and the only reason I noticed is that I had the same issue when I used to use a different slicer and I've been waiting for PrusaSlicer to upgrade the "avoid crossing perimeters" for a while!

Not that you really care about other software, but some very similar issues for additional context: https://forum.simplify3d.com/viewtopic.php?f=23&t=8329 https://forum.simplify3d.com/viewtopic.php?t=6442

[bubnikv]

The travel moves should not be centered along the hole contours. That is a bug.

There is a code derived from elephant foot compensation, that is used to calculate the allowed region for travel moves inside islands, which ensures that two regions connected by a narrow bridge will still be connected after half a perimeter width shrinkage. Maybe the issue is in this particular "elephant foot compensation" like shrinkage algorithm.

út 5. 1. 2021 v 8:27 odesílatel robosteve notifications@github.com napsal:

Version

PrusaSlicer 2.3.0-rc2 Operating system type + version

Windows10 3D printer brand / version + firmware version (if known)

Prusa MK3S - 3.9.1 Behavior

The new avoid crossing perimeters algorithm routes travel moves along the perimeter. If the nozzle is slightly leaking, this can drag filament along the perimeter causing stringing along the edge and impacting surface quality.

It would be preferable if the travel moves happened inside the part (maybe on the infill, or at least on one of the inner perimeters?)

[image: image] https://user-images.githubusercontent.com/37645729/103617159-bd9ef080-4efb-11eb-9b85-e6c79f7486ec.png

The screenshot is just a test part I mocked up real quick to illustrate the issue.

I'd upload the file that I actually printed where this was noticeable, but it's confidential. Let me play around to see if I can reproduce it physically with a non-confidential part. The stringing isn't too bad, and the only reason I noticed is that I had the same issue when I used to use a different slicer and I've been waiting for PrusaSlicer to upgrade the "avoid crossing perimeters" for a while!

Not that you really care about other software, but some very similar issues for additional context: https://forum.simplify3d.com/viewtopic.php?f=23&t=8329 https://forum.simplify3d.com/viewtopic.php?t=6442

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/5689, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI4IIMHBUGMKMPZ6JYTSYK5PDANCNFSM4VUPAJNA .

[bubnikv]

@hejllukas is author of the new path planning code. He notified me, that what you see is the effect of the elephant foot compensation active on the 1st layer only. In reality the 1st layer is squished, thus the travel paths are actually inside the 1st layer.

[robosteve]

@bubnikv Understood and thank you. Yes that makes sense as I had the elephants foot compensation enabled. Let me turn that off and see if I get the same surface quality issues.

[robosteve]

@bubnikv @hejllukas OK, So I did some test prints. It's definitely workable as-is, but it does kind of just push the strings to a new location.

The current implementation does improve the situation, but if the travel moves happened more in-board, (on the infill or an inner perimeter instead of an outer perimiter) it would probably further reduce stringing and really solve the problem that the "avoid crossing perimeters" is trying to solve:

[robosteve]

Files here if you want them: https://www.prusaprinters.org/prints/51109-perimiter-crossing-test

[bubnikv]

We will look into your print, however with Z lift the strings may get stretched in the air the way you see it across a hole even if the print head was not crossing the print head. The string may get stretched from start point to end point in a straight line.

[Siox0911]

Slicer: Prusa Slicer 2.3.0 rc2

That can't be... Elephant foot compensation = on and "Avoid crossing perim" = on. This will result in... files.zip

[BeatSlayer]

From my tests it seems that setting the "max detour length" to zero is disabling the "avoid crossing perimeters" functionality altogether.

I was under the impression that the "zero to disable" label was relative to the max detour length.

[Siox0911]

Approved. If I set the detour length to 0.01mm. It results in "perimeters will cross". And any higher value will "cross the outer perimeter". So the question is: "Why the path planning runs on the outer perimeter?" And not the outer - 1 perimeterWidth?

[dartrax]

So the question is: "Why the path planning runs on the outer perimeter?" And not the outer - 1 perimeterWidth?

From https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.4.0-beta1:

Travel paths planned by the "avoid crossing perimeters" algorithm no more follow the outermost perimeter, but the 2nd outermost perimeter if possible. This should improve the print surface quality and reduce re-heating of overhangs.

This does not work or at least not reliable in 2.4.0 final:

For comparison, SuperSlicer in 2.3.57: