Inner walls detaching with Marlin

So first, my printer works great with Skeinforge 45 and Sprinter. But I wanted to get the smooth curves that everyone else brags about with Slic3r and Marlin so I tried that combo out. I am consistently having issues with inner walls detaching and stretching inward any time I print with Marlin, which doesn't seem to be consistent with what other people are getting.

I have Slic3r configured with the exact same speeds and temperatures as Skeinforge (walls at 25 mm/s, infill at 30 mm/s, 180 C) plus native arcs, and all the steps per mm are the same for the two firmwares. I also tried using the Skeinforge generated gcode under Marlin and got even worse results.

I've attached pictures of the same object printed with Sprinter/Skeinforge and Marlin/Slic3r to show the issue. Anyone have any ideas what's going wrong?

Native arcs are having issues if i'm not mistaken (and doesn't buy you much at the 25mm/s you are printing perimeters at)

Try it without arc support and see if that solves the problem perhaps?

---

www.Fablicator.com

The 25 mm/s was just for test to remove any possibility that stability at speed is causing it. But like I said I'm getting the same issues using the exact same Skeinforge generated gcode that worked well on Sprinter.

This may or may not be helpful, but there is a new version of slic3r if you are not already using it

Quote

0.6.0 is out!

Improvements:

much better overlap between infill and perimeters in those situations where previous version was still producing gaps

Heh, I was actually using that version.

I'm unfamiliar with anything but Skeinforge (sfact) and sprinter with pronterface, but I had the exact same problem and unchecked my "clip" button in skeinforge.

I have SFACT installed on two laptops and reverted to the one install that I had never tampered with and found that it wasn't checked. I must have accidentally checked it at some point.

Anyway, I don't know if Slic3r has a similar option, but I'd guess it would. I hope it's that simple for you

I actually have clip enabled on the skeinforge generated print that came out nicely. It really seems like the only changed factor is marlin.

Have you turned on the "advance algorithm" in Marlin ?
Turn it of and try again...

I'm assuming that's triggered by the define ADVANCE? It's commented out in my current Configuration.h. Would it be in my interest to try enabling it?

jsadusk Wrote:
-------------------------------------------------------
> I'm assuming that's triggered by the define
> ADVANCE? It's commented out in my current
> Configuration.h. Would it be in my interest to
> try enabling it?

The Advance feature shouldn't make any difference at lower print speeds (<50mm/s).

I have printed the same exact object with Marlin and had no problems. I could even send you the same gcode that worked on my printer with Marlin.

It's kind of hard to see, but is it really so that the inner perimeters are not attaching to previous layers / adjacent tracks at all and are instead being pulled as bridges? Could it be some sort of a calibration error or something else that has gotten misadjusted? Did you try with Sprinter again after the bad print?

I went back to Sprinter afterward and no prints have had any problems. What appears to be happening with Marlin is that the perimiter threads aren't adhering to the lower layer, and then when they cool they contract inward and make a straight string across the gap. This only happens on concave curves. I had issues like this a long time ago that seemed to be related to low flow rates (filament was being stretched too much), but the identical gcodes should make the flow rates the same. Its almost as if Marlin isn't treating E steps per mm the same way as Sprinter, as I have identical values for each. I shouldn't need to recalibrate that for Marlin, right?

jsadusk Wrote:
-------------------------------------------------------
> I went back to Sprinter afterward and no prints
> have had any problems. What appears to be
> happening with Marlin is that the perimiter
> threads aren't adhering to the lower layer, and
> then when they cool they contract inward and make
> a straight string across the gap. This only
> happens on concave curves. I had issues like this
> a long time ago that seemed to be related to low
> flow rates (filament was being stretched too
> much), but the identical gcodes should make the
> flow rates the same. Its almost as if Marlin
> isn't treating E steps per mm the same way as
> Sprinter, as I have identical values for each. I
> shouldn't need to recalibrate that for Marlin,
> right?


I actually see this myself from time to time with Marlin. It's not really reproducible though.

Check your hot end for dust and lint built up in the filament path. That was what it turned out to be for me.