Tiny jagged corner slicing one-wall circle, breaks smooth traversal

[richfelker]

Slicing the attached test case generates a tiny spurious move with x,y components -0.003, -0.010 at just past 90° around the circle (and again at just past 270°):

G1 X69.719 Y48.275 E59.31722
G1 X69.494 Y46.563 E59.32805
G1 X69.124 Y44.886 E59.33881
G1 X69.121 Y44.876 E59.33888
G1 X68.601 Y43.23 E59.3497
G1 X67.94 Y41.635 E59.36053

This happens even with the baseline fdmprinter.def.json config, but tweaking meshfix options does not seem to help. Because there is no significant precision at this magnitude, the junction angle to the previous and next moves is not particularly meaningful, and at least with Klipper firmware (I suspect the same happens with Marlin JD though) the printer has to slow to a near stop at this point in the circle then re-accelerate.

The file was generated by OpenSCAD taking the linear extrusion of the difference of a circle of diameter 40 mm, approximated with 72 sides, and itself offset inward by 0.4 mm.

onewall_cylinder_72.stl.txt

[Ghostkeeper]

This is a project file that reproduces the problem, for easier testing.
CFFFP_onewall_cylinder_72.zip

[Ghostkeeper]

Actually, I'm starting to think this is expected behaviour now. We have an exception in the simplification algorithm that prevents moving line segments longer than the Maximum Resolution even if both vertices of the line segment move by less than the Maximum Deviation. This is necessary because of effects like these:

The effect of that is visible in the print as well.

The tiny segment is probably caused by the inset for the outer wall originally. The reason why it is retained is that removing it would shift a long line (defining "long" as more than the Maximum Resolution setting) which can cause this banding effect. In this case though, I don't expect you'd see the effect of removing it, or at least not more than the effect of leaving it. A different definition of "long" might be appropriate.

[richfelker]

I think it's a bug that this segment is being generated to begin with, regardless of how meshfix removal works. It's not an accurate representation of the inset outline, either because of catastrophic loss of precision or some other numerical issue. If it were accurate to begin with, I'm not sure I'd agree that meshfix should even remove it, since removing segments in ways that alter angles significantly could have unwanted effects on printing.

[konskarm]

Devs see ticket in backlog: CURA-8275