Overhang perimeter not well detected

[ldiegos]

Describe the bug
I have a symmetric design with a section with overhang, but is only detected at one side and in the other side is not detected, so this seems to became an issue when printing because is not properly managed. And seems to squish the layers on that portion.

This is the CAD:

The section that is correct identified the print is so good, but the section that is not correctly identified is weird:

Despite the position of the model in the bed, the print is always wrong with the squished lines where the overhang starts:

Printed in two different, one with dual z(ender3) the other no. (both are printed without any care, just to show the error, the quality of the overall i know, is bad, stupid fast printed)

I design a set of test with different overhangs(with a downgrade version of my CAD program), to see what could be happening, but when i print them, everything is fine, despite one of the overhangs, the one with the angel at 90º, do not show correctly the image.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

>> Project File <<
Please upload a ZIP archive containing the project file used when the problem arise. Please export it just before the problem occur. Even if did nothing and there is no object, export it as it contains your current configuration.

TracertAndCompensatorKit-TM45-Zegote.zip

Expected behavior
I expect to have the same management of the overhang at both sides.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows 10Pro
• Version: 2.3.56.8

Additional context
Add any other context about the problem here.

[gpread]

I have seen the same (or a least very similar) issue but in 2.3.57.0 where overhangs facing the bed which were modelled in the form of a uniform 45 degree chamfer were being inconsistently detected (I didn't print the resulting g-code so can't comment on the resulting squishing aspect).

The chamfer was contiguous on 3 sides of the object but was being detected only in a few of its parts. I re-sliced with same project file in 2.3.57.9 and it looked fine.

[ldiegos]

i know what you say @gpread , in my g-code preview one champfer is correctly manange(the front), but both side champfer not.

But something else happen also with the seam at the same time that the overhang start, because, when i put the seam "aligned" and superslicer choose the corner, that corner also has squished lines:

[gpread]

Well the squishing effects are likely to be somewhat a result of how the printer behaves, start/stop, acceleration/deceleration, retract/unretract are going to increase the likelihood of warping, shrinkage, and under or over extrusion. They may not be at all or only partially due to some error in the slicing.

So I think careful placement of seams when there are overhangs is going to be necessary for high quality prints.

FYI I know that currently (I don't really see it as wrong) Superslicer can/will detect perimeter on first layer as an overhang when XY Compensation of 1st layer is set (to some negative value - to managed so called elephant foot). So I believe you/we should consider that separately from the inconsistent treatment of uniform overhangs.

Superslicer detects overhangs based on the level of overlap between perimeters, so I can see how other settings and factors can trigger overhang treatment for certain external perimeters, where we might not expect it.

What's not clear (nor I therefore think correct) is why only some part(s) of a perimeter segment should be detected as an overhang where they are parallel to the layers below. My best guess is that maybe/somehow there is a precision/rounding effect which is causing that issue.

[ldiegos]

I have created a set of tests, see my update on the first post, and nothing is out of order, so, maybe something else is inside the stl file, some kind of incorrect export from my CAD version. This new tests, were created with the downgraded version.

Some weird things or a mix of all of them.

[ldiegos]

Hi Supermerill,

Despite the colored overhang that is strange to me... i found my issue with the prints.

Some time ago i was testing and checking the circumference surface and playing with the "filtering/resolution" and i ended up using a 0.009 value to have a nice circular surface without the polygon-ish looking.

But this value, with complex STLs files, make my printers to be overcrowd and do this weir things.

I start from scratch with a ender3 profile were i check that this value was 0.002 and the surface and model are perfect right now, but some of my stl with circular surfaces, have the polygon finish... i will try to increase a little bit more this value to have a balance between finish and structure.

So you can close this "bug" when you want.

Sorry for all the boring stuff.
Luis.

[supermerill]

@ldiegos using your project file, it's fixed in 2.3.57.0
@gpread for your issue on 2.3.57.0, do you opened/ use an issue where I can reproduce the problem?

[gpread]

I didn't open an issue on it. I'll see if I can reproduce again and I'll append to this with details if so

[gpread]

Susi 2.3.57.0

Windows 20H2 (19042.1165)
CR-10V3 (Modified)
Marlin 2.0.8.2

1. Load the project file (attached below)
2. Make sure Print Settings->Perimeters & Shell->Overhangs->Threshold for->Bridge Speed and Fan is set to 55%
3. Slice the model, then examine the Feature Type view

4. Look at the Feature Type view for Overhang Perimeters, on the front of the model running along the x-axis, you can see that the slicer detects only part of the length of a uniform overhang as being one.

5. If you go to Print Settings->Perimeters & Shell->Overhangs->Threshold for->Bridge Speed and Fan adjust from 55% to 56% is will reduce the length it detects as an overhang

6. If you go to Print Settings->Perimeters & Shell->Overhangs->Threshold for->Bridge Speed and Fan adjust from 56% to 57% it will stop detecting that overhang entirely

The same model and 55% setting for overhang threshold for Bridge Speed and Fan does not detect that model feature as an overhang in Susi 2.3.56.9

So to me, since there is nothing in the model as far as I can tell to make this overhang non-uniform (its clean/no errors and was not constructed with any object/part in that wall at that location), it would seem SuSi 2.3.57.0 is having some strange precision issue triggered by something else about the model.

[gpread]

Overhang perimeter not well detected_Susi_Issue#1562.zip

[supermerill]

that's due to a over-zealous simplification/precision.
I'll up it a bit.

[ldiegos]

Thank you so much men! But i will update to .57. when the gcode-preview works better than the current 57.0, that update and jump to the window each time you change a parameter.

[supermerill]

jump to the window each time you change a parameter.

?
put 'don't switch' into 'switch to preview when sliced'

[ldiegos]

jump to the window each time you change a parameter.

?
put 'don't switch' into 'switch to preview when sliced'

The problem was detailed over here: #1532

with version 57.0, if you put "don't switch" the g-code preview" never appear.