[SOLVED] Marlin reproducibly causing skewed layers

I'm using Marlin, and it rocks! …Generally. Unfortunately, I've run into a reproducible problem: I have a 3 or so hour print, and after a while, the printer abruptly starts printing each layer farther off to the right:



I'm using Replicatorg, and after printing the same model three times (second and third printed with a different gcode file after re-skeining), the same thing happens in the same place at the same time. I've checked out the gcode in Skeinlayer and it's fine; it's definitely not telling the printer to make the mess shown above!

I'll mention at this point that I changed Marlin's baud rate to 115200 to get it to work with Replicatorg. Yeah, yeah, I'm a bad person and all that. I decided to try printing the same gcode file with Pronterface, keeping the 115200 baud rate to see if it was my fiddling with the baud rate or Replicatorg. With Pronterface, it exhibited the exact same problem, albeit it started messing up immediately rather than waiting two hours (how considerate!). I then returned the baud rate to the normal 250000 and printed the same gcode file with Pronterface once again and got the exact same result as when I printed that file at 115200 baud.

I've verified that this isn't a hardware problem. Neither the X motor nor its Pololu driver are overheating (both are actively cooled), there's no drag on the filament, the rods are nice and slick, and furthermore, it happens in the same place every time with each setup!!!

I'm pretty sure I've isolated the problem to a bug in Marlin somewhere. I realize Marlin's experimental but it's awesome and I otherwise love it, so I was hoping a Marlin developer might be able to shed some light on this. Thanks!

Edited 1 time(s). Last edit at 10/30/2011 05:03PM by Pointedstick.

It looks like a HW problem to me. Have you tried printing using another firmware with similar settings?

I'm almost positive it's not a hardware problem. I've done other long-ish prints with Marlin before without trouble (like this one), and I've likewise done many many prints of more than 7 hours with Sprinter in the past. I really don't think the hardware is at fault here, although I'm willing to be proven dramatically wrong. My plan is to print this model out using Sprinter tomorrow and I'm 99.5% sure it will work fine, albeit slower and with small blobs at the corners I'd use the same gcode file but Sprinter really can't handle 52 mm/sec perimeters and 130 mm/sec infill without the machine seeming like it's going to shake itself to pieces.

The bizarre thing is that running with Replicatorg, it shows up after about 2.25 hours with this particular model, while with Pronterface it shows up immediately. But using Replicatorg, I just now used Marlin to print a perfectly nice calibration cube. So if it's a hardware issue, it's a hardware issue that waits patiently until it's in the middle of a long print as long as I'm using Replicatorg.

Edited 1 time(s). Last edit at 10/28/2011 01:02AM by Pointedstick.

The problem seems to be due to the either the x stepper missing steps or the gear slipping when the carriage is towards 0 (left). Perhaps at some point in the print, there's enough plastic that gets in the way of the nozzle when the part starts to warp upwards giving enough extra resistance to result in the motor skipping or gear slippage.

You can see and hear when it's skipping steps though, right? I was watching everything and the X motor seemed totally fine. The pieces weren't warping up. A slipping gear doesn't seem likely either since I have machined pulleys clamped on super-tight to the motors' axles. My belts are both nice and tight, but not too tight.

It sure looks like lost steps. I had to turn down the acceleration a bit from the default after a few prints with Marlin. Come to think of it, I couldn't use the default acceleration in Sprinter either.

I'm not sure a lost step would necessarily be easy to distinguish from the other sounds a RepRap can make while printing, though it is often obvious.

I had a very similar problem once. Many things would print fine and others would fail in exactly the same place. Here's what I found: [sliptonic.com]

The tension on the X belt was such that the other teeth held fine most of the time, but if the acceleration was just right when the gear was turned to the right place, it had enough slack to slip.

sliptonic Wrote:
-------------------------------------------------------
> I had a very similar problem once. Many things
> would print fine and others would fail in exactly
> the same place. Here's what I found:
> [sliptonic.com]
>
> The tension on the X belt was such that the other
> teeth held fine most of the time, but if the
> acceleration was just right when the gear was
> turned to the right place, it had enough slack to
> slip.

Thanks for the idea! It's highly doubtful the belts are slipping off the gears, since I use manufactured 12-tooth pulleys, although I'll watch for that today when I try this print again. It's frustrating to try to regress since shorter prints come out perfectly; it's only this print, and only after more than two hours.

Are you using the latest commit? Someone else I know was using Marlin and had the same issue but it was fixed in the last release Oct 18.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Sublime Wrote:
-------------------------------------------------------
> Are you using the latest commit? Someone else I
> know was using Marlin and had the same issue but
> it was fixed in the last release Oct 18.


Yes, I am.

I think it is a hardware problem, too.

There is probably a small section of infill which just happens to get your machine in a small resonance, every time.

Turn down the acceleration, and it will probably be fine.

The layer offset appears to vary each time, so it is probably isn't software.

---

www.Fablicator.com

So… this is a bit embarrassing. It wasn't a hardware problem! …It also wasn't a firmware problem. The culprit turned out to be that I had made the model too large, so at a certain point, the extruder needed to print outside the printable area and stopped moving. But it thought it had moved that distance, so as a result, its internal sense of where it was got skewed. With each layer that it tried to print outside of the bounds, it got worse. Solution: decrease the size of the model to fit the build platform. D'oh!

so.. marlin handles endstops poorly? still sounds like a firmware bug to me- sprinter does something sensible in this situation

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I just accidentally did the same thing with wrong multiply settings. I really would prefer if touching an end stop was treated as a fatal error such that the print should be aborted without wasting plastic.

I had the same problem with Gen6/Marlin/Sells Mendel/Sfact.

Any print that was larger than the initial base layer would appear to skip steps.
The base layer would start at 0,0 (left corner) and if any layer above it when beyond
that range it would reflect to the opposite side; giving the illusion of it skipping steps.

Any print that was the same or smaller than the base layer was fine.

By using multiply to move the print away from the edges, the issue went away instantly.

W