Perplexing Y-axis shifting problem - only in positive y direction, and only on moves of a very specific radius

Question

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.

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.

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/s², the shifting never happens in the negative y-direction, only in the positive. And even if I lower it to 50 mm/s², 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/s² 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:

Idler:

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.