<p>The behaviour you are describing (stopping to extrude before the nozzle finish moving) is called <strong>coasting</strong> and is actually a desirable one if tuned correctly (which is clearly not your case).</p>

<p><strong>Here's a primer on why coasting is good</strong>: the hysteresis (think of it as "springiness") of the filament between the point where the stepper motor pinches it and pushes it towards the nozzle, and the point in which the filament liquefy, makes so that there is always a residual pressure whenever the stepper motor stop spinning.  So coasting consists of <strong>stopping to actively extrude <em>before</em> the nozzle has reached the endpoint of the line</strong> being "drawn", and relying on the residual pressure to finish the job.</p>

<p>Many slicer have a dedicated setting for this, but - to the best of my knowledge - slic3r PE has not.  In your question, you seem to think this may be linked to filament retraction.  It is definitively worth trying (why not!) but <strong>filament retraction normally refers to the act of relieving that residual pressure <em>after</em> the line being printed is finished and before moving away the nozzle</strong>, so... if that setting turns out to be the key to your problem, then it would be quite a misnomer.</p>

<p>A quick way to verify if this is the case could be <strong>toggling the ceckbox "use firmware retraction"</strong> in the printer/general pane of slic3r settings.  If the problem is with the retraction settings you chose, this would ignore them completely.  A clean print would confirm your theory.</p>

<p>Failing that, the best way to debug would probably be <strong>to slice the same model with a different slicer</strong> (<a href="https://ultimaker.com/en/products/ultimaker-cura-software" rel="nofollow noreferrer">cura</a> is a common one) and see if the problem persists:</p>

<ul>
<li>if it does, then the problem is probably in the firmware or the extruder of the printer itself</li>
<li>if it does not, then you would have a set of "good settings" in the second slicer that you could try to replicate in Slic3r PE.  Or - as you believe it may be the case - you could have found a way to trigger a weird bug in Slic3r.</li>
</ul>

<p>Good luck and let us know about your findings! :)</p>

CC BY-SA 3.0
2018-01-26T21:59:12.723Z
whereas I kind of solved the issue in some other fashion, I've looked and some of what you pointed out and, preliminary tests seem promising.
Felix Hauser
CC BY-SA 4.0
2022-04-26T22:34:37.673Z
This answer is outdated and should be updated to reflect the current state of slicing software and printer firmware.
R.. GitHub STOP HELPING ICE
CC BY-SA 3.0
2018-01-21T21:50:19.393Z
2018-01-21T21:50:19.393Z
mac
<p>As mac's answer says, this is <strong>coasting</strong>, but contrary to that answer, <strong>coasting is not good</strong>. At one time (that answer was written way back in 2018 when the state of software was much worse than it is now), it was an idea a number of people accepted as reasonable, but it was operating at the wrong layer, and was a very bad hack, necessarily extruding less material than needed to accurately construct the part being printed. Leading to exactly what OP saw.</p>
<p>Nowadays, printer firmware has a feature called Linear Advance (Marlin) or Pressure Advance (Klipper) that can be calibrated with test prints and compensates for the increased backpressure when extruding fast - or more importantly, seen from the other direction, the reduced backpressure when slowing down at the end of an extrusion path, that results in continued oozing after the extrusion was supposed to end. This feature eliminates the need for hacks that underextrude and produces very accurate extrusion regardless of changes in speed or flow.</p>
<p>Anyone experiencing problems like OP hit should check that their profile does not have coasting (and hacks meant to compensate in the other direction for problems it causes, like &quot;extra prime&quot;) enabled in the slicer.</p>

CC BY-SA 4.0
2022-04-26T22:41:24.563Z
2022-04-26T22:41:24.563Z
R.. GitHub STOP HELPING ICE
<p>If you think it is a slicing problem, look at the G-code. You might want to arrange for the infill to be orthogonal to the axes, but it ought to be easy enough to calculate the ratio between printhead motion and the extruder. G-code is just text, and fairly easy to make sense of. The <a href="http://reprap.org/wiki/G-code" rel="nofollow noreferrer">RepRap</a> wiki has a good reference to the commands, and all you care about are X-Y movement, and E movement.</p>

<p>An alternative explanation might be that your extruder is struggling with the extrusion rate, and after continuous extrusion is failing to heat the filament fast enough to melt. The layer change could be providing a sufficient respite that walls start off OK on the next layer. Also check (in the G-code) that the speed of walls and infill is the same.</p>

CC BY-SA 3.0
2018-01-24T01:30:07.347Z
The one about temp drop is actually an easy one to check.  If you are correct, diminishing the printing speed should solve it.  Definitively worth a try @Felix-Hauser...
mac
CC BY-SA 3.0
2018-01-26T21:55:45.483Z
I'm already printing at 50 mm/s...
Felix Hauser
CC BY-SA 3.0
2018-01-26T22:24:10.037Z
@FelixHauser that's way to fast to rule out speed related problems. Some filament I needed to drop to 20.
Sean Houlihane
CC BY-SA 3.0
2018-01-20T16:49:32.840Z
2018-01-24T08:12:59.620Z
2018-01-24T08:12:59.620Z
Sean Houlihane
<p>The Prusa Slic3r edition has <a href="http://manual.slic3r.org/expert-mode/fighting-ooze" rel="nofollow noreferrer">specific help references</a> in the manual that may be of value to you. One of the entries that catches my eye is the line marked "Retract on layer change" which appears to be just as you are describing. You've noted that you've disabled all retract settings, perhaps overlooking the check box?</p>

<p>The above linked document also refers to a print setting that prevents retract of filament when not crossing perimeters. This again appears relevant to your difficulties.</p>

<p>Your post says "resulting in the lines of the filament to touching each other." I expect you mean "not touching each other" but I do not wish to correct/edit your post if I am incorrect in this understanding.</p>

CC BY-SA 3.0
2018-01-26T21:57:33.227Z
yes exactly, I meant not touching. All retract settings were off, including layer change.
Felix Hauser
CC BY-SA 3.0
2018-01-20T22:20:16.777Z
2018-01-20T22:20:16.777Z
fred_dot_u
<p>I've have observed that when the printer is finishing a layer, the flow of plastic through the nozzle starts fading out as it comes closer to the point of layer change.</p>

<p>As an example, let's say that I'm printing the first layer of a cube. The nozzle first prints the perimeters ok. Then it begins to print the inner part, beginning from one corner and finishing on the opposite one. As the nozzle comes closer to the finishing corner, the flow of plastic diminishes, resulting in the lines of the filament to touching each other. </p>

<p>Maybe it's not a big deal, but it's annoying because it's stopping the part of having a very nice first layer and finish.</p>

<p>My setup is:</p>

<ul>
<li>Anet A6 running Marlin 1.1.8</li>
<li>Bed auto leveling before each print</li>
<li>Slic3r Prusa Edition, latest release (as of 20 January 2018)</li>
<li>PETG from Das Filament</li>
</ul>

<p>I tried disabling all "retract" settings but the issue persists.</p>

<p>I'm beginning to think that this could be a software bug (Slic3r), but before I submit it to GitHub, I'd like to be sure.</p>

<p>Any opinion is welcome!</p>

CC BY-SA 3.0
2018-01-20T14:39:10.600Z
Does this happen only on the first layer? If so, you have an uneven bed.
Mick
CC BY-SA 3.0
2018-01-20T18:32:59.527Z
The bed is very even
Felix Hauser
CC BY-SA 3.0
2018-01-22T19:56:11.120Z
"Very even" doesn't mean anything.  But more to the point: you should review the Layers View (or whatever Slic3r calls it) to see what the software thinks is being created.
Carl Witthoft
CC BY-SA 3.0
2018-01-22T21:23:31.837Z
@CarlWitthoft - AFAIK slic3r preview does not render filament width to volumetric scale, so underestrusion would not be rendered to screen even if intentional by the slicer...
mac
CC BY-SA 3.0
2018-01-24T23:42:00.047Z
Just curious... have you managed to try out some of the suggestions?  Did you succeed in solving the problem?
mac
CC BY-SA 3.0
2018-01-26T21:54:09.810Z
yes @mac, more or less. I haven't had the time to see all that you guys said because I've been dealing with some other stuff that rendered 3d printing, not on the top-ten of priorities. But I've found a problem with my bed. The glass was not as planar as I thought it to be and also the nozzle height was not as close as I needed it to be. So, for now, by addressing both issues I've been able to get nice first layers again. When the things calm down a bit I want to go step-by-step on everybody's suggestions because I saw a lot of interesting points.
Felix Hauser
<print-quality><marlin><slic3r><pet>
Nozzle reducing flow as it comes close to finish layer
Felix Hauser
# Nozzle reducing flow as it comes close to finish layer

(Asked by: username_0 on 2018-01-20)

I've have observed that when the printer is finishing a layer, the flow of plastic through the nozzle starts fading out as it comes closer to the point of layer change.

As an example, let's say that I'm printing the first layer of a cube. The nozzle first prints the perimeters ok. Then it begins to print the inner part, beginning from one corner and finishing on the opposite one. As the nozzle comes closer to the finishing corner, the flow of plastic diminishes, resulting in the lines of the filament to touching each other.

Maybe it's not a big deal, but it's annoying because it's stopping the part of having a very nice first layer and finish.

My setup is:

* Anet A6 running Marlin 1.1.8
* Bed auto leveling before each print
* Slic3r Prusa Edition, latest release (as of 20 January 2018)
* PETG from Das Filament

I tried disabling all "retract" settings but the issue persists.

I'm beginning to think that this could be a software bug (Slic3r), but before I submit it to GitHub, I'd like to be sure.

Any opinion is welcome!

**Tags:** print-quality, marlin, slic3r, pet
> **Comments:**
> **username_1**: Does this happen only on the first layer? If so, you have an uneven bed.  
> **username_0**: The bed is very even  
> **username_2**: "Very even" doesn't mean anything.  But more to the point: you should review the Layers View (or whatever Slic3r calls it) to see what the software thinks is being created.  
> **username_3**: @CarlWitthoft - AFAIK slic3r preview does not render filament width to volumetric scale, so underestrusion would not be rendered to screen even if intentional by the slicer...  
> **username_3**: Just curious... have you managed to try out some of the suggestions?  Did you succeed in solving the problem?  
> **username_0**: yes @mac, more or less. I haven't had the time to see all that you guys said because I've been dealing with some other stuff that rendered 3d printing, not on the top-ten of priorities. But I've found a problem with my bed. The glass was not as planar as I thought it to be and also the nozzle height was not as close as I needed it to be. So, for now, by addressing both issues I've been able to get nice first layers again. When the things calm down a bit I want to go step-by-step on everybody's suggestions because I saw a lot of interesting points.  

---

## 4 answers

### Answer by username_3 on 2018-01-21. Score: 0 | Accepted answer

The behaviour you are describing (stopping to extrude before the nozzle finish moving) is called **coasting** and is actually a desirable one if tuned correctly (which is clearly not your case).

**Here's a primer on why coasting is good**: the hysteresis (think of it as "springiness") of the filament between the point where the stepper motor pinches it and pushes it towards the nozzle, and the point in which the filament liquefy, makes so that there is always a residual pressure whenever the stepper motor stop spinning. So coasting consists of **stopping to actively extrude *before* the nozzle has reached the endpoint of the line** being "drawn", and relying on the residual pressure to finish the job.

Many slicer have a dedicated setting for this, but - to the best of my knowledge - slic3r PE has not. In your question, you seem to think this may be linked to filament retraction. It is definitively worth trying (why not!) but **filament retraction normally refers to the act of relieving that residual pressure *after* the line being printed is finished and before moving away the nozzle**, so... if that setting turns out to be the key to your problem, then it would be quite a misnomer.

A quick way to verify if this is the case could be **toggling the ceckbox "use firmware retraction"** in the printer/general pane of slic3r settings. If the problem is with the retraction settings you chose, this would ignore them completely. A clean print would confirm your theory.

Failing that, the best way to debug would probably be **to slice the same model with a different slicer** ([cura](https://ultimaker.com/en/products/ultimaker-cura-software) is a common one) and see if the problem persists:

* if it does, then the problem is probably in the firmware or the extruder of the printer itself
* if it does not, then you would have a set of "good settings" in the second slicer that you could try to replicate in Slic3r PE. Or - as you believe it may be the case - you could have found a way to trigger a weird bug in Slic3r.

Good luck and let us know about your findings! :)

> **Comments:**
> **username_0**: whereas I kind of solved the issue in some other fashion, I've looked and some of what you pointed out and, preliminary tests seem promising.  
> **username_4**: This answer is outdated and should be updated to reflect the current state of slicing software and printer firmware.  

---

### Answer by username_4 on 2022-04-26. Score: 1

As mac's answer says, this is **coasting**, but contrary to that answer, **coasting is not good**. At one time (that answer was written way back in 2018 when the state of software was much worse than it is now), it was an idea a number of people accepted as reasonable, but it was operating at the wrong layer, and was a very bad hack, necessarily extruding less material than needed to accurately construct the part being printed. Leading to exactly what OP saw.

Nowadays, printer firmware has a feature called Linear Advance (Marlin) or Pressure Advance (Klipper) that can be calibrated with test prints and compensates for the increased backpressure when extruding fast - or more importantly, seen from the other direction, the reduced backpressure when slowing down at the end of an extrusion path, that results in continued oozing after the extrusion was supposed to end. This feature eliminates the need for hacks that underextrude and produces very accurate extrusion regardless of changes in speed or flow.

Anyone experiencing problems like OP hit should check that their profile does not have coasting (and hacks meant to compensate in the other direction for problems it causes, like "extra prime") enabled in the slicer.


---

### Answer by username_5 on 2018-01-20. Score: 1

If you think it is a slicing problem, look at the G-code. You might want to arrange for the infill to be orthogonal to the axes, but it ought to be easy enough to calculate the ratio between printhead motion and the extruder. G-code is just text, and fairly easy to make sense of. The [RepRap](http://reprap.org/wiki/G-code) wiki has a good reference to the commands, and all you care about are X-Y movement, and E movement.

An alternative explanation might be that your extruder is struggling with the extrusion rate, and after continuous extrusion is failing to heat the filament fast enough to melt. The layer change could be providing a sufficient respite that walls start off OK on the next layer. Also check (in the G-code) that the speed of walls and infill is the same.

> **Comments:**
> **username_3**: The one about temp drop is actually an easy one to check.  If you are correct, diminishing the printing speed should solve it.  Definitively worth a try @Felix-Hauser...  
> **username_0**: I'm already printing at 50 mm/s...  
> **username_5**: @FelixHauser that's way to fast to rule out speed related problems. Some filament I needed to drop to 20.  

---

### Answer by username_6 on 2018-01-20. Score: 0

The Prusa Slic3r edition has [specific help references](http://manual.slic3r.org/expert-mode/fighting-ooze) in the manual that may be of value to you. One of the entries that catches my eye is the line marked "Retract on layer change" which appears to be just as you are describing. You've noted that you've disabled all retract settings, perhaps overlooking the check box?

The above linked document also refers to a print setting that prevents retract of filament when not crossing perimeters. This again appears relevant to your difficulties.

Your post says "resulting in the lines of the filament to touching each other." I expect you mean "not touching each other" but I do not wish to correct/edit your post if I am incorrect in this understanding.

> **Comments:**
> **username_0**: yes exactly, I meant not touching. All retract settings were off, including layer change.  

---

