I'm running a RepRap based ORDBOT Hadron on Repetier firmware version 1.0 that I built from a kit. I've slowly worked out the kinks but this one is an utter doozy.

Basically I occasionally get shifting in the y-axis - the print bed moves on this axis - but only in the positive y direction. Never in the negative y direction. I'm not sure if I'm using those terms correctly, but the bed shifts forwards (negative y), so subsequent print moves are displaced in the positive y direction relative to the rest of the print. I'm calling that a "positive y direction shift".

The offending y-axis is belt-driven by a single NEMA 17 stepper motor. The belt is tight (not too tight I don't think) and well-aligned. It would be difficult for it to become unaligned or lose tension since it runs along a piece of extruded aluminium that is very rigid.

It took a long time to notice the pattern. Some prints don't have the problem, and some prints I simply cannot finish no matter what I do. Finally I found a model that reliably reproduces the problem, on the same move, on about 50% or so of its layers.

This piece is supposed to be straight up & down. Wild.

This piece is supposed to be straight up & down

The moves that cause the shift are on this red line.

The moves that cause the shift are on this red line

The issue seems to only occur on curved moves with a radius of approximately 2-3 mm that point their convex side towards the y-negative direction. Larger or smaller radius moves don't cause the problem. In fact sharp turns don't cause the problem either. Only 2-3 mm radius moves with their convex side towards y-negative produce the issue. No other kind of move causes the problem.

I think the offending move is highlighted here in red, but it might be one of the two moves either side of it. I haven't been able to narrow it down.

Cross-section of print

Also note that there is no opportunity on this part of the G-code for the hotend to snag on the model, and I see no evidence of this when it happens. If it were, I imagine a small model like this would simply dislodge, rather than jamming the y-axis.

I've tried lowering the y-axis acceleration, to the point where you can hear the y-axis spooling up and down as it slowly accelerates to and fro, and the problem remains. What is especially baffling is that if I leave the y-axis acceleration at 300 mm/s2, the shifting never happens in the negative y-direction, only in the positive. And even if I lower it to 50 mm/s2, the shifting still happens towards positive y. So somehow this problem is independent of y-axis acceleration as set in the firmware.

One thing I have noticed, is that even if you can visibly see how slowly the y-axis accelerates, when the problem occurs, the y-axis seems to launch itself into overdrive and whip around that corner as fast as possible, to the point that it overwhelms itself. I'm almost certain the moves that cause the skip are breaking the acceleration limit, but I have no idea what to do about it. It seems like a bug in the firmware, like instead of reducing the acceleration it's increasing the acceleration.

I would guess that somewhere in the code there should be a mathf.abs() around a term, so it slows down the move whether it's positive or negative, but that's pure speculation.

The above paragraphs no longer appear to be true. I changed the y acceleration limit to 50 mm/s2 and the piece printed perfectly. It's possible the firmware update made a difference. I've also enabled EEPROM, so that may have changed something as well. It's also possible that by re-compiling the firmware every time I made a change in the past, I made an error that misled me about the problem. I will try to reproduce the problem and post an answer about it if I manage to, otherwise I may just close the question.

I'm hesitant to say the firmware is the problem because a) I don't know enough to confirm it and b) it makes the solution super difficult: either wait for a solution from the developers, or write it myself. Whilst I could find & write the solution, it would take a lot of work and I'm hoping it's simpler than that.

I've recently upgraded the Repetier firmware from 0.92 to 1.0, and the problem has remained. This also has happened when controlling the printer from Repetier Host, Repetier Server and Octopi, so I'm confident it's not the controller. I'm also using Slic3r.

Here are some photos of the y-axis belt as requested:

Motor: Motor

Idler: Idler

  • $\begingroup$ Also it would be generous to call my phone a potato; perhaps it is a much more primitive form of tuber, if such a thing exists. $\endgroup$ Commented Jun 1, 2018 at 11:03
  • $\begingroup$ how you manage belt tension - could you add a photo of that $\endgroup$
    – profesor79
    Commented Jun 1, 2018 at 11:04
  • $\begingroup$ Added! Also I need a longer comment... ok good. $\endgroup$ Commented Jun 1, 2018 at 11:14
  • $\begingroup$ You could try Cura to slice the model and see if it persists, also you may opt to install Marlin Firmware. Have you tried slowing down printing? $\endgroup$
    – 0scar
    Commented Jun 1, 2018 at 13:05

1 Answer 1


You see this for a few reason. First you are going too fast and you are getting belt shift from the whip lash. You can mitigate that by going slower and adjusting your Jerk settings to lower. Though usually this is not a consistent wall. Usually you see this.

That said it is likely you have not adjusted the current to your stepper motors correctly. I don't know if your system has pololus, but you will want to adjust your current carefully. If you hear thudding from your stepper or the stepper cannot move, you have not done this correctly. Note I've fried many boards adjusting these, make sure to do it with the board unplugged or with a ceramic screw driver. Here is a more complete guide.

A last option is your system has too much friction as Ultimaker points out in their trouble shooting guide. You said your belts are very tight. I wonder if you have them So tight you are actually creating binding. Check to make sure the belts are not rubbing in any way.

Leaning: A leaning print is usually caused by friction causing the print head to move a shorter distance than expected. Make sure that the short belts that connect the stepper motors to the axes do not rub up against the main body of the printer. Similarly make sure that the pulleys on the stepper motors that the belts ride over are not touching the side of the printer. If they are you must move the pulley closer to the stepper motor.

My bet is it's current.

  • $\begingroup$ It does have pololus. I'm still not certain how current explains the behaviour where sharp corners, even at high speed, don't cause this problem, but turns of a specific radius, and only in one direction, do. Also there's the issue of why tweaking acceleration has no effect. However, I haven't touched the drivers since I built the kit, and to be honest I had no idea what I was doing. So rather than sit here and theory-craft about what the problem should be, I'll try tweaking them and let you know how it goes. $\endgroup$ Commented Jun 2, 2018 at 1:18
  • $\begingroup$ I've updated the question - I have found a firmware solution, but I'm trying to reproduce the problem as described - I may have been mistaken about the nature of this problem. $\endgroup$ Commented Jun 2, 2018 at 2:19
  • $\begingroup$ When photos fail videos can be of help. $\endgroup$
    – StarWind0
    Commented Jun 2, 2018 at 7:01
  • $\begingroup$ Okay, the shift-faulter print that I discovered worked up to 150mm/s^2, but another new print failed. So I tried adjusting the pololu, touched the wrong thing, got a spark, and now it's dead. The printer went non-functional completely, but it turned back on after I removed the pololu, so I think that's the only issue. Ordered another one to pick up tomorrow, so we'll see how we go then. The lesson for me here is: don't work when you're tired & frustrated. You make mistakes. We'll see how many more times I need to learn that one... $\endgroup$ Commented Jun 3, 2018 at 4:12
  • 1
    $\begingroup$ Yeaaah I've done that. I've also fried whole boards. That is why I did mention " Note I've fried many boards adjusting these, make sure to do it with the board unplugged or with a ceramic screw driver. Here is a more complete guide." That said I will likely fry boards in the future. Glad you are up and running! $\endgroup$
    – StarWind0
    Commented Jun 4, 2018 at 15:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .