Support Interface Insecting Part

[BackwardEcho]

Cura Version

5.7.2

Operating System

Windows 10

Printer

Tronxy X5SA-400

Reproduction steps

All I did differently with my settings and model, was orient it face down. Standing or face-up does not duplicate the issue

The bug might not replicate on other models, so it might be my model that is the issue, but wouldn't there be slicing issues with the other orientations?

Actual results

The preview on layer 61 shows the beginning of the support interface being printed in a way that intersects the part being printed.

Expected results

I don't think the interface should intersect the part being printed unless there is a separation in the part, which this should not have.

Add your .zip and screenshots here ⬇️

Telescope Mount-Body.zip

[BackwardEcho]

Tilting the model out of the perfect horizontal orientation does not replicate the bug.

[Asterchades]

That isn't the Interface printing through the model - that's the Supports themselves. The Interface is shown in a darker colour, which you can see further down those holes and indeed on layer 62 as well with a much higher density.

What is curious to me, though, is that these errant Supports appear to be generated according to your regular settings. When you switch back from Trees you can see the same pattern at what looks all the world to be the same density, albeit better behaved in that it doesn't cross through the model.

@ThomasRahm This looks like it might be something for you to take a look at.

NB The model does report errors when analysed via 3D Builder, however allowing it to repair this makes no difference to the slicing error. Weirdly it also makes it take longer to slice.

[ThomasRahm]

This is a duplicate of #18970
As a workaround one can ensure the hole in the support structure gets connected to the outside of the support structure. E.g. by placing a thin support blocker.

[GregValiant]

Setting the "Support Wall Line Count" = 1 seems to work
alternatively
Setting the "Support Interface Wall Line Count" = 0 also seems to work.

It appears that the problem only occurs with 0 support walls and support walls enabled around the interfaces which is the way the project is configured.

The only change here is Support Wall Line Count = 1

[ThomasRahm]

Interesting find, though these changes only help here, as the cause is the filtering out of holes that don't rest on either the outside or the buildplate, even if these holes contain the model .(Which is a bug, I made pull request Ultimaker/CuraEngine#2088 to fix that). Iirc I subtract the support wall area somewhere in the function to filter out problematic holes, which would explain why it here then works with walls enabled

I completely missed that the support wall line count is 0 here. Nice catch!
I should be checking that everything works fine with no walls! I never thought about someone using connected zigzag without walls for tree support. Normally tree support without support walls does not really make any sense.

There could be even the argument made that if there are no walls, there is no need to filter out any holes. The support will rest on the support infill anyway, as having 0 walls and 0 support infill would not result in support anyway.

[GregValiant]

I try to find workarounds so people can get back to printing while a fix is being worked on.
Tree supports can be fine with Support Infill Density = 0, but they don't work well at all with the Wall Line Count = 0.

Something like this may be simpler. Currently the "support_wall_line_count" "minimum_value" line is:
"minimum_value": "0"
changing it to
"minimum_value": "0 if support_structure == 'normal' else 1"
might be a sufficient change if the other considerations aren't in the way. It would eliminate "disappearing supports" that can occur with the Support Infill Density set to 0 and Support Wall Line Count set to 0.

EDIT: The above change worked with this project, but not with #18970 . Sorry. I'll go sit in the corner now.

[BackwardEcho]

That isn't the Interface printing through the model - that's the Supports themselves. The Interface is shown in a darker colour, which you can see further down those holes and indeed on layer 62 as well with a much higher density.

NB The model does report errors when analysed via 3D Builder, however allowing it to repair this makes no difference to the slicing error. Weirdly it also makes it take longer to slice.

Would it actually be just normal-non-tree-supports just leaking through the generation? I know the color difference between supports and the interface portions, but at the time it felt more appropriate to attribute the support shape change to the interface.

What sort of errors? This is my first model using "FreeCAD", normally I use Blender and I even tried to see if there was some disconnect in the model. Maybe there was something else?

This is a duplicate

Apologies, I looked through some pages but obviously not far enough.

I completely missed that the support wall line count is 0 here. Nice catch! I should be checking that everything works fine with no walls! I never thought about someone using connected zigzag without walls for tree support. Normally tree support without support walls does not really make any sense.

I tried using tree support with 1 wall and the zigzag infill I have now prior, but I disliked how much material it used and how difficult it became to remove as I couldn't break the dang things when I needed. So removing the walls and making the infill a little more dense seemed to give me adequate support for my parts.

[ThomasRahm]

Apologies, I looked through some pages but obviously not far enough.

No problem, I just wanted this issue to be linked to the other one.
It is better to have two reports of the same issue than no report at all!

[Asterchades]

Would it actually be just normal-non-tree-supports just leaking through the generation?

It looks to pretty much exactly match the pattern you would see if you were using regular supports instead. As Greg has mentioned it vanishes if you switch from infill to a wall (which is the more typical usage of Trees), which would also remove that pattern from the calculation entirely.

I'm yet to see Cura give a feature the wrong colour. Put it in the wrong place like this, sure, but it's always the right colour - at least with the default Light and Dark themes (I've seen the suggestion that the high contrast themes are inconsistent but not verified it).

What sort of errors? This is my first model using "FreeCAD", normally I use Blender and I even tried to see if there was some disconnect in the model. Maybe there was something else?

3D Builder unfortunately doesn't tell you what problems it finds - just that there are problems. When I try to do a more manual inspection using SketchUp I'm unable to find anything, both by myself and using the SolidInspector² plugin, so I can't even offer any additional insight - though I do need to convert to STL first before I can import to SketchUp, which could easily be masking the issue (there's possibly a native 3MF plugin now, but it seems Trimble has finally closed the last loophole that lets the last free, offline version of SketchUp surpass any of its modern offerings).

It's possible that 3D Builder is just being picky, in so much as perhaps there's a small issue with the layout rather than an issue with the models themselves. This could easily be a fault in 3D Builder just as much as FreeCAD, as I do know there are some minor shortcomings in its format implementations (its VRML implementation, for example, is incomplete - I think it's missing support for quads entirely, but don't quote me on that).

[ThomasRahm]

Would it actually be just normal-non-tree-supports just leaking through the generation?

No. It is just the support infill going through the model, because a hole in a support area was wrongly removed.
The tree support does not generate lines, but areas for which later walls and infill is generated.
Basically if there is a hole in an area of support, the hole will have walls. If said hole does not overlap with another hole (or the outside) on the layer below it results in floating lines (if support density is low). Because of that such problematic holes are removed. It was overlooked that if there is a part of the model inside said hole, removing it causes issues if the support density is > 0%, as then the support infill will be overlapping with the model.

That is also why connecting it to the outside avoids that issue, because then there is no engulfed hole to filter out.

[nallath]

Fixed for 5.8