Cura should never start a perimeter on an overhang

Created on 2 Jun 2018 · 59Comments · Source: Ultimaker/Cura

I'm printing the vertical version of this part:

https://www.thingiverse.com/thing:2563185

As you can see, it consists of one horizontal beam, two vertical beams, and 45° diagonal beams forming an X. This X, thus, has overhangs that face each other, when sliced.

No matter how I tell Cura to position the seam, one of the diagonal bits will have the seam placed right on one of its outermost corners (or too close to it). For example, here is "user specified" mode with the target coordinates set to {100,600}, which inexplicably puts the right island's seam on the overhang:

Shortest has the same effect, the right island's seam starts on the overhang:

Sharpest Corner, the right island is fine now, but now the left island has its seam starting on the overhang:

I guess I don't need to show Random mode.

The print moves proceed counter-clockwise from the starting point (at least in Sharpest Corner mode).

The design of this part makes it impossible to rotate it to any orientation that would put all of the seams in desirable positions, because of the facing overhangs created by the X shape. Anyways, you're not allowed to rotate this part to arbitrary angles - it's a skew calibration object, so it must be printed parallel to either X or to Y (depending on which of X/Z or Y/Z is being calibrated).

Basically, Cura should never -- in any seam placement mode -- start a perimeter on an overhanging corner, whether it's the exterior perimeter, or the corresponding interior ones. I realize an interior perimeter is usually 100% supported by the lines under it, but it's still on an overhanging corner. Although there is some plastic there, there's nowhere near enough thickness to ensure a rigid base for each new layer.

In the actual print, as expected, this causes the affected corner to curl, warping the whole diagonal bit after a while. Warp it enough and the nozzle crashes into it, forcing it down. Too much further, and something will crash into it that will knock the part off the plate (like fan ducts). The bit with the seam placed properly is perfect (or as much so as my bot can do right now). There's plenty of cooling, and I'm printing slow with this part (30 mm/s).

It happens whether the part is parallel to X or parallel to Y, just which island gets the bad seam differs. I have dual fans - one in front of the hotend, one in back, with powerful airflow (more than I need during normal prints, in fact). When printed parallel to Y, the points where the seam is positioned wrong (the front island in the lower parts of the model, but BOTH islands in the upper parts) don't curl up as much as printing it X-aligned, probably because one fan or the other is pointed right at the edge in that case, but one has to print this part twice - one for each orientation.

I've had this happen in other models, too, but overhangs usually end up being short enough to not create a severe problem. The part linked above, however, pushes the issue to its limit (at least on my bot).

Application Version

3.3.1

Platform

Debian 9.4

Printer

Prusa i3 clone, but that's not relevant here.

Steps to Reproduce

Load the vertical YACS model from the above link, select any seam placement mode, and slice it.

Actual Results

One or another overhanging corner will get a seam.

Expected results

The seam should be started as far away from any overhanging corners as possible, and with as much printing distance as possible between the corrected start point and the first overhanging corner to be printed.

In the screenshots, the seam should be placed caddy-corner to where it actually is (for the affected bits), placing it on top of what amounts to dozens of layers of underlying plastic (hence a rigid base).

More

Example photo:

p1180036

As you can see, the verticals, and the overhang with the properly-placed seam, all printed just fine. This part failed because the bad seam overhang curled and warped too much, causing the hotend to hit it too hard during a travel move, stalling the motor (I actually tried re-homing and resuming, but it crashed the nozzle a second time a couple layers later, plus re-homing messed up the precise alignment for the part, rendering it useless anyway, so I gave up on that print). And that's with avoid part during travels turned on, with a 1 mm avoid distance. I guess the curling forced the newly-laid plastic to spread out enough to encroach into that avoid distance.

Engine Deferred Improvement

Source

VanessaE

👍4

Most helpful comment

Just letting you folks know that I have separated out the overhang support from the bridging and there will be two new settings, one is the threshold angle which determines if a wall is overhanging or not and the other is a speed factor that allows the overhanging wall to be printed slower if desired. It also moves the wall start points to avoid starting a wall polygon at an overhanging point.

The code is new and will obviously require testing and improving before submitting as PRs. However, I am not submitting the PRs until the log jam of outstanding PRs goes away as there is some dependency on the earlier changes being accepted.

smartavionics on 19 Jun 2018

👍4

All 59 comments

Hi @VanessaE, I think you have a good point. In the bridge handling code, I avoided starting walls over air and I think a similar thing could be done for normal walls. I will look into it.

smartavionics on 2 Jun 2018

Actually, the bridging settings help you here. Set the min bridge wall length to 1, the bridge wall max overhang to 20 and the bridge wall flow to 100. Bingo!

screenshot_2018-06-02_07-23-33

screenshot_2018-06-02_07-23-46

smartavionics on 2 Jun 2018

Interesting workaround. To get this part printed, I set the seam to random (so that at least when a seam gets placed wrong, there won't be many of them stacked up).

Since you brought it up, overhang settings should be distinct from bridging settings (flow, speed, and acceleration especially). I guess it's okay to use a threshold to decide whether to consider something a bridge or an overhang, though.

VanessaE on 2 Jun 2018

Since you brought it up, overhang settings should be distinct from bridging settings (flow, speed, and acceleration especially). I guess it's okay to use a threshold to decide whether to consider something a bridge or an overhang, though.

Ideally, the overhang settings would be separate from the bridging settings but that would make the implementation even more complicated than it already is. At the moment, when printing a wall line, it has to segment the line into those portions that are above air and those that are not and then it does some funky stuff with the extruder flow rate to try and avoid over/underextrusion due to the step change in extruder rate that is required when crossing between bridge/non-bridge.

Adding separate params for the regions of the line that are considered overhang would be nice but how many models have both bridges and overhang?

smartavionics on 2 Jun 2018

Good points, all.

"How many models"? Honestly, a lot of them. In particular, anything containing a non-rectangular horizontal hole (e.g. for a screw/bolt), as the upper half of the hole is of course all overhangs, and the top layer closing the hole is formed by bridging. Anything mechanical and remotely complex is almost guaranteed to have both features, especially with thicker layers (as there'll be a larger step between the last round/overhang layer and the top side bridge).

My most recent important print was a replacement for the trunk pull-down gearbox for my car (https://www.thingiverse.com/thing:2929763 in case you're curious). On first look, you'd almost think it has more overhangs and bridges than it has regular vertical walls. :wink:

VanessaE on 2 Jun 2018

Totally agree here, as a general rule, start extrusion where they are most likely to work. There used to be similar issues with a tower coming from a flat surface - printing its base on gaps in infill.

AbeFM on 2 Jun 2018

Good suggestion indeed, it'll improve print quality for overhangs.

ChrisTerBeke on 3 Jun 2018

Beta 3.4.0 is out (as you surely know); is there any chance that fixes for this seam placement issue (and maybe the part about overhang vs. bridge settings) can make it into 3.4.0-release?

VanessaE on 15 Jun 2018

We almost never add features between a beta and stable release, only the necessary bug fixes.

ChrisTerBeke on 15 Jun 2018

I'd define this as a bug. Starting a seam on an overhang can render something unprintable if the overhang has something else running alongside but separate from it (as in many articulated "print in place" models), as this can cause the bad seam to curl the overhang enough to fuse it with its neighbor.

VanessaE on 18 Jun 2018

It's been there forever, so it's not a pressing bug for us.

ChrisTerBeke on 18 Jun 2018

There are many things in this world that have "been there forever". That doesn't mean they don't need solved.

Maybe it's not pressing to you, but what about to your userbase? If I've run into this, you can be sure others have, too. The usual 100:1 rule applies.

VanessaE on 18 Jun 2018

I'm not here to debate priorities, that's something that the team and Ultimaker decide. If anyone else finds it a priority, they can always contribute. Let's just say that there's a list of other stuff that to work on that we deem more important at the moment.

ChrisTerBeke on 18 Jun 2018

Fair enough, but with all due respect, I've skimmed through the issue list just in the past couple days (just looking for issues that I may have run into), and this is not the first time I've seen this kind of reply, and to be blunt, it reflects badly on the project, the company, and the individual contributors.

VanessaE on 18 Jun 2018

👍3 😕1

I tend to agree with her. The responses to "I can't print this reasonable
thing due to an obvious problem with the approach" I've seen on here often
fail to reflect strong a commitment to improving to software for the user
base.

I understand not all these outsides can be handled right away, but the
responses aren't encouraging.

A suggestion on how to get around the problem without patching the software
would be good. Of the issue were not knowing how to implement the fix, we
could work on it here - I have written a lot of forum pseudo-code over the
years and real programmers have implemented it. I'm sure the fine folks
here can look at it.

This isn't meant to be telling anyone off - when I engage in conversation
here it is to try to help find a solution for the wider community.

              Thanks!
                      -Abe.

Sent from my "smart"phone, please excuse brevity and Swype-oes

AbeFM on 18 Jun 2018

Realistically, in the short term, the only way this is going to get developed is if I put the time in as the UM folks have a different set of priorities to the rest of us. I'm not adverse to doing that but as it's not a burning issue for me I will do it in my own time. As there are already 2 outstanding PRs of mine related to the bridging, I want to get them through the system before I create further mayhem.

smartavionics on 18 Jun 2018

and to be blunt, it reflects badly on the project, the company, and the individual contributors.

Really? Well that sends you to the bottom of my list of people to make happy by contributing my own time for no material reward.

smartavionics on 18 Jun 2018

Thanks for that. We're not aware of the behind the scenes stuff, and it's
hard to differentiate being too busy from not agreeing that an issue is
worthy.

I'd be quite happy to see this "on the list". Thanks again for all the
improvements so far.

              Thanks!
                      -Abe.

Sent from my "smart"phone, please excuse brevity and Swype-oes

On Mon, Jun 18, 2018, 8:22 AM Mark Burton notifications@github.com wrote:

Realistically, in the short term, the only way this is going to get
developed is if I put the time in as the UM folks have a different set of
priorities to the rest of us. I'm not adverse to doing that but as it's not
a burning issue for me I will do it in my own time. As there are already 2
outstanding PRs of mine related to the bridging. I want to get them through
the system before I create further mayhem.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/3875#issuecomment-398092152,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAClkRQMSMwUdhI2juATWLJ6cr6ZZKytks5t98WVgaJpZM4UXjqF
.

AbeFM on 18 Jun 2018

it reflects badly on the project, the company, and the individual contributors

I can also not respond and leave everyone in the dark. Just trying to be clear that it's not a priority for the people that are paid by Ultimaker at the moment. But since Cura is open source, that doesn't mean that it's not a priority for others that contribute to the project.

We shouldn't underestimate both the major open source contributors nor the funds that Ultimaker puts into this. I think it's only fair that both groups decide on their priorities. When those align, that's great. But sometimes they don't and we can still get a lot of work done between all of us.

ChrisTerBeke on 18 Jun 2018

@smartavionics, "contributors" in this context should have clearly meant "UM employees and paid contractors", not (presumably-)unpaid people like you and me. Don't have time? Fine. I get that. Next time, just say it. You do not have to get nasty.

Besides, this is 3d printing... digital model in, plastic out... it doesn't get any more "material reward" than that. :stuck_out_tongue_closed_eyes:

@ChrisTerBeke I don't reject the notion of priorities, but all too often, those priorities just are not well-considered. I see it frequently. Bottom line, unless there are viable workarounds (that don't involve jumping through ridiculous hoops), "broken for everyone" needs to be put above "broken just on our line of printers". "Costs our users money" (for a free-as-in-beer project) needs to be put above all else.

Guys, I am struggling to be polite here, because frankly, these replies piss me off. So I apologize for that air.

VanessaE on 18 Jun 2018

those priorities just are not well-considered

In your opinion I assume? There is no way to determine that objectively. Our priorities are also just opinions, they just happen to be the opinions of the people paying for the development. There's a lot more going on behind the scenes than just 'is it broken?'. We have to deal with a great amount of internal priorities from other departments. Which is perfectly normal because Ultimaker is a for-profit company.

I get that it's not an ideal situation, but on the other hand, without Ultimaker paying for a lot of this development, Cura might not even be here at all, or at least not get a new release very 10 weeks.

Note that I'm currently not in the core team of Cura in terms of daily development, but as someone who worked on it daily for some time, and also did some PRs in my spare time, I feel the need to explain that there's more behind Cura's development priorities than only looking at what is assumed to be broken.

ChrisTerBeke on 18 Jun 2018

Indeed, it's just my opinion. Don't get me wrong, I don't mean to devalue the work done by paid employees.

But, surely there are more than just you two guys involved in this project (paid or not)...

As for "broken", what else can I say about a function that's not working properly, to the point that it fails an entire print?

VanessaE on 18 Jun 2018

function that's not working properly, to the point that it fails an
entire print?

This is getting pretty far afield, but that last bit is why I report stuff.

If it seems like it'll ruin a print and it's fixable, I bring it up.
Sometimes the responses don't make it clear of the issue is credible.

A discussion of the issue is reasonable even if implementing a fix might
not be immediate.

I hope we can all continue to use this approach. Adding tags like
"suggestion" or "bug" can go a long way towards making a poster feel like
their input is not being ignored. If the issue is trivial, then a response
can illustrate.

Perhaps further meta-discussions could happen elsewhere, let's return to
the original topic here!

There's a general problem with individual extrusions beginning in mid air
that this is a case of. How can we fix it?
Thanks!
-Abe.
Sent from my "smart"phone, please excuse brevity and Swype-oes

On Mon, Jun 18, 2018, 2:37 PM Vanessa Dannenberg notifications@github.com
wrote:

Indeed, it's just my opinion. Don't get me wrong, I don't mean to devalue
the work done by paid employees.

But, surely there are more than just you two guys involved in this project
(paid or not)...

As for "broken", what else can I say about a function that's not working
properly, to the point that it fails an entire print?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/3875#issuecomment-398203966,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAClkSOna40JP24BnRnkWU3hJYYhRc71ks5t-B2dgaJpZM4UXjqF
.

AbeFM on 18 Jun 2018

👍3

smartavionics on 19 Jun 2018

👍4

That rocks! Can't wait to try it... And yet I can.

Thanks again, really curious to see the effect. Maybe slice that big X from
earlier in the thread?

              Thanks!
                      -Abe.

Sent from my "smart"phone, please excuse brevity and Swype-oes

On Tue, Jun 19, 2018, 7:18 AM Mark Burton notifications@github.com wrote:

Just letting you folks know that I have separated out the overhang support
from the bridging and there will be two new settings, one is the threshold
angle which determines if a wall is overhanging or not and the other is a
speed factor that allows the overhanging wall to be printed slower if
desired. It also moves the wall start points to avoid starting a wall
polygon at an overhanging point.

The code is new and will obviously require testing and improving before
submitting as PRs. However, I am not submitting the PRs until the log jam
of outstanding PRs goes away as there is some dependency on the earlier
changes being accepted.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/3875#issuecomment-398415324,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAClkdb4NSl8QLInZtQQjca5PGu8QszIks5t-QgngaJpZM4UXjqF
.

AbeFM on 19 Jun 2018

Here's a couple of images that show how the start vertex gets moved so that it is not above air:

screenshot_2018-06-20_10-35-44

screenshot_2018-06-20_10-35-24

If you want to try this out (linux only) you can find a tarball at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

This is the current master branch with my additions/tweaks (YMMV).

smartavionics on 20 Jun 2018

By default, the overhang wall angle is set to 90 to disable the feature and the overhang wall speed is set to 100%. You will need to adjust those values to suit your requirements.

smartavionics on 20 Jun 2018

So far it looks to be printing the shell wall at the reduced speed and the inner walls at regular speed.