Excessive print head travel: WTF?
Hello,
this is what my print head does when I print the attached frame. Note the heap of blue lines all over the place. This is just the first layer! The others are at least as bad.
In fact half of my print time is head travel. That's excessive IMHO; when I watch this print I get whiplash from shaking my head. (Kidding. Well, mostly.)
Is there any way to fix this, other than "file a bug in github and hope that the Prusa people get around to looking at it … whenever"?
For comparison, this is what Cura does with the same first layer:
RE: Excessive print head travel: WTF?
First of all you don't have to open a bug on github reporting excessive travel movements. There are already enough of them 🙂 Duplicates just clog everything up.
Secondly 'sometimes' switching the slicing algo to Classic rather than the new default of Arachne can reduce that. You haven't attached a zipped up prusa slicer project file so we can't see if that would help.
Thirdly you might want to download the Prusa Slicer 2.9.1-Alpha release from github and test it with your project (again you haven't included one so WE can't check for you) but you might be interested in this line from the release notes-
"Fixed printing order of open perimeters with Arachne perimeter generator, which led to excessive travel moves. #11658"
https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.9.1-alpha1
RE: Excessive print head travel: WTF?
*Sigh* sorry for not noticing that the forum *still* doesn't allow upload of .3mf files. This should be rather easy to fix …
File attached; I'm building 2.9.1alpha1 right now but that does take a while.
RE: Excessive print head travel: WTF?
Thanks for the project. With 2.9.1-alpha
Classic travel % is 20.4% (with nearest seam configured 18.5%)
Arachne travel is 24.6%
With 2.9.0
Classic travel % is 20.4%
Arachne travel is 24.6%
So identical. Not sure what that supposed fix is actually fixing looking at it. Still a lot of travel moves.
RE: Excessive print head travel: WTF?
TBH this isn't the only case where the slicer appears to randomize paths instead of optimizing them. I often print bins with lots of little compartments, and the order those compartments are printed in is … random, to say the least.
RE:
Example attached.