Layer shifting revisited
I have a i3 MK3 upgraded to MK3S with FW 3.9.0. It has worked resonable well together with Octoprint 1.5.3. Now, however, it has started to act up more than usual. Every print, shifts in the X-axis by a couple of random mm. Can be seen several times during a print. It has happened before but very rarely and then mainly in the Y-direction. Now it happens every print. I started by adjusting the tension of the belts and repeated the entire calibration sequence. Lubricated rods with lithium grease, checked cable connections and movements. Upgraded FW to 3.9.3. Still the same problem. If I reduce the speed by 15-20%, there will be fewer problems (do not think 80 mm / sec is very much). Had to sit and look at the printer hour in and hour out to try to see when it happens. I was lucky and heard a muffled bang almost as if it was going against something. As I suspected, X had moved a couple of mm. Looked under the nozzle and saw nothing suspicious, the X / Y sled was far from the end positions so nothing there either.
I'm getting a bit frustrated as I do not know how to tackle the problem. I can imagine some possibilities.
- Octoprint / Firmware. Has caused trouble before in earlier versions.
- Does the processor keep up with the workload?
- Too low power for the X motor or too sensitive backlash setting?
- Too high "jerk" parameter?
- Some claim on various forums that it is the stock power supply indirectly causing it. Any prove to substantiate this?
To test different solutions, can baud rate, motor current, backlash treshold and jerk be set with G or M codes?
I can add that after looking up the related posts here, I can confirm that the fail stats reports that X had a crash together with a filament runout during the last print. Filament runout did not actually happen (false positive). Some says these are known bugs but should have been corrected in 3.9.0 but apparently the filament sensor bug still shows in 3.9.3 which is strange as the upgrade to MK3S was all about fixing this.
Presuming you have checked the smooth rods for damage and the carraige runs smoothly my suspicions are in the pulleys and the belt itself - any damage? Are the idlers OK?
Filament runout did not actually happen (false positive).
A big enough 'bang' could shake the sensor enough to false trigger, deal with this later.
Do you have the octoprint plugin DisplayLayerProgress installed?
If so, try disabling it and see if it helps.
I checked all the mechanics and it looks fine. The belt shows early stages of wear but no cracks or stranding.
Turned off the crash detection and managed to get a two hour Benchy print through without hickups.
Yes, I have.
I will turn it off and try the same print again. I've been thinking about flashing the new OctoPi image made with Python 3 server. I still use the legacy system based on the 2.7 and tidy up all the plugs in there that I don't use. Maybe now is the time to actually do it.
I flashed a new OctoPi 1.5.3 image and added just a couple favorite plug-ins. Octoprint booted up faster, printer runs quieter (to my surprise), server connected faster and file transfers also went faster. Not just subtle but considerable. In the past days I have managed to get three successful relative large prints out with no layer shifting. I conclude that either the Raspberry Pi system was corrupt somehow or I managed to install a few poisonous plugs, or maybe both.
If you experience layer shifting and have an Octoprint setup, It might very well be the cause if the printer hardware otherwise is ok.