Perplexing Y-axis shifting problem - only in positive y direction, and only on moves of a very specific radius
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/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:
Idler:
how you manage belt tension - could you add a photo of that
Added! Also I need a longer comment... ok good.
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?
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.
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.
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.
When photos fail videos can be of help.
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...
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.
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.
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.
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.
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!
License under CC-BY-SA with attribution
Content dated before 7/24/2021 11:53 AM
Excrubulent 4 years ago
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.