Slic3r: No slowdown of external perimeter when infill is printed

[MacFlieger]

Version

1.3.0-dev-5fd87df

Operating system type + version

OS X 10.12.6

Behavior

I have enabled "Auto cooling" and slow down printing if the print time is below 10s with minimum print speed of 1mm/s.

If the print time for one layer ist below 10s, the auto cooling does not slow down the printing of external perimeters if the infill is above 0%.

It is easy to replicate, even as dry run:

• cube with 20mm size
• perimeter:2
• infill: 0% or 5% Rectilinear
• speed for perimeter 60mm/s
• "auto cooling" enabled with slow down printing if the print time is below 10s with minimum print speed of 1mm/s.

1. Speeds Without Infill (0%) works as expected:
2. internal perimeter: 15.22mm/s (G1 F913.34)

3. external perimeter: 15.22mm/s (G1 F913.34)

4. Speeds With Infill (5% Rectilinear) does not slow down external perimeter:

5. internal perimeter: 16.1mm/s (G1 F965.795)
6. external perimeter: 60mm/s (G1 F3600)
7. infill: 16.1mm/s (G1 F965.795)

[dwillmore]

I believe this is intentional. The external perimeter speed is considered critical to the appearance of the printed part, so variations in speed may result in differences in surface finish. So, if at all possible, the exterior perimeter speed isn't changed if there is any other way to manage it.

Basically, if(infill OR (perimeters > 1)) then leave the exterior perimeter speed alone and slow down the reast.

So, not a bug?

[MacFlieger]

I don't think so.

First: This behavior is new. With older versions it works as expected. Every movement except travel was slowed down. I don't know, at which version the behavior changed.

Second: As I have described, the external perimeter is only fast, if infill is present. Your assumption "if(infill OR (perimeters > 1)) then leave the exterior perimeter speed alone and slow down the reast." doesn't describe the actual behavior. The external perimeter is slowed down even if perimeter>1 and no infill.

Third: The appearance of the printed part is much more worse if the speeds change so much in one layer from internal to external perimeter than by changes from one layer to another.

I have reported another slow down issue nearly 2 years ago: https://github.com/alexrj/Slic3r/issues/3325
There was no slowdown of all movements if the option "verbose output" was not checked...

[lordofhyphens]

If there was no difference in the actual gcode other than the additional
comments, the only reason I can think of for a slowdown is throughput.

On Feb 23, 2018 12:23 AM, "MacFlieger" [e-mail] wrote:

I don't think so.

First: This behavior is new. With older versions it works as expected.
Every movement except travel was slowed down. I don't know, at which
version the behavior changed.

Second: As I have described, the external perimeter is only fast, if
infill is present. Your assumption "if(infill OR (perimeters > 1)) then
leave the exterior perimeter speed alone and slow down the reast." doesn't
describe the actual behavior. The external perimeter is slowed down even if
perimeter>1 and no infill.

Third: The appearance of the printed part is much more worse if the speeds
change so much in one layer from internal to external perimeter than by
changes from one layer to another.

I have reported another slow down issue nearly 2 years ago: #3325
https://github.com/alexrj/Slic3r/issues/3325
There was no slowdown of all movements if the option "verbose output" was
not checked...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/alexrj/Slic3r/issues/4313#issuecomment-367921549, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAB8CpUAMgYbD5X9XdTQu1EsLgNIGe4Xks5tXllTgaJpZM4SNUbp
.

[MacFlieger]

If there was no difference in the actual gcode other than the additional
comments, the only reason I can think of for a slowdown is throughput.

OK, I should have not mentioned the old bug with "verbose output". This bug was solved and there was really different speed GCodes, depending of verbose output or not.
But as written, this old bug was solved and I have only mentioned it, to show dwillmore, that mysterious bugs with slowdown can happen.

The actual bug as described in my first post is not related to verbose output and the differences are clearly visible in the GCode. Only the speed of external perimeters is wrong if an infill is present.
Very strange.

[MacFlieger]

I have found the problem in the source code and it is not a bug.
In CoolingBuffer.cpp at lines 82-88:

// If we spend most of our time on external perimeters include them in the slowdown,
// otherwise only alter other extrusions.
if (this->_elapsed_time_external < time_to_stretch/2.) {
time_to_stretch -= this->_elapsed_time_external;
target_time -= this->_elapsed_time_external;
slowdown_external = false;
}

So it is a "feature", that the external perimeter has no slowdown if the printing time of the external perimeter is less than half of the complete printing time.

But I think, that this is a bad behavior, because of the very big speed change e.g. in my first posting from 16 to 60mm/s.
If the minimal printing time for one layer is set to more than the 10s in my example, the effect increases drastically. E.g. if the minimum time is 30s, the speed changes from 5 to 60mm/s. This is very bad for PETG.

My suggestion:

• The user should be able to disable this behavior or
• the external perimeter should always be slowed down like the other perimeters.

[chambm]

It's definitely a good idea to keep a constant external perimeter speed. A better way to approach this may be to analyze all layers' time, calculate the speed of the external perimeter on the layer with the most slowdown, then apply that speed to external perimeters of all layers.

[pedromelim]

I encountered a similar situation while i was printing a small object (Marvin key chain). I encountered lines in the middle of the print that "shrunk" on those layers of the model. I tracked it down to being a faster speed for those layers.

I think a solution for this would be to implement a feature like @MacFlieger suggested. Let the user decide if he wants to include the external layer on the slowdown.

NOTE: I used Slic3r Prusa Edition, but i think the behaviour is similar.

[MacFlieger]

It's definitely a good idea to keep a constant external perimeter speed. A better way to approach this may be to analyze all layers' time, calculate the speed of the external perimeter on the layer with the most slowdown, then apply that speed to external perimeters of all layers.

I don't think so.
This might be good with some objects and filaments, but if you have an object which is small on one layer, resulting a great slowdown, this results to a great speed change on almost all other layers.
Some filaments are not much sensitive on speed changes, but other are. PETG and TPU don't like great speed changes.

[Ccecil]

I just finally figured out that this was what is causing the poor surface on my PETG prints. The funny thing was it wasn't happening to my prints that used 2.85mm filament but only happens when I use the 1.75mm hotend with the same extruder. I suspect it is showing up because of the speed difference in the extruder more in the smaller diameter (I use a 5.18:1 planetary gearhead running direct drive to the hotend).
https://flic.kr/p/2kqjXzP https://flic.kr/p/2kqjXzt 2.85mm filament print
https://flic.kr/p/2kqjq1k 1.75mm filament print (shown in video below)

I have a video https://youtu.be/I257V1NR6GU of what is happening and why it is an issue for me. This should be something that can be turned off by the user for sure. For now I will just be sure to use a modifier mesh on the parts which I want to be slowed down.

This has been an issue I was chasing for quite some time. It explains a lot of my problems when I switched to 1.75mm filament last year on these machines. I did a bit of extruder redesign and some other things to shorten my filament path in order to mitigate this...but now it all makes sense. I suppose I just never noticed it was doing that...or assumed it was doing a travel while "avoiding perimeters".

If you would like me to post the gcode from the 2.85 and 1.75mm versions for a comparison let me know...I am a bit curious why this doesn't seem to be an issue with the larger diameter. I attempted to limit my E accel way down to mitigate it but it didn't help much.
This is one of those issues that if I only used PLA I might have never noticed.