Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slicing failed while using tree supports in 5.4.0 #16414

Closed
TCotant opened this issue Aug 7, 2023 · 9 comments
Closed

Slicing failed while using tree supports in 5.4.0 #16414

TCotant opened this issue Aug 7, 2023 · 9 comments
Labels
Slicing Error 💥 A crash is caused by a model or a user interaction. This needs a differnt troubleshooting approach Status: Duplicate Duplicate of another issue. Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. Type: Bug The code does not produce the intended behavior.

Comments

@TCotant
Copy link

TCotant commented Aug 7, 2023

Cura Version

5.4.0

Operating System

Windows 10

Printer

SV01 #3 (Klipper)

Name abnormal settings

Tree support

Describe model location

Yes

Describe your model

These models are watertight and slice with Normal supports

Add your .zip here ⬇️

Disks Slicing Failed with Tree Support.zip

@TCotant TCotant added Slicing Error 💥 A crash is caused by a model or a user interaction. This needs a differnt troubleshooting approach Status: Triage This ticket requires input from someone of the Cura team Type: Bug The code does not produce the intended behavior. labels Aug 7, 2023
@GregValiant GregValiant added Status: Duplicate Duplicate of another issue. Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. and removed Status: Triage This ticket requires input from someone of the Cura team labels Aug 7, 2023
@GregValiant
Copy link
Collaborator

Thanks for the report and the file.
This sliced for me right out of the box. I'll mark this as a duplicate report and the Cura team will take a look.
In the meantime try moving or rotating the models and sometimes changing the Initial Layer Height by just a little can fool this bug.

I know it wouldn't slice for you and you haven't had a chance to tweak the supports yet but I noticed this in the preview. There are unsupported areas. Your "Minimum Support Area" and "Minimum Support-Interface Area" are set too high.
I know Silky PLA doesn't have good layer adhesion but printing at 230°??
image

@TCotant
Copy link
Author

TCotant commented Aug 7, 2023

Greg,

Thanks for the reply. I have had some issues with standard supports - maybe this has something to do with it. But, I haven't used the Minimum Support Area / Minimum Support Interface Area parameters yet. (Just when you think you know Cura!)

From what I see, Minimum Support Area = 0 and Minimum Support Interface Area = 10. You're saying it's too high - do you have a link to some good documents to understand this better?

As for the silk, I'm using Sovol's tri-color silk and it actually has pretty decent adhesion. But I was also having some clogs and they recommended moving it up to 230. FYI, this is a "Klipper-ized" Sovol SV01 printer, with an SKR 1.4 Turbo board, BLTouch and E3D V6 hot end.

As you can see in the photos, the main surface quality is decent (zoomed in photos make it look worse I think), but the edges and the back where the supports connect are pretty ragged. The problem is that I can't sand silk... As a rule of thumb, I'm using z gap to 2x the layer height (unless that surpasses .5mm) and I generally have an easy way of removing supports. (This time, too.) But the quality here on the back is bad - maybe like you said because it should have been supported better. I'm curious to what you'd suggest.

One other thing that bothers me is that I have the z seam position set to Back / Smart Hiding. I do notice it doesn't often actually do that. Maybe there's something else to tune here.

Thanks again for the help.
Image (3)
Image (2)
Image (4)

@TCotant
Copy link
Author

TCotant commented Aug 7, 2023

Also @GregValiant - I have tried several changes to the Minimum Support Area / Minimum Support Interface Area (per the suggestions on the Ultimaker site, and even taking it further) and that same spot that you have highlighted will not provide supports. I've tried changing the Tree support values (max branch angle, X/Y and Z distance, etc.) and nothing seems to send supports where they are needed. Thoughts?

@GregValiant
Copy link
Collaborator

There might be some information available in Cura Wiki. There is a link up above.
If you take a rectangle that needs support and it is 100mm² and your Minimum Support Area is 200mm² then your overhang will not be supported. If the Minimum Support Area were to be 90mm² then Cura would generate support.
In this case you have a first layer over support that is about 3 x 0.2 x 0.4 or 0.24mm² when it starts out. It is a very fine feature.

This is the best I could do, but at least its something.
image

You haven't mentioned why you are printing them up at an angle like that.

@TCotant
Copy link
Author

TCotant commented Aug 8, 2023

@GregValiant The reason at this angle is to allow a more smooth feature on the "dish" (outward face). If it was facing directly up (+Z) even at .1 layer height it would be pretty jagged and likely not print very well. Also, supporting the bottom in a face-up situation proved to be very clog heavy for the silk, despite trying to tune the retractions.

I'm coming from a world where I'm used to making movie props and such that are 100% sanded and painted. This time, I can't do that, because I'm trying to demonstrate this silk / tri-color silk filament for this company.

I'm not worried if you tell me that I'm printing too fast for this quality (although I would hope I don't have to do that on a Klipper printer). Whatever I need to do in order to get better quality, I'm open for.

Thanks for the new screen shot - I'll check it out. (Oh, any special sauce in the post-processing script you're running?)

@GregValiant
Copy link
Collaborator

I play with post-processors all the time so the one listed is one of my own - "Advanced Cooling Fan Control". By their nature post-processors don't have any effect on the slice, just on the final gcode.

I print Silkies 5° hotter than any other PLA and at 50mm/sec with 35 for the outer walls. At the lower speeds the silkies look terrific (silky silver almost looks like chrome) and since I'm not in any rush, going slow doesn't bother me.

In regards to print speed...I strive not to let personal preferences get in the way of my objectivity here. Everyone who posts here is having a problem and I have no idea of their skill level or the combination of hardware and firmware they might have. One poster might be a 12 year old who has no experience at all and the next is a robotics engineer who has been dealing with gcode for 30 years.

@TCotant
Copy link
Author

TCotant commented Aug 8, 2023

Yeah, I've always said that after the print finishes, nobody cares what speed you printed it at. :)

I was told by the vendor that due to my E3D V6 and steel nozzles, to bring it up to 230 to avoid the clogging. I was just chatting with a friend that said closer to 215 should be the max. I'm going to run a few simple tests. Currently trying to tune the Outer Wall Wipe Distance to hide the Z a bit more.

I hear you, regarding not knowing the level of experience on the other side. I'm sure you get some interesting ones.

@GregValiant
Copy link
Collaborator

Nobody likes buggy software and that includes me, you, the developers, the contributors, Bill Gates...whoever. When the software is complicated it can be tough to chase the bugs down. I spend a lot of time debugging my own stuff and it is really exasperating when something comes up that I hadn't anticipated, or maybe a typo that I missed the first 189 times I went through the code.

BTW, 215° is what I print silkies at as well. The layer adhesion is much better but still not up to what other colors are capable of. If they pick up some moisture the durability of the prints definitely suffers.

@TCotant
Copy link
Author

TCotant commented Aug 18, 2023

Thanks for the help on this. The original issue has a decent workaround. I'll close the record.

@TCotant TCotant closed this as completed Aug 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Slicing Error 💥 A crash is caused by a model or a user interaction. This needs a differnt troubleshooting approach Status: Duplicate Duplicate of another issue. Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. Type: Bug The code does not produce the intended behavior.
Projects
None yet
Development

No branches or pull requests

2 participants