What is the problem? I still get an occasional random layer shift of 1mm in the Y axis even after curing the majority of my previous layer shifting issues.
What did you already try to solve it?
I’ve been using my Tevo Black Widow for about 6 months. It has the typical add-on corner braces etc. plus a thin glass on top of the bed. I have experienced some layer shifting problems and solved some of them by, for example, discovering a loose belt drive pulley grub screw. But I haven’t completely solved my layer shifting problem. I’ve changed to 2130 drivers with large heat sinks (in Stealthchop mode), changed stepper motors on the X, Y, and Z axis, removed and hard wired some of the stepper motor connectors, replaced the cheap plastic pulleys with good aluminum ones, upgraded the belts, put Locktite on the pulley grub screws, added a dedicated driver cooling duct with a huge radial fan, installed a larger control box cooling fan, etc. I even replaced the printer control board.
I’ve also fiddled with the Vref voltage and I have increased it to the point that an axis will stop presumably because of overheating. I’ve also turned the voltage down to the point where the stepper motors consistently skip steps. At the moment I think I’m OK with the Vref setting. When I touch my stepper motors after hours of printing, I have to hold them a while to determine that they’re barely above room temperature. They’ve never even gotten close to warm, much less hot. I can’t touch the drivers because of the cooling duct, but the duct exhaust air is very cool.
I’ve checked the friction on all the axis. Everything moves smoothly, quietly, and without any significant friction or sticking.
I’ve always used Cura on a Windows 10 desktop in the next room connected to my local WIFI. I send the print file via WIFI to a conventional OctoPrint/Octopi attached to my printer in the next room. The printer/Octopi rig is powered by a large uninterruptible power supply.
I’ve tried reducing speed, acceleration, and jerk settings way down and that, along with my other attempts at fixing the problem, seemed to eliminate the most serious layer shifting. Lately I’ve made some 8-hour prints which were perfect. But then this morning I had another layer shift after printing for only about 30 minutes. In other words, I think my earlier frequent layer shifting problems in both the X and Y axis were caused by overly aggressive software settings along with some solvable hardware problems which I took care of.
Now most prints are essentially perfect but there is still a problem with an occasional layer shift which occurs exclusively in the Y axis. The shifting seems to be completely random with no association with long prints or small parts or difficult moves.
At the moment I’m trying a print directly from an SD card for the first time. I have not tried printing with OctoPrint in the safe mode and I have not tried a slicer other than Cura.
Question: Where does the print data go once it leaves my desktop? Is it stored on the micro SD card in my Octopi or does it pass directly to the SD card in the Tevo Black Widow printer control box? Or perhaps it does something else.
These layer shifts are mostly single shifts of about 1mm and occur in only about 20% of the time. That’s an improvement, but obviously still frustrating especially after printing for 8 or 10 hours.
Could Cura be corrupt and inventing these random, occasional layer shifts?
I’m wondering if a corrupt SD card could be the problem.
Is it possible for the print instructions to become corrupted between the time I send a file out of Cura and the time a stepper motor is commanded to move?
Would a different slicer be worth a try?
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
Octopi 3 B running the current version of Octoprint. Marlin 1,1,8 BLT
First, it would be good to see the part you're talking about. Did layer 17 (ONLY) shift by 1mm in the X direction and then back... or more likely, did the entire part shift 1mm in the X direction at layer 17 and stay there, for example?
Adding a spring to a timing belt is a terrible idea and defeats the purpose of using a timing belt at all. Tensioners work in cars because the belt only goes one way, if you try to put force on the belt the other way, the spring gives, and turns that side of the belt into nothing more than a glorified elastic band.
OP: If you can, move all your axes around slowly by hand, back and forth, and observe where the belts track. I had an issue where my belts would look central when the bed was centered but as it moved to the edges of the axis, the belt would ride on the sides of the pulley guide and stick, causing the motor to skip.
When I touch my stepper motors after hours of printing, I have to hold them a while to determine that they’re barely above room temperature.
Generally a stepper will still work even if it's too hot for human hands, it's the stepper drivers themselves that overheat and shut down.
Is it possible for the print instructions to become corrupted between the time I send a file out of Cura and the time a stepper motor is commanded to move?
It's possible some interference or a dodgy cable can corrupt commands, but I would imagine if that were the case then you'd see it more often. It's also possible a dodgy SD card could store the data incorrectly so anything easily changed should be changed for testing purposes. Try another SD card, try another USB cable, check all your wires going to the motors are tight and properly connected (make sure the power to the printer is off and usb unplugged before touching motor connectors), one of my motor connectors has a dodgy wire that likes to come out so is something I have to watch out for when plugging my motors in.
At the moment I'm making my first print from an SD card. All previous prints have been via wireless Octoprint. Nine hours and forty five minutes of printing at 50 mm/sec and so far so good. So I'm beginning to think I have some intermittent problem somewhere between when the image is sliced by Cura and when the printer Y axis is commanded to move. Of course one instance isn't proof, but I'm running out of other ideas.
To answer the other reply, the layer shift is nearly always a single shift of around 1mm after which the entire remaining part prints OK. In other words, the shift happens and then it stays that way. This has not always been the case, but I've solved those earlier problems. For example, I was getting random shifts in the Y axis, first one way and then later on the other way, always about 2mm or so. I have corner fixtures on my build plate which hold the glass overlay. The securing screws vibrated loose and during most moves the glass would follow the build plate. But during some rapid non-printing movements, the Y axis would jerk quickly enough to make the glass slide to the front stop screws. Then it would print for a while. Later on another violent jerk would cause the glass to slide to the rear stop screws and stay there and print OK. This took me a little while to diagnose, but it was easy to fix especially since it happened during most prints.
My current problem is less frequent so it's harder to troubleshoot.
For now I'm going to do some SD card swapping and checking other possible sources of corruption and/or intermittent connection between my PC and my print head.
If it's only Y-related then we could potentially rule out anything related to serial communications, so it would seem. Otherwise, you'd also see random hiccups in the X dimension of your parts. You should be able to confirm this by several prints from the SD card using the printer's interface.
Ruling out Z-related
If this happened consistently at a particular part height like "always at 20mm high" then this could implicate the Z-axis screw perhaps. But this doesn't sound like the case and can probably also be ruled out.
Ruling out loss of leveling mesh
I recently printed some parts which essentially look like vertically-aligned test tubes. I had to restart the job fairly high at perhaps 80mm. So I had to turn off autoleveling since that would have crashed into the parts. As a result of this, I got a similar characteristic offset like you're seeing. I wouldn't necessarily suggest that loss-of-leveling-mesh is what you're seeing; I'm mostly just listing things that could produce this.
Something is blocking the Y-movement
In the absolute positioning mode for the X/Y/Z steppers (almost always the case), all motors are homed at the beginning of the job usually with a G28 and then the job starts. What would be interesting would be to have you print a small cylindrical part and verify that it has the problem. Next step would be to have something insert a G28 Y0 at the beginning of every layer and see if this fixes it. The assertion here is that something is blocking the Y-dimension progression in such a way that your original homing is now off. Your part then if so would have a single layer that's moved by 1mm and the reset of the part is correct. You could then continue to troubleshoot this as something-is-blocking-the-Y-movement.
Since my last post, I had a Y axis offset of about 1mm using the conventional Octoprint method. Next I printed one 11 hour print directly from the cheap factory SD card and two more lengthy prints from a SanDisk card. The results were perfect.
Next I tried a 4 hour print using Octoprint in Safe mode. After about 2 hours the Y axis lost it's positioning, but rather than just a mm or two, it went wacko by at least 50mm and produced a big hair ball. I stopped the mess and tried to move the Y axis and that's when I found that I couldn't move it closer than about 50mm to one end and it would try to exceed the mechanical limits going the other direction. After issuing a home command, it re-found itself.
I just completed that same print directly from the SD card, and it was perfect.
So now I have about a half dozen instances pointing to something associated with the wireless Octoprint system causing the Y axis to go stupid. This isn't real "proof" of course, but so far the direct-from-SD-card method has been flawless. And the wireless Octoprint method is producing errors 100% of the time.
What does the micro SD card in the Raspberry Pi have to do with this? Do print commands go through the RP card or is it just used for the Octoprint operating system?
What does the SD card in the Tevo control box have to do with printing if using Octoprint? Anything?
I own another Raspberry Pi as well as several other micro and std SD cards. I'd be happy to swap these components if anyone thinks it would help. (well.... not really happy, but I'd do it anyway)
Personally, I think I would switch to the smallest part that will produce the problem and work with that (to minimize my time and filament lost to the cause).
Next, I think I would make sure that the part I'm printing is a cylinder so that I'm not favoring the X axis over the Y in this case.
I might reorient the part in Cura by 90 degrees so that the X and Y are swapped. See if the problem follows the part or follows the printer, if you will.
I'm the type of person who would sit there for a 30-minute print the entire time in a case like this, watching/listening and even doing a webcam of it. I could then rewind the video and see/listen for anything that could be telling.
I think I would add some oil/grease to the Y movement assembly.
That 50mm error is pretty telling. Either something blocked the assembly from moving (then throwing the homing off by this much) or a command that was supposed to go to the printer and be confirmed didn't make it.
I'm not prepared to say I have the problem solved because that, for me at least, would require identifying what the problem actually is. All I can say is that I THINK it has gone away. My latest efforts involve replacing my Raspsberry PI along with formatting the micro SD card and reflashing Octoprint. I disconnected the Y axis belt and rechecked the Y axis movement. It's a dual rail affair of my own design using Hiwin clone cars, one on each corner of the Tevo bed. It's much more stable than the factory single rail and it's very smooth with very low friction.
I've also adjusted the acceleration settings and reduced the print speed slightly. Since then I've made several dozen prints ranging from 40 minutes to 14 hours, all without a layer shift. Perhaps it's a combination of fixes or perhaps it's only one of the changes I made. Unfortunately, the previous layer shift problem was so rare and so random that it was impossible to predict when and if it would occur. Therefor troubleshooting was not easy.
Now, I'll gradually experiment with increasing print speed to see if the layer shifting happens again. If not, then I'll increase the acceleration settings. If that is successful, I'll then conclude it was some kind of fault with either my Raspberry PI or the associated micro SD card data.
