Open vinitlee opened 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.
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.
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.
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.
The empty G1 lines were fixed. I believe this issue is similar to https://github.com/prusa3d/PrusaSlicer/issues/3058
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
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: (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