Skin Edge Support sometimes emits same infill region multiple times

[richfelker]

For many files I've sliced, the Skin Edge Support feature results in the exact same infill region being emitted multiple times (possibly with different zig-zaggification). I suspect it's a logic error with how the region is split when the internal edge support lines are added, causing the same region to appear more than once (or possibly overlapping non-identical regions to get infill applied). This produces enormous nozzle backpressure, trying to print over already-printed infill lines, and quickly causes the extruder hob to start grinding filament, jamming the extruder and causing the rest of the print to fail.

I can try to provide some example cases. I know I've seen it multiple times in the past with both my own files and models from Thingiverse, and I just encountered it again with https://thangs.com/CHEP/CHEP-Universal-Building-Block-24184

[smartavionics]

Please provide a project file that suffers from this issue and I will investigate. Thanks.

[richfelker]

I don't use the frontend with project files but I can provide a command line with fdmprinter.def.json and minimal or empty options on top of that. I'll check if it's reproducible with no options.

[richfelker]

I'm not sure if I can reproduce it without zig-zaggify, but this works:

CuraEngine slice -j fdmprinter.def.json -s zig_zaggify_infill=true -l Flexible\ Block.stl

The resulting file has 8 layers of skin at the top, one non-broken layer just below it, and then 3 broken layers with infill emitted twice at Z=5.2, 5.3, and 5.4.

The stl file is from the link above. I can attach it if you have problems getting it.

[smartavionics]

Please provide the model, thanks.

[richfelker]

Here is the file. chep_flexible_block.stl.txt (not actually text stl but github won't let you upload without adding a .txt extension...)

[smartavionics]

Thanks for the stl, could you also please provide the gcode file that you get as I can't reproduce the problem yet. Thanks.

[richfelker]

skin_edge_bug.gcode.txt

[smartavionics]

OK, thanks for that. Yes, I can see the duplicated infill. It doesn't happen in my Cura build because I have the following additional code which the Cura devs may wish to consider adding to their code...

@@ -1656,6 +1754,9 @@ bool FffGcodeWriter::processSingleLayerInfill(const SliceDataStorage& storage, L
                 infill_lines_here.cut(tool);
             }
             infill_lines.add(infill_lines_here);
+            infill_lines_here.clear();
             // normal processing for the infill that isn't below skin
             in_outline = infill_not_below_skin;
             if (density_idx == last_idx)

I think I have mentioned this before somewhere but my memory fails me.

[smartavionics]

Ah yes, it was discussed in https://github.com/Ultimaker/CuraEngine/pull/1422 where @Ghostkeeper didn't like something so the fix never got used. Hard luck...

[richfelker]

Thanks! I'll apply this and report back whether it works for me but I would assume it does. Are you confident it doesn't do anything else wrong (like omitting infill where there should be)?

[smartavionics]

The original fix was https://github.com/smartavionics/CuraEngine/commit/f4b96769ad29971c92fce33c9a59cbe102b45f36

[richfelker]

OK, I've confirmed that this fixes the problem. Thanks! I hope the maintainers will consider merging your PR to close this.

[richfelker]

FWIW this bug literally broke my printer, in the sense that the teeth of a 3D printed gearbox I use prior to a remote direct drive flex shaft broke after repeatedly trying to extrude against existing infill with nowhere to go. I had sufficient spare parts to replace it, and this was designed as the weakest point to avoid damage to valuable non-printed components, but I still think this makes it a severe issue meriting priority fixing.

[smartavionics]

I'm truly sorry that your printer was broken by my bug. I did try to get a fix for the bug into UM Cura as soon as I discovered the problem but as you can read in the PR cited above, it was never taken up by UM.

[richfelker]

No need to apologize - bugs happen. I just want it to get fixed promptly now that it's known (for the second time) so that it doesn't affect anyone else. And I'm glad to have it working now so I can turn this feature back on, because I feel like it really does help the strength of parts with protrusions on top of flat skin.

[Ghostkeeper]

Effectively it was not merged back then because the issue is fixed in Arachne by a refactor, and because the fix in that PR is a patch for a weird construction with the intermediary infill_lines_here variable. We proposed that the entire variable should get removed instead of clearing the variable and then making new copies of the infill into it.

I don't know what happened after that proposal, since this went through the discussions about PRs which isn't a meeting with meeting notes. But yes, this issue is fixed in version 5.0. I can bring it up with the team to see if we'll need to do something for the intermediary release.

[fvrmr]

We have discussed it with the team, and since it will be fixed in 5.0 we won't fix it now for releases before 5.0, I hope you understand.

[richfelker]

Will 5.0 be the switch to Arachne? If so (well even if not, but especially if so) would you at least merge the PR to present mainline so that there will be a non-Arachne version without the bug, even if you're not making a release with it? I'm liking Arachne a lot now that some of the issues I hit seem to be fixed but I suspect there will be long-term use for the old engine too in some applications.

[Ghostkeeper]

Yes, 5.0 is planned to be the release of the Arachne.

We provide security support for LTS releases of Cura (4.10 was LTS), but I don't think this would be classified as a security issue. We are currently maintaining these two versions of CuraEngine. Essentially, you could see the 5.0 release as the end of supporting both versions.

The refactor for the skin area generation that fixed this cannot be backported to master since it was made to deal with skin areas delimited by variable width lines. We could write a new fix, but that's precisely what we chose not to do, setting priorities based on how uncommon this problem is, how easy the workaround is and the damage of the result.

[richfelker]

The one-line patch in the overlooked PR above fixes it. Why not just apply this to mainline??

[ky438]

@smartavionics - has this been fixed?

[smartavionics]

Hello @ky438 , sorry, I don't know the answer to that as I do not follow the Cura 5 development.

[richfelker]

The fix is in Cura 5 and has been since long ago, as described above. It just didn't get a backport to Cura 4, despite it being a trivial fix to Cura 4. I had the fix in my Cura 4 branch, but I haven't used that in a long time.