Add print speed setting for overhang #328
Comments
|
+1 But yeah, I was just having this discussion with someone a couple weeks ago, when they were printing this: The Ultimaker does the overhangs just fine, but really needs to be slowed down for them not to curl. |
|
I would also like to see this, at the moment I have to manually adjust the print speed in areas where there are overhangs or they curl, (presumably too hot still, not enough contact to pull the heat away/physically not enough contact to hold the extrusion in place while it cools?) either way, this would be a good feature. |
|
This may also be improved by increasing flow rate by x for the overhang, so that it isn't being stretched. I don't think it is that it is too hot, as I can print double-walled hollow objects faster with no issue than I can overhangs with fill. |
|
I'd also like to see this. Detection of overhangs would be very useful, so that actions can be done to:
Anything else? |
|
Very good idea. On Tue, Dec 18, 2012 at 5:21 AM, kefir- notifications@github.com wrote:
|
|
I've solved curling issues by starting the fan near overhanging areas. // basically +1 to this feature |
|
Did you manually edit the gcode, or did you find another way to do this? |
|
Oh, you don't want to know this... manually starting and stopping the fan just in right time. |
|
I can see how it helps having the fan on after the first layer. Why do you On 20 December 2012 07:25, Vasily Stepanov notifications@github.com wrote:
|
|
Well, default slic3r behavior is to use the fan not always, but from time to time. I still do not understand the physics, laying under fan cooling. How the fan helps with curling issues? I GUESS there must be some disadvantages of using the fan, like interlayer strength issues. So that is why I prefer to use the fan only where it is really needed, definitely not in the infilling stage. Am I wrong? |
|
I don't know, that is why I asked. I have only ever done it from the second The problem with turning it on and off is I think Marlin doesn't On 20 December 2012 09:23, Vasily Stepanov notifications@github.com wrote:
|
|
Hmm, slic3r is able to turn the fan on and off during the print (when printing layers with small areas, for instance). So it is possible somehow. |
|
I haven't tried it myself, but there is an issue raised here: On 20 December 2012 11:16, Vasily Stepanov notifications@github.com wrote:
|
|
+1 |
|
look like adding M400 before the M106/M107 command solves the pb of synchronisation anybody get an idea to add a post processing plugin to do that ? more generaly is there a "writing a post processing for the dummy slic3r's users" somewhere ? I would like to implemente the wood layer from cura thank you |
|
+1 |
|
This issue would lead to much nice circular holes in parts, where the top-layer overhangs start to exceed the extrusion width. Because of the lack of a setting for overhang speed and fan, I have to drill out many holes that see droop. Of all the things Slic3r can do to improve part quality, this seems like the #1 thing. |
|
So. I'm almost done with #657, which applies bridge speed (and flow) to the bridging perimeters. My question is: is it okay to use the configured bridge speed for overhangs instead of introducing yet another setting for overhang speed? It looks like a low value, like 30mm/s, would work for both. Also note that applying the full flow (as in bridges) tends to curl overhangs much less. And we're even going to enable fan for overhangs. I'd really like to have a single speed option for both bridges and overhangs. |
|
Bridges and overhangs are quite different. With a bridge, the extruder can race across the gap, and as long as the sag doesn't occur while it's partway through, you're ok - in fact, going too slow gives the fan a chance to push down on the gap and cause sag, so I keep my bridge speed high. That's not the case for overhangs; with no support, the chance of droop is much higher, so you want to go really slow and ensure that the overhang hardens as it's being extruded. I understand the hesitation to have yet another speed setting, but in this case I think it's justified, because bridges and overhangs are really different beasts. |
|
Hey @alexrj, I realize this is an old thread, however I was wondering, have you implemented the overhang custom settings since? I think currently no other slicer does anything other then supports for overhangs. I would really love to at least apply custom speed/flow rate for those areas in order to minimize pla curling upwards.To be precise, pla curls upwards mostly on overhang sharp corners, (like yoda ears tips or gear teeth). Is there any way to detect such problematic areas and apply custom settings? Thanks! |
|
I don't mean to necro-post (does that even count when it's on Github?) but this feature is much-needed, especially if you're printing PLA at higher temperatures. |
|
almost 2017, this sort of feature is like a basic 101 setting for printing with plastic. i guess i can take a stab at it but it would be faster by someone that knows the codebase. |
|
Well, looks like most of the bits are already there to detect overhangs and the flow is already broken out, but PerimeterGenerator() needs a new constructor to submit an overhang flow to it as well and everywhere the constructor is used probably needs to use the new constructor. Flow.hpp needs a new role for overhang flow if you want to break it out completely, followed by a new config option for it (I have notes in the wiki for adding new config options), as well as some sane default in the .cpp. You can probably crib from bridges to get it set up. Also would need a flow ratio for overhangs (width doesn't make sense if there's nothing beneath it). For speed, you need to set it in Gcode.cpp, function extrude. The current path's flow role is exposed, near as I can tell, as path.first().role (it's an enumeration). You will need to figure out what to do when you have an overhang and a small perimeter at the same time. The small perimeter speed is set around line 411. You can try passing --overhangs on Slic3r invocation to use bridge flows for overhangs for right now just to see if this is really what you want. @clearbucketLabs Congrats, you're "hired". The rest of us here are volunteers in our spare time, so things get done when they get done, and I'd be much more interested in reviewing code from someone else and helping them get up to speed and contributing than just doing everything myself. |
|
You may check the EdgeGrid class in the prusa3d fork and how it is used to
detect overhangs for the seam placement. The EdgeGrid class sorts the
contours into a grid structure and then it enables fast calculation of a
signed distance to the contour, so the speed could then be controlled
proportionally to the overhang distance.
…On Sat, Dec 24, 2016 at 4:49 AM, Joseph Lenox ***@***.***> wrote:
Well, looks like most of the bits are already there to detect overhangs
and the flow is already broken out, but PerimeterGenerator() needs a new
constructor to submit an overhang flow to it as well and everywhere the
constructor is used probably needs to use the new constructor.
Flow.hpp needs a new role for overhang flow if you want to break it out
completely, followed by a new config option for it (I have notes in the
wiki for adding new config options), as well as some sane default in the
.cpp. You can probably crib from bridges to get it set up.
Also would need a flow ratio for overhangs (width doesn't make sense if
there's nothing beneath it).
For speed, you need to set it in Gcode.cpp, function extrude. The current
path's flow role is exposed, near as I can tell, as path.first().role (it's
an enumeration). You will need to figure out what to do when you have an
overhang and a small perimeter at the same time. The small perimeter speed
is set around line 411.
You can try passing --overhangs on Slic3r invocation to use bridge flows
for overhangs for right now just to see if this is really what you want.
@clearbucketLabs <https://github.com/clearbucketLabs> Congrats, you're
"hired". The rest of us here are volunteers in our spare time, so things
get done when they get done, and I'd be much more interested in reviewing
code from someone else and helping them get up to speed and contributing
than just doing everything myself.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#328 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFj5I5F87SsgTVQqUVgVHa_vNy7kezsfks5rLJYugaJpZM4AUf2z>
.
|
|
There's a bit of confusion overhere, and the topic is not well defined. First, I ask people who request this feature to agree on a definition of "overhang" in this context. Right now Slic3r has a feature which detects portions of perimeters where the nozzle is fully outside the lower layer contour. For those portions, bridge flow and bridge speed (as well as fan) are applied. That feature is called Detect bridging perimeters ( If it's not, please tell what's your definition of overhang, and what exactly should happen beyond using a dedicated speed. Some of you are talking about flow, but beware that some time ago Slic3r used to use the bridge flow also for much smaller overhangs, and the result was horrible. Also note that changes of speed just for some portions of a perimeter result in a pressure lag, so they are not ideal. Let's first define the problem before talking about code... |
|
What I think is desired here is the ability to monkey around with speed
and/or fan settings for areas of the print that were unsupported a few
layers below--basically to be able to hack one's way into a WorksForMe
"solution".
I agree about the problem needing better definition.
|
|
Actually what most of us refer to as overhang is partially unsupported perimeter. For example upside down pyramid is pretty much all overhang. What would be great is to have ability to control speed and flow in those areas only. At the moment, to print overhangs perfectly, we need to slow down the whole print to 20 mm/s. Especially overhang corners are a problem, yoda ears for example. unless you print slow , pla tends to curl up, so at the best youll get ugly perimeters, and worst print will get knocked off. Here's quite a good thread of ultimaker users trying to figure it out And a video illustrating the problem |
|
Pretty much bang on. With pla you can blast the fan at everything and it "can" work but it's mixed results and does not apply to every plastic, especially ABS and a few others. anything that shrinks can benefit. i don't think there could ever be too many settings to tweak when laying plastic. instead of brute force it should be based on feature detection of the model, overhangs, holes, etc.... a bunch of problems can just be solved in slicer (some in FW and HW but..) that makes printing at least slightly more reliable and quicker. solutions to these overhangs/curling are all currently "WorksForMe" solutions like rotating the model, moving it to a different spot on the bed, dropping extrusion temp for the whole print or entire layer, adding support under so it cools and sticks without curling etc.... |
|
It would really be interesting to find out, why the slow down helps:
My impression is, you want to slow down over overhangs because of inadequate cooling fan. I also think, that spending more time ironing the overhangs with the hot end is counter productive as it re-heats the overhangs. But I may be wrong and the hypothesis 1) is correct. Someone to do experiments? |
|
Its not the inadequate cooling, i tried some crazy setups with portable aircon blowing ice cold air onto external fan etc. More cooling does help somewhat, but by brute force- forcing plastic to freeze before it gets pulled. I have a feeling that too much plastic gets deposited due to no flow control in marlin. That plastic is also only partially supported from underneath, so because its got not much to stick to, it sticks to hot end. Going slow, 20 mms or so, means theres consistent flow, so that helps. Also cooling rapidly prevents extra plastic from following the hotend, if it gets frozen fast enough. Now, since we cant predict the flow that well in slicer, and marlin's flow control is screwed up and turned off, it would be great if we could have the slicer detect overhangs, and especially sharp turns on overhangs, and slow down an X distance before. |
|
@bananapunk What do you mean with "no flow control in marlin"? I actually hacked Marlin at Prusa3D, so I know the firmware inside out. Do you mean the "pressure advance"?
Yes, I agree with that. There is a "small perimeter speed" settings, but it only triggers for small perimeters, not small "ears" sticking out of large perimeters. |
|
Thats right, pressure advance. Last time i checked the alghoritm was incomplete and the libraries never actually get called. |
|
I've been messing around with printing spheres lately, and I've discovered that in addition to cooling, slowing down the extruder can make a significant difference in the quality of the overhang. The upside-down pyramid @bananapunk referred to is overhang with a constant angle, whereas the lower hemisphere of a sphere is all overhang ranging from 0 degrees at the bottom to 90 degrees at the equator. In this case, I've found that more cooling and slower speeds are required for the bottom of the sphere than at the equator. As such, my recommendation would be to add the ability to control cooling and speed as a function of the angle of the overhang such that lower angles (essentially bridges) would have max cooling and use very low speeds, higher angles (vertical perimeters) would have min cooling and faster speeds, and the two would be modified linearly as the angle changes. In my current experiment, the bottom of the sphere is clipped, giving it a base to sit on, and I'm using a modifier mesh to slow down the perimeters to 15 mm/s for the bottom portion where the overhangs are the most extreme. That's my solution when printing 6 concurrently, but for printing one, I just configured the cooling parameters such that the minimum layer time as 60 seconds and the minimum speed was 10 mm/s, which yielded almost perfect results. However, I think that my recommendation above would provide a much more efficient way or printing the sphere (or any overhang) as it would allow the speed and cooling to be much more dynamic. This is a view of one of my earlier attempts that did not adjust the speed at the bottom of the sphere. While not a great picture, you can see the roughness of the front section.
This is a view of a set of 6 printing, and the bottoms of the spheres are significantly improved by slowing the perimeters down to 15 mm/s using a modifier mesh,
Here's a view of a completed item. This one was printed by itself, so the perimeters were printed closer to 10 mm/s at the bottom (at 60 seconds per layer).
|
|
+1 ... just slowing down helps significantly. perhaps because there is just plainly less pull force when pulling slower (plastic stretches slowly) or because of extra filament coming out of nozzle due to ooze , compensating for pull. whatever the reason, if slowing down help, why not doing it? |
|
you can set it up for slow down in simple objects like this example, however when printing anything organic, overhangs come in and out all over the place, setting up zones won't help. So the slicer should analyze the model and set the speed or extrusion multiplier accordingly, slowing down before overhang starts, in order to even out the change of pressure. |
|
@bananapunk it's probably feasible to tag overhang using code similar to the support code. |
|
that's right! only the changes have to anticipate overhang, otherwise due to rapid slowdown the flow will be too much. |
|
If someone wants to muck around with the current support detection code they can take a look, but the true solution would need to live in the c++ side of things, so that detection would need to exist in libslic3r. Probably would need to define an ExtrusionRole for overhangs and figure out how to reference part of a polyline (as we don't want to break loops because that would add seams). |
|
I've tripled the speed of my printer by way of many customizations to the hardware and firmware while keeping the quality on par or better. The biggest issue are overhangs where the printer must be slowed down otherwise the curls happen and leads to a distorted result or even a failure. Having to slow down entire layers pretty much negates the speed advantages. If slic3r could detect overhangs of specific angle thresholds then apply a speed to it, that would be amazing. I would then be able to print max speeds for all features without compromising the quality of the print or the overall time spent on the print. |
|
i achieved good results with smaller layer heights on overhangs. just turn the height down to 0.1 on overhangs and you can go faster wihtout support, of course a wider line is better to, we get more overlaps-»less holes the auto layer hight isnt going far enough for that goal, tuning it in the graphical layer ediotor is fun, as long as slic3r is not crashing. changes can not be saved on this unfortunetly |
|
Common guys, 8 years passed, this is a really useful feature please implement it. Condition to detect overhang: It's very different to bridging & should use another set of settings to allow 2 different set of controls for bridging & overhangs for at least these settings:
example of print that requires it to avoid curling where you can see partially overlapped perimeter contours for external or internal perimeters, example has 3 layers where |__| characters set corresponds to single nozzle line:
Or
Also it would be beneficial to have some multiplier depending on the overhand %, e.g. if overhand is 70% (70% is beyond/outside the below perimeter contour) then (if checkbox clicked) use this multiplier % of overhand * CUSTOM_MULTIPLIER_FLOAT * PARAMETER (Fan / Speed etc considering inverting for slow down speed or increasing fan rate etc) |
I'm having trouble with overhangs curling up in my prints and I've noticed that slowing down the print can sometimes reduce this curling. Could you detect overhanging like you do for bridging and offer an additional print speed configuration setting for the times that you are overhanging?
Thanks,
-Chris
The text was updated successfully, but these errors were encountered: