<p>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 <a href="https://www.simplify3d.com/support/print-quality-troubleshooting/#layer-shifting-or-misalignment" rel="nofollow noreferrer">this</a>.</p>

<p>That said it is likely you have not adjusted the current to your stepper motors correctly. I don't know if your system has <a href="https://reprap.org/wiki/Pololu_stepper_driver_board" rel="nofollow noreferrer">pololus</a>, 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. <a href="https://matterhackers.dozuki.com/Guide/Tuning+Motor+Current/37" rel="nofollow noreferrer">Here</a> is a more complete guide.</p>

<p>A last option is your system has too much friction as Ultimaker points out in their trouble shooting <a href="https://support.3dverkstan.se/article/23-a-visual-ultimaker-troubleshooting-guide#leaning" rel="nofollow noreferrer">guide</a>. 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.</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>My bet is it's current.</p>

CC BY-SA 4.0
2018-06-02T01:18:18.700Z
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.
Excrubulent
CC BY-SA 4.0
2018-06-02T02:19:45.263Z
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.
Excrubulent
CC BY-SA 4.0
2018-06-02T07:01:06.683Z
When photos fail videos can be of help.
MakerModder
CC BY-SA 4.0
2018-06-03T04:12:29.987Z
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...
Excrubulent
CC BY-SA 4.0
2018-06-03T04:18:49.310Z
Also, I'm not sure what I would video. I did mention that it seems to speed up when going around this move, but I only remember that from a while ago. When I had the printer sitting on a rickety fold-out table, the whole thing would visibly shake when this move was encountered, but I now have the printer in a dedicated enclosure built into shelves, and it's not as apparent. I don't know if the rickety table only created the impression of a speed-up, or if it was really happening. I've kind of lost track of everything I've tried. I'm hoping a current change will do it; that would be simple.
Excrubulent
CC BY-SA 4.0
2018-06-03T06:39:14.397Z
A quick question about binding:  when you have binding, can you detect it as an increase & decrease in the resistance as you push the axis back & forth?  If so, I know what that feels like, and my bed feels pretty smooth to me.
Excrubulent
CC BY-SA 4.0
2018-06-04T08:05:12.113Z
Replaced the pololu, adjusted the current limiter - 0.8 * 2.5 = 2A, which is what they're rated for with heatsinks & forced airflow, and the NEMAs are rated much higher.  I'm just about to print something, but for now I can say, when I tried to manually push the y-axis after homing, it was very difficult to do.  Prior to this it's been pretty easy, so that's promising.  I take it the y-axis should have a fairly high holding force when the motor is on?  That's something I didn't know.  By the end of tonight I'll have attempted the print again and will let you know.
Excrubulent
CC BY-SA 4.0
2018-06-04T09:11:10.437Z
Aaaand fixed!  Stepper current was the issue.  Thanks a bunch.  That guide was very helpful.  That's an issue that's been bugging me for a long time.
Excrubulent
CC BY-SA 4.0
2018-06-04T15:54:44.753Z
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!
MakerModder
CC BY-SA 4.0
2018-06-01T16:13:16.027Z
2018-06-01T16:13:16.027Z
MakerModder
<p>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.</p>

<p>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".</p>

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

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

<p>This piece is supposed to be straight up &amp; down.  Wild.</p>

<p><a href="https://i.sstatic.net/IlckP.jpg" rel="nofollow noreferrer" title="This piece is supposed to be straight up &amp; down"><img src="https://i.sstatic.net/IlckP.jpg" alt="This piece is supposed to be straight up &amp; down" title="This piece is supposed to be straight up &amp; down"></a></p>

<p>The moves that cause the shift are on this red line.</p>

<p><a href="https://i.sstatic.net/EOUJN.jpg" rel="nofollow noreferrer" title="The moves that cause the shift are on this red line"><img src="https://i.sstatic.net/EOUJN.jpg" alt="The moves that cause the shift are on this red line" title="The moves that cause the shift are on this red line"></a></p>

<p>The issue seems to only occur on curved moves with a radius of approximately 2-3&nbsp;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.  <strong>Only 2-3&nbsp;mm radius moves with their convex side towards y-negative produce the issue.</strong>  No other kind of move causes the problem.</p>

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

<p><a href="https://i.sstatic.net/q1K7s.pnga" rel="nofollow noreferrer" title="Cross-section of print"><img src="https://i.sstatic.net/q1K7s.pnga" alt="Cross-section of print" title="Cross-section of print"></a></p>

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

<p><s>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&nbsp;mm/s<sup>2</sup>, the shifting never happens in the negative y-direction, only in the positive.  And even if I lower it to 50&nbsp;mm/s<sup>2</sup>, the shifting still happens towards positive y.  So somehow this problem is <em>independent</em> of y-axis acceleration as set in the firmware.</p>

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

<p>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.</s></p>

<p><strong>The above paragraphs no longer appear to be true.  I changed the y acceleration limit to 50&nbsp;mm/s<sup>2</sup> 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.</strong></p>

<p>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 &amp; write the solution, it would take a lot of work and I'm hoping it's simpler than that.</p>

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

<p>Here are some photos of the y-axis belt as requested:</p>

<p>Motor:
<a href="https://i.sstatic.net/swVT0.jpg" rel="nofollow noreferrer" title="Motor"><img src="https://i.sstatic.net/swVT0.jpg" alt="Motor" title="Motor"></a></p>

<p>Idler:
<a href="https://i.sstatic.net/eOZUi.jpg" rel="nofollow noreferrer" title="Idler"><img src="https://i.sstatic.net/eOZUi.jpg" alt="Idler" title="Idler"></a></p>

CC BY-SA 4.0
2018-06-01T11:03:05.337Z
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.
Excrubulent
CC BY-SA 4.0
2018-06-01T11:04:32.567Z
how you manage belt tension - could you add a photo of that
profesor79
CC BY-SA 4.0
2018-06-01T11:14:13.330Z
Added! Also I need a longer comment... ok good.
Excrubulent
CC BY-SA 4.0
2018-06-01T13:05:18.547Z
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?
0scar
<reprap><firmware><repetier><troubleshooting>
Perplexing Y-axis shifting problem - only in positive y direction, and only on moves of a very specific radius
Excrubulent
# Perplexing Y-axis shifting problem - only in positive y direction, and only on moves of a very specific radius

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

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](https://i.sstatic.net/IlckP.jpg "This piece is supposed to be straight up & down")](https://i.sstatic.net/IlckP.jpg "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](https://i.sstatic.net/EOUJN.jpg "The moves that cause the shift are on this red line")](https://i.sstatic.net/EOUJN.jpg "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](https://i.sstatic.net/q1K7s.pnga "Cross-section of print")](https://i.sstatic.net/q1K7s.pnga "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](https://i.sstatic.net/swVT0.jpg "Motor")](https://i.sstatic.net/swVT0.jpg "Motor")

Idler:
[![Idler](https://i.sstatic.net/eOZUi.jpg "Idler")](https://i.sstatic.net/eOZUi.jpg "Idler")

**Tags:** reprap, firmware, repetier, troubleshooting
> **Comments:**
> **username_0**: 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.  
> **username_1**: how you manage belt tension - could you add a photo of that  
> **username_0**: Added! Also I need a longer comment... ok good.  
> **username_2**: 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?  

---

## 1 answers

### Answer by username_3 on 2018-06-01. Score: 4 | Accepted answer

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](https://www.simplify3d.com/support/print-quality-troubleshooting/#layer-shifting-or-misalignment).

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](https://reprap.org/wiki/Pololu_stepper_driver_board), 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](https://matterhackers.dozuki.com/Guide/Tuning+Motor+Current/37) is a more complete guide.

A last option is your system has too much friction as Ultimaker points out in their trouble shooting [guide](https://support.3dverkstan.se/article/23-a-visual-ultimaker-troubleshooting-guide#leaning). 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.

> **Comments:**
> **username_0**: 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.  
> **username_0**: 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.  
> **username_3**: When photos fail videos can be of help.  
> **username_0**: 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...  
> **username_0**: Also, I'm not sure what I would video. I did mention that it seems to speed up when going around this move, but I only remember that from a while ago. When I had the printer sitting on a rickety fold-out table, the whole thing would visibly shake when this move was encountered, but I now have the printer in a dedicated enclosure built into shelves, and it's not as apparent. I don't know if the rickety table only created the impression of a speed-up, or if it was really happening. I've kind of lost track of everything I've tried. I'm hoping a current change will do it; that would be simple.  
> **username_0**: A quick question about binding:  when you have binding, can you detect it as an increase & decrease in the resistance as you push the axis back & forth?  If so, I know what that feels like, and my bed feels pretty smooth to me.  
> **username_0**: Replaced the pololu, adjusted the current limiter - 0.8 * 2.5 = 2A, which is what they're rated for with heatsinks & forced airflow, and the NEMAs are rated much higher.  I'm just about to print something, but for now I can say, when I tried to manually push the y-axis after homing, it was very difficult to do.  Prior to this it's been pretty easy, so that's promising.  I take it the y-axis should have a fairly high holding force when the motor is on?  That's something I didn't know.  By the end of tonight I'll have attempted the print again and will let you know.  
> **username_0**: Aaaand fixed!  Stepper current was the issue.  Thanks a bunch.  That guide was very helpful.  That's an issue that's been bugging me for a long time.  
> **username_3**: 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!  

---

