Layer Shifts Galore
Was running Alpha4 but couldn't stand the constant layer shifting. Switched to a stable release thinking it would fix it but alas...
Printing a set of 30 simple irrigation clamps (5 hours on stable so not a huge print) and when I got home at lunch I could see the print had shifted probably around layer 8 along the +X and -Y axis and then again probably another 10 layers up along the +X and +Y axis.
I just got off a 23 hour print with no issues, 2 objects. I have seen layer shifting occur in the same place on repeat prints. This seems to indicate that the machine is not 'losing it's way' but the problem is more software related (which gives me hope). Is the slicer possibly doing something strange?
Does anyone have any suggestions? Very frustrating 😖
RE: Layer Shifts Galore
These are the 3 sitting next to me. I'm running almost a 40% failure rate. However, I printed the same object again, no changes whatsoever, and I got an identical layer shift pattern in the exact same location. Pretty much eliminates belts as a concern.
RE:
If the shifts are always at the identical layer it is probably not the grub screws but it really can't hurt if you have a look at the grub screws of the X and Y motor pulleys and make sure they are properly tightened.
Mk3s MMU2s, Voron 0.1, Voron 2.4
RE: Layer Shifts Galore
For me, I’ve been expert with IS. Only had max 70ms filament till today. Did the same print 3 times, first time way too fast for the filament. Second time tried to use a modifier on the mechanism in place area but the layer shifted right where the mod-box should start. Re-sliced, new stick and no problem.
however I do notice I’m getting a little bit of feedback shake. Will sort that in the morning. One piece came out functional. Printing with high speed tomorrow.
good luck
RE: Layer Shifts Galore
This is the second time a shift of a few cm in the middle of a print job.
The gcode file is OK because the next times there will be no shift.
How can I avoid such destructive shifts?
RE: Layer Shifts Galore
OK, I reverted from 4.7.1 back to 4.7.0...
RE: Layer Shifts Galore
I went through the whole belt tension process. I spoke with support and they said it had to be a belt issue. Y axis was perfect. X axis needed a little tension. Didn't matter. Two prints later and I'm shifting something terrible again. I'm also going to revery to 4.7.0. We'll see if that fixes anything.
RE: Layer Shifts Galore
... This seems to indicate that the machine is not 'losing it's way' but the problem is more software related (which gives me hope). Is the slicer possibly doing something strange?
If it is a software bug, it should be reproducible. Care to share the gcode of a print that fails?
RE: Layer Shifts Galore
I opened a Bug:
https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3173
The revert to 4.7.0 did not fix the problem.
I swapped the very slow ADATA stick, which comes with the MK4, for a SanDisk-Ultra SD-Card with USB adapter.
The gcode upload is at least 10 times faster, and maybe the slow ADATA stick has something todo with this shifting.
Mostly the shift appears on the 4th print job in a row without resetting the MK4...
RE: Layer Shifts Galore
... This seems to indicate that the machine is not 'losing it's way' but the problem is more software related (which gives me hope). Is the slicer possibly doing something strange?
If it is a software bug, it should be reproducible. Care to share the gcode of a print that fails?
A gcode problem I can exclude because the same gcode prints 3 times good and the 4th time with a shift in a random xyz direction.
The gcode is generated with the latest PrusaSlicer software.
RE: Layer Shifts Galore
I think it's interesting that you think it's a USB issue because I kind of do too. I switched to a CRAZY slow USB key and the layer shifting went nuts. Specifically on the attached print. Four tries, four failures. The problem seems to have more to do with the number of objects in the initial setup than it has to do with the complexity of the object (which is why I thought it could be a slicer issue). I'm a noob when it comes to GCode so it's possible that multiple objects would create a larger file than one large object which could create problems on a slow USB. Someone could probably chime in on that.
Also, I've noticed that the PrusaSlicer software is much much slower than it used to be. Definitely not a computer power issue. The program may be poorly optimized for Windows 11 (most stuff seems to be) and my install of 2.6.0 corresponds to my install of Win11 so I wouldn't have seen it until now. One additional thing I've noticed is that once the Gcode is uploaded to the drive, and the 'eject' option opens up on slicer, if you hit it right away, it will always give a "Drive is in use" warning. That NEVER happened in the last several years I've been printing on the MK3. It will eventually eject once it's finished its operations, but the delay is functionally enormous compared to the past.
Anyway, I'm going to try two things. I'm going to try to print this file (because it has a 100% failure rate) from a faster USB. I'm also going to replicate the file and slice on the appimage instead of an installed version of PrusaSlicer (doubt that will do anything but why not). I'll also try an older version of PrusaSlicer.
I also reverted back to running 4.7.0. That did not work so I'm going to put it back to 4.7.1.
RE: Layer Shifts Galore
Software bugs are notorious for not being 100% reproducible.
For example, if the problem is a slow USB stick as you propose, the bug might be improper handling of an empty command buffer. This would be triggered by prints that have a lot of commands in short succession, and may depend on random timing that varies from print to print.
RE:
That would track with my 'multiple separate objects' problem. All my layer shifting seems to happen when either there are a lot of different objects, or the single object in question has a lot of individual output spots that are not interconnected, like, if you were printing something like an open upright box of crayons.
With my attached example, I was printing 30 individual water clips. When I dropped it down to 15, it was about 75% successful. When I dropped it down to 6, it worked fine over and over and over again.
Really leaning on the USB.
RE: Layer Shifts Galore
Did anyone ever figure out the issue? I've been having the exact same issue and I'm on 5.0. Had plenty of great prints and now I can't figure out how to fix this to save my life.
RE: Layer Shifts Galore
This likely has nothing to do with this issue. I don't know much about Prusa printers but I assume they don't use Marlin firmware however I landed here trying to pin this down so I wanted to post the solution that worked for me in case anyone else happens to land here.
I was having layer shifts all over the place suddenly after many year of bulletproof service from my printer. Replaced motors, belts, endstops, controller, stepper drivers, heat sinks and fans on the motors, and probably some other stuff I forgot (this is part of my livelyhood). At one point I noticed a beep immediately before the shift. The notifications said an endstop was triggered with the nozzle in the middle of the bed.
Anyway I eventually found this setting in the firmware:
#define ENDSTOP_NOISE_THRESHOLD 2
Which is commented out by default. I turned it up to 4 and uncommented and so far no more layer shift issues. I don't know why this suddenly started to register endstop pulses but whatever I guess.
RE: Layer Shifts Galore
When loading GCode in the viewer it looks fine, at 22m z the print shifts 10mm to the right. I have lost 1Kg of filament so far trying to solve this. Firmware 5.0, Prusa Slicer 2.6.1, profile .15mm structural (modified support, infill, brim). Now I am thinking it is a memory issue, have not tried reset so far.
RE:
Since I swapped the original USB Stick with a SanDisck Ultra MicroSD and Sandisk mini Adapter, I did not see a shift anymore.
I also added a Prusa Nextruder Silicone socket to avoid clumps.
Firmware: 5.0.1