Regular print speeds overrides "slow down" cooling settings

[VanessaE]

[Using Slic3r from @lordofhyphens Debian-ready fork, should still be at HEAD]

If a layer feature such as a small perimeter (the periphery of a 5 mm diameter cylinder, for example) is bring printed, and it occurs at a point in the print where layer cooling with print-speed-slow-down is expected, the layer fan speeds up as configured, but the configured print speeds (as in feed rates) in Print Settings → Speed gets used, regardless of what speed the values in Filament Settings → Cooling → Slow down if[...] would calculate out as.

For example, if I have a small perimeters value of 10 mm/sec, and auto-cooling is enabled with a minimum speed of say, 1 mm/sec, and I were to print a single small object like the aforementioned cylinder, it'll get printed at 10 mm/sec, even if the slow-down auto cooling feature should have turned the speed down lower. If you examine the G-code this example generates, you will notice the feed rate never drops below 600 mm/min.

Example model file: http://www.thingiverse.com/download:1121088 -- get the "lid.stl" file.
Config bundle, not that it's really needed: Prusa i3 - Slic3r 1.3.0 config bundle.ini.zip

Print the model by itself, but whatever settings you use, turn your layer fan speed down, as you're likely to have a better fan setup than me, which may invalidate the test. You will notice that the little "nub" on the top of the part, and some of the surrounding slopes, will basically melt down as they're being printed.

Adding a dwell command to the per-layer custom G-Code could help, but that can cause ooze, so an effective, if hacky, workaround is to add a few "sacrificial" objects (such as the aforementioned 5mm cylinder) to the plate, way off to one side and widely separated, to force the printer to take longer to print. I've read that some folks just put multiple copies of their object on the plate to accomplish this. Either way, extra/sacrificial objects waste filament and add extra print time when it wouldn't be needed.

[VanessaE]

duplicate of #3134

[lordofhyphens]

@VanessaE https://github.com/lordofhyphens/Slic3r/tree/debian-pr_3303 has a fix in it supplied by @hyperair
Please give it a shot and see if it helps you.

[KlausHans]

Hello,
i've ran in the same issue, i've build Slic3r from master yesterday. The bug is still present here. The fork provided by @lordofhyphens in the "debian" branch got this issue too. The "debian-pr_3303" fixed it indeed. But with all builds (debian and debian-pr_3303) from @lordofhyphens fork i get errors at the startup like "slic3r failed to load image from file "usr/share/slic3r/printer_empty.png"." and there are no icons in the settings.

I am not firm with the structure of this project, so i kindly have to ask some qustions: Why is the fix not in the master branch? Why is the issue closed if the fix is not present in the master branch? When will fixes like this be implemented in master? Is it ok to write here or do i have to open a new issue?
And of course, how do i solve the issues with the images when i use the fork? I've attached a screenshot.

Edit: Ok, i've solved the problem with the icons. I had to made a "slic3r" directory in the usr/share folder and copied the icons from the slic3r/var directory. Weird nonetheless.

[lordofhyphens]

@KlausHans She closed it because it's a duplicate of #3134. The linked issue was closed because the pull request associated with that branch was merged into master. The code in the pull request is there (I just verified this myself).

It's not in the debian branch because that branch is currently very much behind master (I haven't been maintaining it as much because I have a way to build Slic3r that doesn't wreck my system Perl install).