X/Y axis fails to home at random

[shledge]

Printer type - Mk4 assembled

Printer firmware version - 4.6.4

Original or Custom firmware - Original

Optional upgrades - none

USB drive or USB/Octoprint USB

Describe the bug Sometimes the X/Y axis fails to home (it bashes against stop 10-20 times at least when trying to home), leading to the printer to restart and show the equivelent homing error X/Y BSOD. Self test also fails in these instances.

Sometimes power cycling or leaving it for a few hours fixes it, other times adjusting the belt helps for a while. It seems to happen more on the X axis than Y in my case.

It also seems the firmware is rather sensitive about what it expects from the X carriage.

How to reproduce Tricky as it seems to happen at random.

Expected behavior Firmware to perhaps be less strict on what it expects when homing X/Y axis.

[shledge]

Updated to 4.7.0, issue still persists

[shledge]

Replacement x axis motor arrived (due to resonance issues), which seems to have reduced the amount of failures on x axis - however, sometimes it still bashes 8-10 times before it finally homes. I have checked belt tension since installing new motor - belt tension app says its at the correct tension.

Now the motor is ruled out, I'm leaning more on firmware being an issue, or potentially a motor driver issue.

[Bbennyx]

I have exactly the same issue. Factory built Mk4, with steadily getting worse x axis homing. Firmware versions 4.6.2, 4.6.4 and 4.7. X axis homing rams itself into the stop until I get a 'crash detected' warning which the only way out of is to restart the machine, at which point it defaults to the self test which now fails at the x axis homing! The only way I have found to solve the problem is to turn off the printer and leave it for an hour. I have produced some nice prints which testifies to the random nature of the issue and to the magnitude of the frustration. My printer is in the Original Prusa enclosure, which also makes adjustments to the belts and motor very fiddly, but as a layman it certainly does feel like firmware to me.

[bluejakester]

I have the same issue on my completely stock factory assembled MK4. I have not been able to resolve with belt tension and heatbed bearing adjustments as detailed in Prusa Help documents. I'm currently running 4.7.0 firmware.

There is a lengthy discussion by other MK4 users experiencing the issue in this Prusa Support Forum thread.

[mp-se]

My printer fails on the x axis test every time. it crashes and restart as a result. I've spent hours with prusa support without any resolution so far. Yesterday the rep was out of ideas and was happy with the setup and videos I recorded for him. My printer is a new MK4 kit that I got last Friday.

Attached is a dump file from my printer. dump.zip

[Twinsen68]

I had the same problem during 2 week without issue. First see if gear motor are fixed at the right position and belt tensioning correctly. Second use calibration XYZ and force on time extrudeur to stay at left for one time. On mine calibration failed. After when your do next calibration, if the printer doesn't restart and try to calibrate x axis and failed, you will see just before to go on right... extruder tap many time on left Z axis and let a gap between Z left axis just before to go one right. One again at this exact moment i push extrudeur completely on left. It go next on right and achieve calibration. I thing their have a problem in firmware to reinitialize position 0 on X or Z axis.

[n4bft]

The X calibration constantly fails on mine - If i put a slight pressure on the extruder body with my finger towards the X axis motor, it homes correctly every time. I think the firmware is banging the extruder body against the X axis motor end too hard, and it causes it to bounce.

[icepick3000]

Same issue here with both the X and Y axis. I tried the 5.0 firmware but the issue was even worse there so I went back to 4.7.1.

[mp-se]

I found the problem on my printer, it was the x-idler pin that was not pushed in far enough. Its strange how that would cause a different behaviour in the self test

[Claghorn]

Just a random thought from someone waiting for his kit to arrive: What if the firmware were to run the motors a lot slower during the homing process? Heck, it has to heat up the print bed, so it has plenty of time to slowly home.

[xrefusedx]

same thing happens to me at random. mostly on the X. Seems firmware related? Usually if I push down on the belt while its doing it will work. Stock Factory Assembled MK4. Still an issue with 4.7.1

I have tried upgrading my firmware to different versions all the way upto 5.0.0-alpha4 and the X/Y axis fails to home is getting worst and worst. They must not use the MK4 in a farm if we are running into this.

[n4bft]

Just a random thought from someone waiting for his kit to arrive: What if the firmware were to run the motors a lot slower during the homing process? Heck, it has to heat up the print bed, so it has plenty of time to slowly home.

@Claghorn - unfortunatly can't do this. Stallguard, which is what's used to find home, requires a minimum speed for the motor for it to be accurate. It's possible they're running the motors too slowly, or there's something else. I have found when I dampen the vibration of the hotend banging it's head, it behaves better.

[erdnamulb]

I have a factory assembled Mk4 and the homing issue gets worse with every firmware update. No hardware modifications on the printer done. I guess I have to try playing around with belt tensioning now...

[shledge]

4.7.1, still have the issue at random.

[n4bft]

Question, has anyone noticed a particular pattern in the homing related to how many homing cycles have occured since a reset?

[Shushuda]

I had this issue randomly, but pretty rarely. About 90% of the time I had successful 2 bashes per homing. Today I've adjusted the belt, since they always get a bit loose after the first month or so of printing. The Y belt was on the left side of the "just right" scale when I checked, so I decided to tighten it a bit to be closer to the middle. I did a small adjustment and, to my surprise, the belt tuner app showed the belt as more loose instead of tighter. So I tightened it some more and now it shows as perfectly in the middle of the scale, "just right". I've started the printer and... I have a lot more of the Y bashing. Like way more. Yet the belt shows as perfectly tightened, dead center of the scale. I do not understand this. Also, some of the middle bashes seem way more forceful than usual, the "bonk" sound is way louder and it just sounds like something is wrong, like there's too much force used.

So far it seems like the belt needs to be too loose to avoid this issue, which is just wrong. The firmware is way too sensitive and seems to prefer a too loose belt, at least in my case.

[Bbennyx]

So far it seems like the belt needs to be too loose to avoid this issue, which is just wrong. The firmware is way too sensitive and seems to prefer a too loose belt, at least in my case.

Would also explain why retensioning the belt makes no difference. Mine has more or less settled down now, and when it does start to kamikaze into the stop I found that n4bft's solution seems to work. I've not tried it on the y axis though because that seems to sort itself out after 4 or 5 bangs. It's a bit disconcerting that nobody has been assigned to this issue in over a month.

[n4bft]

So, here's the interesting bit. With the belts too lose (85hz) I was getting print quality degredation and I was still getting homing errors fairly often. I then decided to try the other direction, overtightening the X axis to 95hz and the Y axis to 92hz seems to have resolved my homing problems. So far I've had a dozen homes that haven't needed any intervention.

[Shushuda]

This is interesting and further proves the issue lies in the sensitivity of the firmware. In your case a loose belt was increasing banging, in my case a properly tightened belt is increasing banging. Surprisingly enough, only on the Y axis. On X I have a properly tightened belt that I didn't have to retighten since the assembly (while Y had to be touched up once) and I don't remember a single time it had trouble homing. Always just 2 light bangs.

[mshipman]

I have the same issue with my kit MK4. Fortunately, mine has never made it to the crash screen/reboot loop. I have tweaked the belt tension many times and have run firmware 4.6.2, 4.6.1, 5.0.0-alpha3, and 5.0.0-alpha4. I haven't noticed any clear pattern when switching between firmware versions.

When starting a print, the Y and/or X axes bump an extra 2 to 12 times and the homing error message is displayed before eventually homing successfully. The strange thing is that the printer will often home on the first try for 3-4 prints in a row, and then start occasionally bashing again. I have double-checked the bearings, checked for obstructions, etc, etc.

Fortunately it's not a crippling issue for me, as the printer works and prints beautifully... but I have noticed that the occurrence of the issue on the X axis is getting more frequent, which has me concerned. Hopefully this can be fixed in firmware in the near future.

[Royski-noob]

I have the same Y axis homing issue here with my kit-build Mk4. So far it does eventually start printing after a lot of bashing around and error messages but I hope that Prusa can fix this.

[shledge]

On 5.0 RC, it still happens randomly. As much as I've looked into it, there doesn't seem to be any mechanical reason for it.

[coreyward]

+1 — this is happening for me on 5.0.0-alpha-1 with around ~6 "bangs" per occurrence, and happens on ~70% of prints. After upgrading to 5.0.0-RC today, both prints I ran experience the issue with well over 20 bangs each.

At the request of Peter S. (and then Rodolfo) on the Prusa support team, I sent photos of the X and Y axis pulleys and they were confirmed to be in the correct position. Again at their request, I downgraded to 4.7.2 and ran an XYZ test, the results of which were successful (well, the Z axis failed at first since I didn't clean the nozzle on the first run; X and Y succeeded both runs).

Here's a video demonstrating the issue, for reference:

https://github.com/prusa3d/Prusa-Firmware-Buddy/assets/81224/7ba3d3d8-512c-4064-83a0-15d03208d893

Update: I've run several more prints on 5.0.0-RC and they've gotten progressively worse, with the last one failing entirely and showing a screen that says "Length of an axis is too long. Motor current is too low, probably. Retry check, pause or resume the print?" It shows the X-Axis as okay, but the Y-Axis as having failed.

After downgrading to 4.7.2, I still see multiple "bangs" on the Y axis to calibrate. It's not as bad as it is on 5.0.0-RC, but still definitely an issue.

Update 2 — Potential fix: Max at Prusa had me adjust the pulley position on the Y-axis motor, moving it away from the motor a couple millimeters to align with the raised portion of the plastic housing, as shown in the photo below, and that seems to have resolved my issue even in 5.0.0-RC. I guess the difference is that this prevents any rubbing/friction between the pulley and the motor housing that can trigger the stall guard.

[trskinn]

I had a mk4 factory assembled and I'm getting the homing error when i moved from 4.7 to 5.0.1 firmware. It doesn't happen all the time and I'm unsure of what is causing it. So, I have moved back to 4.7 firmware and i'm no longer seeing this issue. I hope a future firmware update will fix this or detailed instructions come out on how to prepare your printer for input shaping firmware. I say this last statement because the homing error says "unable to home the printer - do you want to try again?....try checking belt tension or debris on the axis. Is it possible that the belt must be tuned differently to support input shaping? Just a thought.

[feutl]

same problem with mine, every second print does not start of this :( perhaps these two are related https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3272

[jtaylorreed]

I may have stumbled upon something. I received the mk4 prebuilt and upon setting it up I had issues as above with x-axis homing. At one point while attempting to print again I came across a message that it might be an amperage issue. As I have my printer plugged into a power strip I removed that and plugged it directly into the wall outlet. It has worked flawlessly since. It makes sense that loosening the belt would help as this would reduce the load that the motor must overcome to move the printer head. Just an idea! I hope it helps!

[Mikyner]

The same problem haunts me to this day. 95% of prints start with constant X bumps, Calibration, recalibration etc (sometimes crash detection is also reported). The XY axis test always passes without problems.

[trskinn]

I may have stumbled upon something. I received the mk4 prebuilt and upon setting it up I had issues as above with x-axis homing. At one point while attempting to print again I came across a message that it might be an amperage issue. As I have my printer plugged into a power strip I removed that and plugged it directly into the wall outlet. It has worked flawlessly since. It makes sense that loosening the belt would help as this would reduce the load that the motor must overcome to move the printer head. Just an idea! I hope it helps!

I have not tried going back to 5.0 but when I do, I will try plugging directly into the wall outlet. I would be surprised if this was the case because I run 4.7 with zero issues. I am also reluctant to reduce the belt tension because it works perfectly on 4.7. I would like to hear Prusa come out and acknowledge this requirement when upgrading to 5.0 version.

When I have a down window of not printing anything (not very often), i will attempt these 2 changes and report back. For now, it's more important for it to just work.

[Sebastian1989101]

+1, same issue here. Sometimes it reports failure on the X-axis, sometimes on the Y-axis. Did a recording of the issue here: https://youtu.be/NDHEbcZWi1U

And so far I tried the following:

• Cleaned the printer
• Tighten the belts (they are in the sweet spot for the printed tension meter towards the "max" region)
• Re-lubed the rods
• Re-calibrated (usually successful as you can also see in the video)
• Factory reset the MK4 with re-flashing of the firmware (5.1.2 in my case)
• Different G-Code (including ones that worked before) also re-sliced G-Code with latest PrusaSlicer

It's embarrassing and ridiculous that an error like this remains open for so long and isn't fixed. But at least they push new features with every release instead of fixing what is broken first...

[Prusa-Support]

The axes test has been changed slightly, firmware release after firmware release. A few limit cases of false negatives (due to firmware thresholds) and a few limit cases of false positives (due to minor assembly problems) have been corrected and yet there are chances that there will be further firmware improvements.

However, so far, we could hardly reproduce problems reported in this and other similar issues. No matter how hard we try, there are pretty much always assembly or hardware problems to explain these failures.

As an example, looking at the video above, probably several printer owners may recognize these are not regular printer noises and that would very likely mean there are HW/assembly problems: probably nothing can help at the firmware level in that case. The root of the problem may not be that obvious but our Support must guide you through the final resolution - no matter what.

Some of the most probable causes of axis test failure are probably

• too loose or too tense belt,
• misaligned the idler bearing, or friction opposing its movement (especially the X one if its pin is not fully pushed, and pulled all the way inside),
• inaccurate linear bearing positioning,
• not tight enough or overtightened linear bearing cover/clips (may slip or deform),
• belt or motor pulley misalignment,
• belt slipping inside the belt holder or wobbly belt holder,
• friction on the rods (including dirt, insufficient lubricant, debris, excess lubricant buildups...),
• faulty motors, cracked/deformed parts and more...

Our Customer Support should be able to check these cases in several ways so please, in case of related problems, have our Support help evaluate at least all these basic aspects. Our official Support may be able to confirm if it is the case of the case of a firmware bug too, and possibly address it to me or directly to our developers. https://help.prusa3d.com/article/customer-support_2287

Michele Moramarco Prusa Research

[Sebastian1989101]

@Prusa-Support in my case (so in case of the video), this is a factory assembled MK4. It always did make these noises. And I already contacted the chat support multiple times with this issue, including the video. No solution.

From all the mentioned parts, it should have already be covered by the support except cracked/deformed parts as the printer sits 24/7 in the Prusa Enclosure printing ASA and PC as well so maybe the PETG Parts from this early MK4 batch (got mine shortly after it's release) is at it's limits and I should reprint the plastic parts in ASA (fan shroud is already in PC). However neither a faulty motor or any of the other things got mentioned from chat support yet.

[Claghorn]

For me, everything works perfectly 90% of the time, but then at very rare intervals, the Y axis will slide the bed back and forth a lot before finally deciding it has homed properly. You'd think a hardware or calibration problem wouldn't be so intermittent. But then, I guess you'd think a software problem wouldn't either :-).

[Prusa-Support]

In the case of factory-assembled printers, the warranty is extended to the assembly too - with a few possible exceptions for user manipulations. We must be able to provide a solution or a repair. The case should be carried together with the official Customer Support till the final resolution - AKA the only possible scenario for our Customer Support to actively close a case. Please get back in touch with the Customer Support.

.

Erratic errors on the Y axis this time may actually find an explanation at the hardware level - maybe or rather likely (https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3521). If a linear Y-bearing can even slightly budge, the Y axis test may fail. The front Y linear bearing will basically hit at the front end of the axis, and a short shift of this bearing after the crash may result in soft homing or incorrect axis length. Even visible lubricant buildups may cause soft homing by attracting debris to dampen the movements, or by reaching the outside of the linear bearing thus making it even slightly slippery inside the clip. These are only a few examples so please reach the Customer Support for help inspecting these and more aspects of the axis.

Michele Moramarco Prusa Research

[coreyward]

In the case of factory-assembled printers, the warranty is extended to the assembly too - with a few possible exceptions for user manipulations. We must be able to provide a solution or a repair. The case should be carried together with the official Customer Support till the final resolution - AKA the only possible scenario for our Customer Support to actively close a case. Please get back in touch with the Customer Support.

I have had a lot of issues with my factory-assembled MK4. Support helped solve the worst of this issue, but it took several hours on chat, taking lots of photos and videos, flashing the firmware many times, and making changes/fixes myself.

The last issue I tried to get help with took over 8 hours on chat, and I was disconnected because I had to take 45 minutes to cook and eat dinner (so no resolution). I've instead switched primarily over to using Bambu printers instead because the MK4 is loud, produces extreme artifacts in prints with no clear cause, and has issues homing. The cost of sitting on chat for hours and hours answering the same questions over and over is too expensive—I'd rather write this printer off than spend another thousand dollars in lost opportunity cost diagnosing it.

@Prusa-Support If you are sincere in the desire to honor this warranty on assembly, let me ship my printer to you to have a support tech perform maintenance on, or just replace it with a new one (honestly probably cheaper than hunting down the gremlins in this one). It is clear that there is an issue with the assembly or hardware, as you point out many times in #3521.

If a linear Y-bearing can even slightly budge, the Y axis test may fail. The front Y linear bearing will basically hit at the front end of the axis, and a short shift of this bearing after the crash may result in soft homing or incorrect axis length. Even visible lubricant buildups may cause soft homing by attracting debris to dampen the movements, or by reaching the outside of the linear bearing thus making it even slightly slippery inside the clip.

These sound like hardware bugs to me. The design is simply too sensitive to be so delicate. Not sure what customers are supposed to do about this other than look at other options on the market.

[slentz5678]

I can repeatably generate this problem. I have a plastic enclosure bought off of amazon. If I close it and print ABS with a 110C heatbed, between 3 and 4 hours later, the Y axis will start slamming the heatbed backwards then start printing again in the wrong place. This has happened 4 out of 4 attempts with the enclosure. I'm assuming that this is related to a microcontroller getting too hot and generating errors, and therefore NOT the firmware.

[Mikyner]

I can repeatably generate this problem. I have a plastic enclosure bought off of amazon. If I close it and print ABS with a 110C heatbed, between 3 and 4 hours later, the Y axis will start slamming the heatbed backwards then start printing again in the wrong place. This has happened 4 out of 4 attempts with the enclosure. I'm assuming that this is related to a microcontroller getting too hot and generating errors, and therefore NOT the firmware.

My MK4 sometimes repeatedly hits the X axis even when cold and it is the first print of the day.

[Prusa-Support]

The enclosure could be an interesting point in this rather generic issue. Please make sure not to exceed the operating temperature stated in the handbooks. Namely 38°C for the printer (with the PSU mounted on), and 42°C inside our Enclosure (if the PSU is mounted outside). Please notice that these are the maximum allowed temperatures and not necessarily optimal, so you may want to keep the printer's area rather below these thresholds. High-temp materials will already benefit from gentle cooling in mildly warm air slightly above 30°C.

For the rest, please count on the help of the Customer Support. Our agents will have no peace until a satisfactory solution for each individual case is met, in observation of the terms of the service. We have solutions. The customer's cooperation is the only requirement. 🙂

Michele Moramarco Prusa Research

[Sebastian1989101]

The enclosure could be an interesting point in this rather generic issue. Please make sure not to exceed the operating temperature stated in the handbooks. Namely 38°C for the printer (with the PSU mounted on), and 42°C inside our Enclosure (if the PSU is mounted outside). Please notice that these are the maximum allowed temperatures and not necessarily optimal, so you may want to keep the printer's area rather below these thresholds. High-temp materials will already benefit from gentle cooling in mildly warm air slightly above 30°C.

For the rest, please count on the help of the Customer Support. Our agents will have no peace until a satisfactory solution for each individual case is met, in observation of the terms of the service. We have solutions. The customer's cooperation is the only requirement. 🙂

Michele Moramarco Prusa Research

As my issue primarily happened over the winter where the Prusa enclosure does not exceed 36°C even with extended ASA or PC prints (above 16h), this should not be the issue in my case. Mostly my enclosure sits at 30-32°C with PSU mounted outside. The printer has warmer environments in the summer without the enclosure here…

[shledge]

I haven't had the issue since. I've done the following:

• printed the bottom part of x carriage and fan shroud in PCCF
• retensioned belt (it's rather sensitive to this)

It how works every time, and has done so for several months at this point.

[Shushuda]

Tbh nowadays the only time I have a bit of rehoming is after printing with high temp materials such as ASA or PC. The enclosure reaches 40C for a few hours of printing which is enough to make all metal on the printer expand and shift slightly, which throws the homing calibration off. The rehoming happens when starting a second high temp print in a row and then no more rehoming. After going back to low temp prints it rehomes again, just once. And no more rehomes until I go back to ASA printing. Aside from these moments of metal expansion happening - no rehoming anymore.

Seems fixed on my end as well. But I have no clue when exactly it started to behave.

[Mikyner]

The problem with my X-axis persists even after updating to FW 6.0.0+1479. I recently tried aligning the X-axis pulley so that the entire travel is exactly in the middle of the pulley. For a while that seemed to solve the problem, but today I experienced repeated X-axis bumps again.

[shledge]

You need to make sure the belt isn't too tight, and that the bearings are at the correct orientation. This is more or less what fixed it for me. It's still VERY sensitive to such things, maybe the kit manual should make it clear on where to look if homing fails.

The stiffer PCCF bottom part of the x carriage likely helped too.

[Prusa-Support]

Most basic scenarios are summarized at https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3116#issuecomment-1918045110 but there could be other edge cases where external factors play a role - for example, the working temperature partially covered at https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3116#issuecomment-2033257193 - and I fear some of your cases won't be adequately addressed in this conversation.

There may be more very individual and specific cases that deserve special attention, that probably won't find a solution at the firmware level, and that unfortunately, can't be closely followed case-by-case in a GitHub general issue.

I hope you can find the two linked comments useful. However, for the rest, please follow up on your case one-on-one, with our Customer Support, in official support channels, until a satisfactory and possibly definitive solution is met. https://help.prusa3d.com/article/customer-support_2287

Michele Moramarco Prusa Research

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[github-actions[bot]]

This issue has been closed due to lack of recent activity. Please consider opening a new one if needed.