Features fail with extra G1 moves when above a certain layer height and Detect Thin Walls is enabled

vinitlee commented 3 years ago

Version

2.2.0+win64 (and still present in 2.3.0-alpha3+win64)

Operating system type + version

Windows 10 Enterprise Version No. 1809

3D printer brand / version + firmware version (if known)

Original Prusa i3 MK3S, unmodified, stock firmware, version 3.9.1

Behavior

Describe the problem When printing small loops with 0.3mm layer height and Detect Thin Walls enabled, lots of messy G1 commands are generated for Gap Fill that cause the feature to fail.
Steps needed to reproduce the problem Make a cylinder with 5mm diameter, 10mm height, and 1.5mm wall thickness. Set layer height to 0.3mm. Set: External Perimeter Width = 0.45, Detect Thin Walls = True. Optionally add a brim for printing. This should generate a model with two outer perimeters and a "Gap Fill" trace. Generate GCODE and print.
Expected Results You should get out a physical model that looks like the 3d model +/- tolerances. Given these settings, there should be 3 traces on every layer: two external perimeters and one collapsed fill trace. All three of these traces should have somewhat similarly-spaced G1 commands.
Actual Results You do not get a model that looks similar, but rather a bloated, messy solid blob: (From left to right: 1. straight out of PrusaSlicer, 2. with empty G1 lines removed, 3. with empty G1 lines and very short extrusions removed)

You can see the resulting G-code generated from the attached 3mf file here: Raw and Filtered GC.zip In "Raw Output.gcode", look at lines 1799:1996. There are a few odd things going on here. The most visible is that there are a lot of blank G1 codes that don't seem to do anything. However, removing these doesn't change much. The real thing causing problems seems to be the large number of moves in the infill trace and the distribution of these moves. Here is an illustration from a G-code renderer: Annotation 2020-11-16 142940 (Left: 0.1mm layer height, Right: 0.3mm layer height) In the 0.3mm file, there are drastically more G1 commands generated and there are many on top of each other. It's possible that these tiny steps also have incorrect extruder deltas, resulting in overextrusion. This happens suddenly after a certain layer height. I am not sure what determines this cutoff, but it will cause the number of G1 moves in the gap fill to increase from ~30 moves to ~100 moves.

I've written a script to strip out tiny moves, and that removes the issue, but is external to the slicer. Results seen above. Alternatively, printing below this layer height threshold will yield similar results.

Project Files

3MF STL

Additional screenshots

Annotation 2020-11-16 180621

bubnikv commented 3 years ago

I tried to generate a G-code with the current PrusaSlicer 2.3.0-beta2 https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.3.0-beta2 and I don't see the G1 lines generated with no axis. Would you please retest with PrusaSlicer 2.3.0-beta2?

BTW if you are printing such a small object alone, you will most likely have an issue with cooling.

dartrax commented 2 years ago

I've just noticed those empty G1 Commands in the preview of 2.4.0 beta 1 and was curious if this is a (known) bug. So I found this and I take the opportunity to provide a project file that reveals this. However, empty G1 commands have also been mentioned in #3058, so I think it's already known.

Empty-G1.zip

bubnikv commented 2 years ago

The empty G1 commands get generated from G1 Fxxx by the cooling buffer when the feedrate is found to be equal to the preceding feedrate emitted. Thus the cooling buffer has to be improved.

bubnikv commented 2 years ago

The empty G1 lines are produced by the cooling logic. Fixed with 4e9f906848f6bbe31476e355919692ec1fb7b40d

Cooling buffer used to remove F word from G1 Fxxx lines if the feed rate
did not change compared to the preceding value creating empty "G1" lines.
The empty "G1" lines are now removed.

bubnikv commented 2 years ago

The empty G1 lines were fixed. I believe this issue is similar to https://github.com/prusa3d/PrusaSlicer/issues/3058

prusa3d / PrusaSlicer