Avoid starting a layer on overhang edge corner

[d-schmidt]

Edit 2: 'Overhang Wall Speed' + 'Optimize Wall Print Order' could in theory prevent this, but the overhang deceleration doesn't work properly. When everything is overhang the seam goes back into the corner. I think that might be an actual bug instead of a feature request. See comments and images below.

Is your feature request related to a problem?

An overhang corner warps up and the outside wall there will be rough. This happens on corners which are the start of a layer and an overhang. See images. I start on the inner walls and the outer wall starts on a different point but it still happens.

Describe the solution you'd like

I'd like an option to have Cura try not to start on the overhanging edge. Overhang #3340 and and edge/corner detection (seams) already exists. I would love to have them combined (and working for inner walls).

See Image

Describe alternatives you've considered

Rotating the model to avoid this is not always possible. Speed and temperature changes help only a little bit.

Some tricks have been suggested in #3875 but the ticket was deferred.
It seems some work has been done there and the outer wall doesn't start on the bad edge but the inner walls still do. This still causes reproducable problems for me.

Affected users and/or printers

Curling edges seem to be a common problem but I use Ender 3 V2.
overhang4.stl.zip

phone2.zip

[d-schmidt]

'Overhang Wall Speed' + 'Optimize Wall Print Order' doesn't solve the problem for this specific model.

The overhang (ac/de)celeration(?) is too slow (orange). Everything is overhang (red).

[d-schmidt]

I tried looking through Ultimaker/CuraEngine@2eb9528 but I can't find the place where the acceleration and deceleration distances are calculated.

@smartavionics You wrote the overhang speed function. Maybe you could tell me?

[smartavionics]

Well, it's rather confusing because my Cura builds do modulate the speed depending on the position within the overhang region but I don't think the UM builds do. For info here is the code in LayerPlan::addWallLine() that I am referring to...

    Ratio overhang_speed_factor = mesh.settings.get<Ratio>("wall_overhang_speed_factor");
    const Point mid(p0 + (p1 - p0)/2);
    const bool is_overhang = (!overhang_mask.empty() && overhang_mask.inside(p0, true) && overhang_mask.inside(p1, true) && overhang_mask.inside(mid, true));
    double fan_speed = GCodePathConfig::FAN_SPEED_DEFAULT;

    if (is_overhang)
    {
        if (layer_nr > 1)
        {
            fan_speed = (double)mesh.settings.get<Ratio>("wall_overhang_fan_speed") * 100.0;
        }
        // use the distance from the mid point of the line segment to the inside edge of the overhang mask to modify the overhang speed factor
        // the closer the line segment is to the inside edge of the overhang mask, the closer the overhang speed factor is to 1.0
        // the effect of this is to smooth the speed transition
        const coord_t wall_line_width_0 = mesh.settings.get<coord_t>("wall_line_width_0");
        // end is normal to the line mid point spaced a wall line width to the inside of the polygon
        const Point end(mid + normal(turn90CCW(p1 - mid), wall_line_width_0));
        if (!overhang_mask.inside(end, true))
        {
            // end is not inside the overhang mask area so unless the outline polygon is a very weird shape end must be
            // located nearer to the inside edge of the mask than the outer edge
            ClosestPolygonPoint cpp = PolygonUtils::findClosest(end, overhang_mask);
            if (cpp.isValid())
            {
                // cpp.location is now the point on the inside edge of the overhang mask that is nearest to mid
                const coord_t overhang_width = layer_thickness * std::tan(mesh.settings.get<AngleDegrees>("wall_overhang_angle") / (180 / M_PI));
                const coord_t dist = vSize(cpp.location - mid);
                if (dist < overhang_width)
                {
                    overhang_speed_factor = 1.0 + (overhang_speed_factor - 1.0) * dist / overhang_width;
                }
            }
        }
        // ensure the speed factor does not produce a speed less than the minimum speed allowed
        const Velocity min_speed = fan_speed_layer_time_settings_per_extruder[getExtruder()].cool_min_speed;
        overhang_speed_factor = std::max((double)overhang_speed_factor, (double)(min_speed / non_bridge_config.getSpeed()));
    }

Going out now, see you later...

[d-schmidt]

I did a long model to test this. The problem is not the deceleration which is slow but at least exists. There is no acceleration. It keeps the slow speed until the next different vertex. It doesn't speed up again after the overhang.

Red start, orange direction:

[d-schmidt]

The overhangs are not symetrical. This causes different behavior as you can see above. As expected it decelerates to the right overhang on the visible front (image in last comment).

Surprisingly there is acceleration between the 1st and 2nd follow-up vertex on the other side:

This model: overhang5.zip

It seems it accelerates one vertext too late if there are no other overhangs on this layer. It doesn't accelerate at all if there is another overhang on the layer.

[fvrmr]

Hi @d-schmidt thank you for you feature request.
I will discuss this with the team, keep you posted.

[d-schmidt]

@fvrmr I made some edits just now (not just because I mixed up deceleration and acceleration). I now think fixing after-overhang-acceleration could solve this. Is it possible for the seam to start in the middle of a straight wall?

An explicit feature toggle to keep the seam away from overhang edges would be great tho.

[smartavionics]

BTW, it's worth noting that in UM Cura, the speed colouring in the layer view blends the colour used for a line segment when the speeds at the start and the end of a line segment are different. That is just a visual thing, the actual speeds used when printing will not follow the same profile but, instead, the printing speed will be influenced by the speeds set for each of the line segments and the printer's acceleration and jerk values.

By comparison, the speed colouring used in my Cura builds does not do that colour blending but, instead, uses a solid colour for the whole line segment based on the print speed for that segment only and ignoring the speeds of the line segments that come before and after. I'm doing that because I think it makes the visualisation more accurate. Of course, still not completely accurate because the colouring does get adjusted to account for the acceleration/deceleration that occurs at the junction of two lines that are printed at different speeds.

[d-schmidt]

You are talking about this?

I'm not yet deep enough the rabbit hole of GCode. Are these Outer Wall rectangles just 4 move commands? The official cura build showing the slope in different gradients is just some kind of floating point error? [edit: it's caused by different seam points]

I don't even know what to do with this information. There is no acceleraton or deceleration?

[smartavionics]

Yes, those images illustrate what I have just said (assuming that the image on the left is from my Cura and the image on the right is from an UM release). I wouldn't say it was a floating point error, I would call it a programming error! To me, the speed colour should represent the speed used for the bulk of the line.

[smartavionics]

I think the acceleration/deceleration occurs at the printer firmware level and is not visible in the gcode visualisation.

[d-schmidt]

Yes left is you, right is UM

[d-schmidt]

Okay, so what I imagine is to move the seam away from the overhang:

[smartavionics]

I'll look into that and get back...

[smartavionics]

Can you provide an STL that includes the feature shown in the image immediately above? Thanks.

[d-schmidt]

Yes, ofc.
phone2.zip

If you have one-sided overhangs like in the images below, activating overhangs will push the seam back into the upper slope corner. If both sides of a rectange are overhangs it has no chance. I guess starting a straight line in the middle is not something we usually want.

overhang4.zip (z seam position set to right)
without overhang the seam is in the top right corner:

with overhang, w/o optimize the outer wall now starts in the top left, the two inner walls still start in the top right (and mess up the print quality):

overhang+optimize wall order forces all 3 walls into the top left:

[smartavionics]

A quick experiment gives me this...

Note that the inner wall will still start in one of the corners, it's only the outer wall whose start location is moved.

I will play some more with this over the weekend and probably make a release so that you could try it out.

[smartavionics]

Hi @d-schmidt , I have made a new release at https://github.com/smartavionics/Cura/releases/tag/20210306. If you have any feedback, please open either a new issue or discussion at https://github.com/smartavionics/Cura rather than here, thanks.

[d-schmidt]

Thank you very much. That was much faster than I even expected an answer. 👍
I will definitly try this on my next modified phone stand! And some voronoi easter eggs. Can I get you a beer or coffee?

What is the diff between your cura and the UM version? I see regular upstream merges. Is it this and some fixes?

@fvrmr a possible solution in 4 commits smartavionics/CuraEngine@a7a942b

[smartavionics]

No payment required, I do this for fun!

Unfortunately, these days my Cura source has diverged so much from UM's Cura that I no longer submit any PRs for anything other than bug fixes. This could be considered a bug fix but as the solution depends on some code that already existed in my Cura the required change is more complicated than just the recent 4 commits. Anyway, if you wish to discuss this further please do so over on my repo rather than here, thanks.

[fvrmr]

I have discussed it with the team. And we also think that this has value. So we've created a ticket on our backlog.
Developers see CURA-8076.

[StuSerious]

OFFTOPIC: @smartavionics you should consider github sponsorship, I'd defenetely chip in!

[brunoosti]

Sorry, didn't read the entire thread. But looking for something ele I stumbled on this and think the solution might already been implemented.
Set you Overhanging Wall Angle to 40º and cura will not start the layer at the overhang (I don't know exactly why 45º or 44º doesn't work for every part at that angle; try rotating a cube 45º and see for yourself) .

[d-schmidt]

@brunoosti this trick stops working when all corners are overhangs whichs happens for my model.

[brunoosti]

Oh sure! And the seam settings only apply to the outer wall. I've been dealing with it too and opened a feature request that might help with this (#10290). Overhanging corners normally curl because of not sufficient cooling. The layer below (generally the outer wall) don't have much to transfer the heat to and it tends to reheat, curling up.
I'm guessing here, but do you print the inner walls faster than the outer one? Is there curling ate the inner seam even at slower speeds?
With my sidewinder x1 i'd have to print inner walls at 30mm/s (a crawl...) to avoid any overhanging cornes curling up.

[d-schmidt]

I rarely print the walls faster on my ender 3v2. I've been printing on a bigger nozzle the last few weeks so I print slower anyways.

[MariMakes]

👋 Quick update on our side.
This is resolved in the 5.8 release 🎉 , you can download the Beta version with the fix here: https://github.com/Ultimaker/Cura/releases/tag/5.8.0-beta.1

I'll close this issue since it's resolved.
Thanks again, and please let us know if you run into any other issues 💪