PrusaSlicer
PrusaSlicer copied to clipboard
prusa3d
1.40.1 sliced code has speeds greatly suppressed when using auto speed
Version
1.40.1+linux64
Operating system type + version
Ubuntu 16.04
Behavior
-
Describe the problem My printer is capable of printing at higher speeds, but whenever I slice with the PE edition of Slic3r, the max speed it generates is around 30-35 mm/s. When setting as compatible settings as possible in Slic3r 1.2.9, it generates speeds of over 80 mm/s which cuts my print time way down from 2:53 to 1:10. I can't seem to see any settings that are holding this back.
-
Steps needed to reproduce the problem For my example here, I'm printing the 3D-Benchy model, but I see it happening on any model I print. I've set most of my speeds to zero, except for outer perimeters, gap fill, bridges, etc. and some speeds as percentages like top solid infill. My autospeed setting is 120 mm/s and my volumetric speed is 13.78 mm^3s. I'm using volumetric extrusion, but if I turn that off everywhere, it still yields almost the same speeds and time required to print.
-
If this is a command-line slicing issue, include the options used
-
Expected Results I would expect most auto generated speeds to be much faster,
-
Actual Results On layers that have only perimeter and infill, the color scale in Repetier Host is showing that the print speed of the infill is only in the 18-20 mm/s range. The same layer sliced with Slic3r 1.2.9 shows the infill in the 60-66 mm/s range. Same goes for any of the autogenerated speeds. If I manually set the infill speed to say 100 mm/s, then the sliced model comes out with the infill in the 66-72 mm/s range in the PE version. I have cooling settings on in the attached settings, but turning that off has no effect. Most layers print longer than the cooling threshold.
- Screenshots from Slic3r preview are preferred
Is this a new feature request? No
STL/Config (.ZIP) where problem occurs
Upload a zipped copy of an STL and your config (File -> Export Config)
slic3r-issue.zip
I don't know why this would be different between versions (if this is even the problem), but your slowdown_below_layer_time is 30 seconds. On an old benchy gcode I have on Octoprint, it's saying a lot of my layer times are expected to be less than 20 seconds. Mine is printing 241 layers (0.2mm) and if every layer was 30s long it would take at least 2 hours.
Yes, the configuration I sent had that setting, but I've tried it without any cooling features and it still gave me only a slight difference. It reduced the printing time from 2:53 to ~2:35. Still way slower than 1.2.9 and no speed greater than 28 mm/s.
Ok, I started with the "My Settings" profile for printer, filament, and print. Without changing any setting, it sliced at a total time of about 1:02. Then I started customizing and setting in all the settings I was using in my original post. I started with the printer, then the filament. I was re-slicing after every section of every profile. Before starting with the print settings, the total print time was 1:08. I then started modifying the print settings other than speed, saving, and re-slicing. The total print time was around 1:43.
The default "My Settings" profile for the print settings, have all hard coded speeds of the defaults listed. I set my autospeed max up to 120 from 80. I set perimeter speed to 0 and re-sliced. It set a decent speed for perimeters of about 60 mm/s. At this point, my total print time was about 1:25. It seems the real culprit is the infill speed. It is by default a hard coded 80 mm/s. When I set that to zero, it always wants to choose an infill speed of somewhere around 18 mm/s. My bridge speed is 22 mm/s and it could be doing that, but based on the color coding in Repetier Host, it looks like it's a little slower than 22. Also, if I set the infill to 0, then the perimeter speed drops to whatever it's generating for infill. They seem to be locked together when perimeter is 0 also.
So, either it's treating all infill as bridges, or it's doing some other wacky autospeed calculation to cause it to generate very slow infill. That appears to be the difference between 1.2.9 and PE 1.40.1. The workaround for now is to hard code the infill speed.
If I drop the max autospeed back down to the default 80 from 120, then my print time goes up to ~3:30 and the perimeter and infill speeds drop to about 14 mm/s (perimeter and infill set to 0)
Why do you insist on the autospeed feature? We do not use it internally at Prusa Research, we always set explicit extrusion velocities. The autospeed feature has issues with the gap fill, which commands excessive extrusion rates, and the whole print is then slowed down to limit the maximum gap fill extrusion rate.
I'm not insisting on using autospeed nor am I giving this a priority or saying it needs to be fixed immediately. I'm perfectly fine to use hard coded values as the only two speeds I would even think to use autospeed for are infill and perimeters. Most of the other speeds I use are based on my own calibration testing. I was trying it out and saw there was a big difference between using autospeed in 1.2.9 and the latest PE version and I thought I should report it with as much detail as I could figure out. That way it's at least documented. Do with it what you will, I'm just trying to be a good developer and report a bug.
Thanks for the report. There are a lot of reports streaming in, and I am trying to asses their severity. I appreciate your time reporting this issue, but for now this issue is considered low priority and it will be postponed.
My Autospeeds dropped from ~80mm/s to 20mm/s because "detect thin walls" was enabled, although my model had no thin walls at all.
@bubnikv this is most definitely a problem, if for no other reason than some hotends just perform better when given a constant pressure/flow.
Lack of automatic speed for gap fill also leads to inconsistent speeds even with two instances of the same part using the same print profile:
Suppose you have a simple open-top box with thick walls (like those stackable part organizers, or a "desk tidy"). You choose a print profile with a specific number of perimeters at a particular line width which, when sliced, results in a fairly thick gap fill line running through the centers of the walls. Ok, so far so good.
Now, increase one of the perimeter line widths a bit, enough to cause the gap fill to become really thin.
Since you're required to provide a fixed speed for gap fill, Slic3r is forced to print each gap fill line at whatever flow rate is dictated by that fixed speed and the space to be gap-filled. That in turn causes the rest of the print to slow down or speed up to match that flow rate. Thus the box with the really thin gap fill lines will print much slower than the one with the thick lines, even though the same amount of plastic is to be used.
Of course, if you turn gap fill off, all other automatic speeds would be where they should, but doing so can negatively impact the strength and/or appearance of the part.
No, the gap fill flow rate needs to be held at whatever the user's set the flow rate at, and its speeds varied instead, even if that means you'd end up with relativistic speeds. :smiley: Of course, this is the point where the "max print speed" setting should come into play, as a limit to be applied after all "ideal" speeds have been calculated. If something can't reach the requested flow rate, it won't alter the overall print speed of the part, it'll just run that one feature at the capped speed.
In mainline Slic3r, speeds are set to auto by explicitly choosing "auto" from the combobox for each entry, including gap fill, which is enabled/disabled independently of any speed via a checkbox in the "Infill" section of the print profile.
We do not use it internally at Prusa Research
The world isn't contained entirely within Prusa Research. :stuck_out_tongue_closed_eyes:
Any movement on this? Enabling thin walls still trashes the speeds normally achieved in autospeed mode.
Why do you insist on the autospeed feature? We do not use it internally at Prusa Research
WOW. What a response from a Prusa worker. Horrible. Have you ever even used your own software, or read your own documentation?
From your site:
And in fact this is indeed a valuable feature. To brush off a bug with it because you don't personally use it is insane. As someone else said, the world also exists outside of Prusa internal. And if you are so averse to your own developers' hard work, why not tell them yourself how useless and bad you consider their work and that you want it removed? Until it's fixed, you will continue to get reports about it.
The autospeed feature has issues with the gap fill, which commands excessive extrusion rates, and the whole print is then slowed down to limit the maximum gap fill extrusion rate.
This is the entire problem. You simply aren't applying the flow limits to speed of the gap fill, like every other feature type. See #6844 -- We are reporting that gap fill on classic slicing mode CANNOT be given ANY value when mixed with autospeed on other features. We are asking you to FIX the bug, not tell us there's a bug when we're already reporting it. There's no reason that telling it to go at say, 100mm/s for gap fill, should at all affect my other features set to 0 for auto speed. And if so, certainly not reducing the speed across every feature by so much that it's not even achieving the input gap fill speed (the whole print goes to like 20mm/s, this is unacceptable).
Altogether, this needs fixed if you are going to tout this as a reason to use the slicer. And I sincerely hope a DIFFERENT developer is assigned to the task, one who won't take the position of "WONTFIX" on bugs because you don't experience them in your own workflow, and dissuade users in a conflict of interest of your own documentation.
