A lot of strange unnecessary movements generated in Cura 4.11.0

[Tarik2142]

Application Version

4.11.0

Platform

Windows 7

Printer

Ender 3

Reproduction steps

Open Cura 4.11.0
Slice bike_numer_sign v5.stl

Actual results

File "bike_numer_sign v5_4.11.0.txt"
On layer 16, a lot of strange unnecessary movements generated, and the Z-axis uplift did not apply to them either.

Expected results

Gcode in file "bike_numer_sign v5_4.9.1.txt"

Checklist of files to include

• Log file
• Project file

Additional information & file uploads

Correct gcode bike_numer_sign v5_4.9.1.txt
Bug bike_numer_sign v5_4.11.0.txt
Original model bike_numer_sign v5.zip

[Tarik2142]

screenshot

[GregValiant]

If you use "File | Save Project" the 3mf file would include your settings and the model. You would need to zip it and post it here.
It makes debugging easier.
Do you have "Optimize Wall Printing Order" enabled? With it enabled the walls in one area would finish without all the jumping around.
Are you using "Combing"? Combing can cause a lot of movements.
If it isn't Z-hopping then it isn't retracting. What is your "Retraction Minimum Travel" distance? Moving from letter to letter isn't far and maybe you aren't going the minimum so no retraction and no Z-hop.

[Tarik2142]

Optimize Wall Printing Order disabled.
Combing enabled.
Yeah it a combing problem!
Here is my project bike_numer_sign v5_project.zip

[GregValiant]

I don't think it's so much of a combing problem as an assembly problem.
Here is layer 13 (and 14 is the same). Lots of areas that don't get skinned because Cura knows the letters will be there and so avoids the areas.

To get around this behavior I typically bring the base into Cura and then bring the lettering in separately. Since they are separate models the "per model" settings can be used. The "letters" model would have the raised border and that will allow you to precisely locate the letters on the base. The base will print with full layers (no gaps for the letters) and then I set the letters to print with no bottom layers and no infill.
Turning on "Optimize Wall Printing Order" will help but I really don't see a lot of travel on layers other than 13 & 14. There has to be travel between the letters so that part doesn't count. All of those void areas require borders also so that is more movement.

[Ghostkeeper]

Setting the Minimum Infill Area to 1000mm² also gets rid of those thin pieces of infill. It may be a bit easier than adjusting the model.

Funnily enough, I can reproduce this issue in Cura 4.11, but not in the current master any more. Taking a look at the difference, I can narrow it down. It turns out that this commit from yesterday fixes the issue here.

It's somewhat explainable why it has an effect, but I can't explain why the effect is to travel to that specific location every time.

The problem is with this piece of wall:

It exhibits the problem described here in more detail where the limited resolution of the input mesh causes the width to oscillate slightly, dipping just below 3 line widths periodically. Until Arachne is merged, when below 3 line widths it will print with 2 walls instead of 4. So it creates tiny loops of walls. When one of these loops is finished, it wants to travel to the next loop. But since it finished the loop on the back side, it would need to go through the wall it just printed. This is not allowed by the combing mode "within infill". It can only go through infill. So it goes to the nearest infill area. Which seems to be in that letter A, an entirely different part. That seems like a bug to me.

After the fix, this doesn't happen any more, because the fix aligned the infill area correctly when using the Infill Overlap parameter (which is currently set to 30% in this project). Instead of both infill and gap filling, it now just has an area of gap filling there. So there is no more infill to travel to and - as a result, it doesn't make that weird travel any more in 4.12. That bug causes there to be a tiny bit of infill, which was wrong, but it's fixed now.

Why it thinks it can make that big travel move to the invisible "infill" area though is unknown to me. It's in a different part so it should see that it can't make that travel move without going through more walls.

[GregValiant]

@Ghostkeeper that is a very nice nuts and bolts analysis.

[Ghostkeeper]

I guess it's fair to close it, yeah. The symptom has been fixed at least. And Arachne will fix the rest.