[BUG] XYZ Shifts randomly

[rocrail]

Please, before you create a new bug report, please make sure you searched in open and closed issues and couldn't find anything that matches.

Printer type - [MK4]

Printer firmware version - [4.7.1]

Original or Custom firmware - [Original]

USB drive

Describe the bug Middle in the print job there are randomly xyz shifts which destroys the object.

How to reproduce It occurs randomly with the same GCODE.

Expected behavior Keep the XYZ positions to match the GCODE

G-code Please attach the G-code you had trouble with. This will make it easier for us to replicate the error.

Crash dump file Please attach the crash dump file. This will make it easier for us to investigate the bug.

Video Please attach a video. It usually helps to solve the problem.

Forum links with pictures: https://forum.prusa3d.com/forum/english-forum-original-prusa-i3-mk4-hardware-firmware-and-software-help/layer-shifts-galore/#post-666492

[shledge]

I would check two things:

• grub screws
• slice new gcode on a different USB stick

[rocrail]

The MK4 is factory assembled and grub screw are tightened. The Original USB Stick, which comes with the MK4 is very slow. The gcode is OK because otherwise it would make at every print the same shift. (PrusaSlicer) I downgraded to firmware 4.7.0 but the 4th print in a row will have this shift. (randomly in which direction xyz) I will reset from now on the MK4 between all print jobs. I'm using Prusa Link for control.

[rocrail]

For me it looks like an out of bound array index which overwrites variables related to the XYZ position. The shift is completely random in all directions.

[murk-sy]

Honestly this looks like bog standards layer shift due to either bad bed adhesion or extreme overhangs (as it seems to be in the photo of a cube in that thread).

1) Ensure you are using the correct sheet for the material 2) Ensure the bed is clean (you can easily see things like greasy areas by looking at light reflections) 3) Verify temperature settings are correct for the material 4) Consider using a brim and Z hop

This is unlikely to be a firmware issue.

[rocrail]

I'm using Prusa PETG and a Satin-Powder-Coated sheet cleaned with Isopropanol 99,9%. The temperatures are the recommended ones from the PrusaSlicer for PETG; No adhesion problems. The print object can only be removed after the sheet has cooled down to room temp. I'm not a novice in 3D Printing, so please do not treat me this way.

The shifts are definitely a firmware bug, but not easy to reproduce. Maybe uploading GCODE by the PrusaSlicer during an active print job could be the cause, but there is no shift after uploading. The next job could get a shift if I do not reset the MK4.

[murk-sy]

I'm glad you verified what I listed above isn't the case. Usually it's best to note the standard troubleshooting you've done since I've seen a lot of standard printing issues reported as firmware problems. Hopefully I didn't come across too crass about it.

To be clear, I have had random layer shift or bizzare movement issues on the Mini (#1793), but those were generally from old gcode that ended up corrupt due to the USB drive. Since the MK4 USB drive is connected to the screen rather than the mainboard, it is possible that that particular cable has intermittent connection issues.

If I understand correctly, after a reset, the first print never has issues? Or do you do a full power off+wait? If you upload the next job during the print, can you verify the gcode has no issues?

[rocrail]

I can only verify the gcode in the PrusaLink Browser which shows small images of the uploaded gcode's. I replaced today the very slow ADATA 16GB stick with a micro SD-Card from Sandisk-Ultra which type I also use for the Raspberry Pi which is 10 times faster when uploading gcode files. But I do not know if this slow USB-Stick which comes with the factory assembled MK4 could be an issue.

And yes: After reset there will be no shift in the print.(sofar...)

[dracoalien007]

I wanted to chime in as I am having the same issues.
Greenhouse Water Clips and water_0.4n_0.2mm_PETG_MK4IS_1h32m.zip

This file is particularly bad. I get no Z shifts, but X and Y are all over. This should be a very simple print. Almost all my prints have been with the supplied USB or an old USB (slow). Belts were correctly tightened as per support instruction, factory built unit.

The firmware doesn't seem to change the behavior, resetting also does not change the behavior. Shifts are random, but occur 100% of the time with this file. Bed adhesion is not an issue. Each individual clip is exactly in the same place as when it started. Images uploaded as well.

[murk-sy]

@dracoalien007 If resetting doesn't change the behaviour, it might not be the same issue. Based on the model gcode you provided, the fillet overhang could also be causing problems even if the print mostly (or fully) stays adhered to the bed. Your photo is actually the one I was looking at when i wrote my first comment for rocrail, I guess I thought he had a different username there since he linked it.

Additionally, rocrail is using stable firmware, not IS. Please check if the issue also happens on 4.7.1 so we can narrow things down. Printing 3-4 clips for each test should probably be fine, and I recommend you check on the print when it reaches the height where you originally had a layer shift - just to make sure the issue isn't caused by curling.

[rocrail]

Maybe the number of files, which increases every day, on the slow USB-Stick will make the stick more slow. I think you must check what happens if reading the data from the stick take more time then the firmware can allow.

[murk-sy]

From my experience with the Mini (300+ files on the stock USB drive), amount and size of files doesn't really affect performance beyond slower file browsing. What I remember causing some issues in the past was regularly deleting files, causing file fragmentation - but it's been a while and I honestly could be remembering completely wrong. It's likely only related to directory listing as well.

[dracoalien007]

@dracoalien007 If resetting doesn't change the behaviour, it might not be the same issue. Based on the model gcode you provided, the fillet overhang could also be causing problems even if the print mostly (or fully) stays adhered to the bed. Your photo is actually the one I was looking at when i wrote my first comment for rocrail, I guess I thought he had a different username there since he linked it.

Additionally, rocrail is using stable firmware, not IS. Please check if the issue also happens on 4.7.1 so we can narrow things down. Printing 3-4 clips for each test should probably be fine, and I recommend you check on the print when it reaches the height where you originally had a layer shift - just to make sure the issue isn't caused by curling.

I appreciate the input. I have tried the print on every imaginable firmware. I probably just uploaded the one most recently on my computer. Fail on all. And none of them fail with only 4 clips.

Call me noob, but what are you talking about with fillet overhangs? These models are flat. There should be no overhangs at all save the overhangs produced as a byproduct of closing the screw holes through the side of the clip. Also, the shifting occurs way before it ever hits the hole.

Does the Code indicate there are overhangs somewhere?

[murk-sy]

I appreciate the input. I have tried the print on every imaginable firmware. I probably just uploaded the one most recently on my computer. Fail on all. And none of them fail with only 4 clips.

Call me noob, but what are you talking about with fillet overhangs? These models are flat. There should be no overhangs at all save the overhangs produced as a byproduct of closing the screw holes through the side of the clip. Also, the shifting occurs way before it ever hits the hole.

Does the Code indicate there are overhangs somewhere?

From your gcode file - red is the current fillet overhang, blue is a more optimal 45° chamfer that should generally be used to guarantee printability. If the issue is what I suspect it to be (specifically curling), cutting off the bottom 0.60mm (or honestly even half that) of the model will resolve it. I believe it is failing at a larger clip amount because the clips cool down sufficiently to cause the axes to skip steps on crash. Other possible solutions are setting a higher fan speed or a fairly high z hop.

[rocrail]

@dracoalien007: Did you also so test with different USB stick?

[rocrail]

@murk-sy: If such tiny overhang will trigger a shift ???? An overhang could lead to a poor print result but certainly not to such a shift.

Pleas take those shifts seriously and check the firmware.

[murk-sy]

The issue is not the overhang itself but the fact that it will curl up. If 4 clips don't fail that means the filament stays hot and malleable enough for the nozzle to just dig through them and bend them out of the way. While the gcode uses 0.20mm z lift, it might not be sufficient.

Regarding your issue specifically:

If it occurs randomly, reproduction is difficult or impossible, so fixing it also difficult or impossible. If you can make the issue reproducible fairly reliably, it's actually something that can be hunted down. Right now there is no guarantee it is actually a firmware issue either.

If it's possible, try reproducing the issue using a benchy or something similar with prusa's filament and default profiles - that removes a lot of variables from the very start. Ideally, also try printing in PLA if you're not already, just so we can rule out any print cooling related issues. If it is a firmware issue, it's unlikely to appear for one material but not for the other.

[dracoalien007]

Ah-I see the filets now. My bad.

I'm printing the same file (ish) on PLA now, same drive. I do find it odd that I have SO MANY shifts occurring after the filet if that's a possible cause. It's a 1.5 hour print, so I'll know soon. After it finishes/fails, I'll print it again. Also, I have a camera on it. We will be able to see if it is "crashing".

This one is going PLA, 0.30 Draft, no changes to slicer (I never change from the default profiles). If it succeeds, I'll switch to 0.20. I'm going 30 to see if it prints. Then, I'll switch to PETG at 30, then 20, then Input Shaper. Then I'll have a lot of evidence to what's happening, or I'll open a business selling low quality irrigation line clips.

I'm glad to stick with this file for now, but this isn't the first time this has happened. I had it happen a few times, including on models that were symmetrical along the Z axis at near completion of the print.

Oh, and in several years of printing with the MK3s, I have never had a single layer shift. Thousands of hours of printing. I've had a share of crashes, but never a layer shift caused by a bad layer adhesion or a crash. Maybe I'm lucky but I had to learn the term "layer shift" to even open the initial topic on the forum.

[jvasileff]

I think @murk-sy might be right. I was very easily able to create Y and X layer shifts by pushing on the heat bed and the extruder while printing. The steppers just lost their position and kept going. I guess the MK4 doesn't have crash detection?

This is very different from my experience with the MK3, which requires a ton of pressure to overcome the torque of the steppers, and even then, prints generally continue fine after crash detection and re-homing.

This was with input shaping.

FWIW - I've had no layer shifts with regular prints so far, including when I tried @dracoalien007's gcode.

[dracoalien007]

I think @murk-sy might be right. I was very easily able to create Y and X layer shifts by pushing on the heat bed and the extruder while printing. The steppers just lost their position and kept going. I guess the MK4 doesn't have crash detection?

This is very different from my experience with the MK3, which requires a ton of pressure to overcome the torque of the steppers, and even then, prints generally continue fine after crash detection and re-homing.

This was with input shaping.

FWIW - I've had no layer shifts with regular prints so far, including when I tried @dracoalien007's gcode.

Wow. That's pretty crazy. It's hard to believe a single clip (likely less than a few grams) is causing such a catastrophic crash that it would shift the entire print head 3cm. On the MK3, it would just stick that sucker to the side of the next object and keep on trucking.

The only thing that doesn't track is why on some large objects (which definitely aren't curling) I get a failure at the very top of the file. One was a 14 hour print. Based on the shift, it looks like it failed right around 13.5 hours. It's the chimney that shifted of the attached file. Desktop.zip

[jvasileff]

Yeah, I'm pretty surprised your water clips gcode would curl & crash. But when there is a collision, there may be a lot more force that it would seem. I've definitely had crashes on my MK3s, just with better recovery.

[jvasileff]

surprised your water clips gcode would curl & crash

Unless... maybe there is a problem with Z? If for whatever reason Z fails to lift when it should, it may drop too low and crash into the part during X or Y movements.

[rocrail]

Fast USB does not do the trick; After reset a print with gcode which printed OK before... About 3mm X right shift... This is a relative small print job and I spotted the shift before more filament was wasted. Firmware: 4.7.1

I relay like the MK4, and I spend a lot of money to get one, but those shifts will force me to revert back to a Chinese printer. :((

So dear developers: Try to fix the firmware. NS2400-top-headtop.gcode.zip

OpenSource or not: The MK4 is a commercial product.

[rocrail]

The PrusaLink(Beta) is always open in the Google Chrome browser. (Does not work with Safari...) Maybe this is a hint.

[ricker24]

I am going in circles having random shifts as well. incredibly frustrating. Prusa does not seem to be able to figure it out either. I suspect the nozzle adapter is not a solid design and causing filament clumps to come out that then cause steppers to lose their home and wreak havoc. Would love to buy the obsidian nozzle (1 Piece) but Prusa hasn't had it in stock in weeks. I've tried different temps per Prusa and no luck. Also tried slicing different times and different drives. Just doesn't add up!

[rocrail]

The Technical Support did ask per Email the Serial numbers of the 4 stepper motors. Maybe we have a bad motor batch.

BTW: Reverted to firmware 4.7.0 (Won't install 4.7.1 again.)

[rocrail]

The 4th print job got a Y shift. It looks like the hot-end collects a lot of filament and after a while it drops the filament. This drop will get hard and at the next layer the stepper motor will hang and causes a shift. The Hot-End get dirty very soon and if enough filament is collected the shift will certainly come...

The filament drop was bigger than you can see on the photo because I tried to save the print job but without success.

Maybe ricker24 has right that the cause is a filament clumb.

[rocrail]

IMHO the stepper motors are fed with a too low voltage to make them silent, but every small obstacle will cause a shift. The Hot-End fan is very loud so to increase the voltage for the steppers will no one notice.

Alternative: Design the Hot-End so that it will not collect filament.

[rocrail]

I added a "Prusa Nextruder Silicone sock" to the Hot-End; Maybe it prevent clumbs.

[zachsa999]

Tuning in here. I started having this issue exactly, but only when I installed rc5. I assumed it has some alpha firmware bug, so I downgraded to 4.7.2. Printing a challenging part and will report back

[zachsa999]

Note: it only does it on the horizontal axis

[zachsa999]

Sorry for the spamming.

I checked the tension on the belts, it appears that the bed axis might be slipping. I tightened it up, but I don't think that fixed it as the problem appears on the gantry axis as well.

[Prusa-Support]

This issue has been silent since last Summer. Major firmware changes occurred shortly after, with the final release of FW 5.0.0 (enabling Input Shaper). Plus, there have been minor further tunings in the axis testing and the motion systems later.

We couldn't reproduce this problem except for hardware/assembly-related reasons. Some of these problems may find a root in the first layer preparation, the belt tensioning, and the presence of obstacles/friction along the axis. Some other side concerns about the USB flash drive interferences and specifically tricky print scenarios mentioned in this thread may also be valid but rather unlikely. These cases may potentially be ruled out by replacing the flash drive and analyzing the specific print with the help of our Customer Support (or comparing the results with other simpler print objects and approved profiles/filaments.

I wonder if the problem persists with the most recent firmware, as the issue may actually be obsolete by now.

Michele Moramarco Prusa Research

[Prusa-Support]

It seems safe to close this issue as stale.

Michele Moramarco Prusa Research