You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Load or create a model with curved thin walls about the nozzle thickness. Here's a half-sphere with 0.4mm wall thickness created with a sphere primitive and a concentric sphere primitive of 0.8mm smaller diameter subtracted: Sphere-Shell.3mf.zip
Slice and print the model.
Actual results
The G-code for the curved thin walls has G1 segments with almost zero movement. On my Klipper v0.11.0-87 printer, this results in decelerations at each nearly-zero-movement move, which in turn result in small overextrusion blobs. From the comments embedded in the g-code, it appears that Arachne thinks the extrusion width should change a tiny amount for a tiny distance, for example from layer 30 of the attached Sphere-shell example, the exported g-code lines 3106-3113 (layer 30 operations 5-10) are (with comments added for move distance):
Note that for the two moves after WIDTH:0.399154 have distances of less than 0.02 mm. Also note that the width is only about 0.005 mm changed!
I have observed this behavior on PrusaSlicer, but I don't observe it on Cura, so perhaps it's an Arachne issue that has been fixed already in Cura, or perhaps it's a configuration difference.
I think a simple solution might be to allow nominal extrusion width to change by some epsilon amount (perhaps 0.01 mm) without requiring a new segment.
Expected results
Output where each G1 segment is of a non-trivial length, avoiding movement stalls.
OrcaSlicer Version
1.8.0
OS version
macOS 14.1.1 (23B81) arm64
Additional system information
No response
Printer
Elegoo Neptune 3 0.4mm nozzle
How to reproduce
Sphere-Shell.3mf.zip
Actual results
The G-code for the curved thin walls has G1 segments with almost zero movement. On my Klipper v0.11.0-87 printer, this results in decelerations at each nearly-zero-movement move, which in turn result in small overextrusion blobs. From the comments embedded in the g-code, it appears that Arachne thinks the extrusion width should change a tiny amount for a tiny distance, for example from layer 30 of the attached Sphere-shell example, the exported g-code lines 3106-3113 (layer 30 operations 5-10) are (with comments added for move distance):
Note that for the two moves after
WIDTH:0.399154
have distances of less than 0.02 mm. Also note that the width is only about 0.005 mm changed!I have observed this behavior on PrusaSlicer, but I don't observe it on Cura, so perhaps it's an Arachne issue that has been fixed already in Cura, or perhaps it's a configuration difference.
I think a simple solution might be to allow nominal extrusion width to change by some epsilon amount (perhaps 0.01 mm) without requiring a new segment.
Expected results
Output where each G1 segment is of a non-trivial length, avoiding movement stalls.
Project file & Debug log uploads
Sphere-Shell.3mf.zip
Here's a more complex model that shows the blemishes more dramatically:
wingtip-slice-artifacts.3mf.zip
Here's an example printed from OrcaSlicer 1.8.0 from the project above, showing the blemishes:
Checklist of files to include
The text was updated successfully, but these errors were encountered: