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!

  • $\begingroup$ Does this happen only on the first layer? If so, you have an uneven bed. $\endgroup$ – Mick Jan 20 '18 at 14:39
  • $\begingroup$ The bed is very even $\endgroup$ – Felix Hauser Jan 20 '18 at 18:32
  • $\begingroup$ "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. $\endgroup$ – Carl Witthoft Jan 22 '18 at 19:56
  • $\begingroup$ @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... $\endgroup$ – mac Jan 22 '18 at 21:23
  • $\begingroup$ Just curious... have you managed to try out some of the suggestions? Did you succeed in solving the problem? $\endgroup$ – mac Jan 24 '18 at 23:42

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 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! :)

  • $\begingroup$ 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. $\endgroup$ – Felix Hauser Jan 26 '18 at 21:59

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 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.

  • 1
    $\begingroup$ 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... $\endgroup$ – mac Jan 24 '18 at 1:30
  • $\begingroup$ I'm already printing at 50 mm/s... $\endgroup$ – Felix Hauser Jan 26 '18 at 21:55
  • $\begingroup$ @FelixHauser that's way to fast to rule out speed related problems. Some filament I needed to drop to 20. $\endgroup$ – Sean Houlihane Jan 26 '18 at 22:24

The Prusa Slic3r edition has specific help references 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.

  • $\begingroup$ yes exactly, I meant not touching. All retract settings were off, including layer change. $\endgroup$ – Felix Hauser Jan 26 '18 at 21:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.