[BUG] Ghost Y-Axis Crashes

[DFliyerz]

Printer type - MK3S Printer firmware version- 3.8.1

Describe the bug I'm getting repeated "ghost" y-axis crashes when printing models both from the SD card supplied with the printer and models sliced on PrusaSlicer where at similar heights the printer will detect a y-axis crash for seemingly no reason, try to recover, and usually end up slightly offset. I've attached a picture showing two Benchys, one that recovered and was allowed to print further, and one that was cancelled after the crash. Additionally, to the right is a model I sliced in PrusaSlicer, which also crashed and was cancelled.

To Reproduce I tried reproducing the behavior by printing a 20mm tall tower while watching the printer (the crash usually happens between 10-15mm), but the crash didn't occur. I also checked the belts, pulleys, etc. to see if they might have been causing the issue but they all seemed normal.

Expected behavior There doesn't seem to be a reason for these crashes occuring, and even if they are legitimate crashes it shouldn't be recovering with an offset.

[proachaz]

Ok tests have been done. I had a 6 hour print that would start to fail at less than a hour into it. So with the suggestion I put a fan to blow on the EINSY board just on the outside of the case part, not the bed side. I had a 140 mm fan with speed control. I set it rather low so there was always a light breeze on the board case. Then started the print over changing nothing else. The board never got hot in any way. The print did not fail at all, no errors. So to further prove it I started the same print again, and again no problem!! So bigger einsy case here I come. There is no question for me cooling helped. I think I am also going to attach heaksinks’ to all of the stepper motor controller chips and the new case with a fan(more like 40mm not 140mm as in test!). That should chill things down a bit. THANKS for your response and advice!

[koprivajakub]

Having the same issue as well.

I noticed the Y motor is having a bit higher temperature than the X axis motor. I tried the Experimental E-Cool feature, but I guess that impact only the Extruder.

I don't have any heatsink at home to install on the motor, but I am not sure if that would help.

It started recently so I lubricated the Y rods and it helped a bit on earlier model I printed, but recently it started again. The room temperature is ~27deg Celcius. And I was printing Prusament PETG with standard Prusament profile from Prusa Slic3r.

As it starts mid print ~70% I guess it has something to do with the temperature that builds up over the time.

The printer is 2y+ old with Total print time ~61days and ~5km of Filament.

Should I get a new Y axis motor and try to replace it or is this going to be addressed via some FW update?

[proachaz]

I have not had a problem since I started cooling the einsy board. I also thought my y-axis motor was bad. I know you said the area the printer sits is cool. But the board itself gets warm. The trick is not to have the fan blowing on a part while printing, but if you have some way to just cool the board I would try that before a new motor. I started with a plain 120mm fan with speed control, set to low speed, didn't take much. I happened to have one. The idea is get air flow around the board and see if that helps with the errors. The room my printers is warm(30+ degrees celsius), so I was thinking the fan would be of no help. I did find nice heat sync''s that fit the side of the motor and I have those are on both x-axis and y. I did that as more preventative, before the problems start. Cause heat kills! Good luck!!

[jefflongo]

Also started having phantom y-axis crashes since updating to 3.13. I have my printer in an enclosure, when the temp reaches ~30-35C the crashes start. If I leave the enclosure door open, no problem. Temperature seems to be the only contributing variable. I rebuilt the entire y-axis assembly, checked the rods, bearings, etc. Packed the bearings and greased the rods. Still crashes with the enclosure door shut (printing PLA!). This was never an issue before..

[koprivajakub]

I have not had a problem since I started cooling the einsy board...

Fair enough, I will give it a try, but my guts telling me, that this is more a software issue as I read the comments where this suddenly started after an update of FW.

@Prusa-Support I can provide you with a PETG GCode where it constantly happens for me ~1h into the print if that would be any help. I am also keen on testing a RC version as soon as you have some.

[adamdport]

• installed a small fan onto the outside (back of einsy board) of the original prusa einsy case and still reproduced the issue
• installed the big einsy case and without a fan and still reproduced the issue
• installed a small fan into the big einsy case and thus far cannot reproduce the issue, but ambient temperature is now staying around 80ºF in my enclosure, and so this isn't a good datapoint.

I used this fan which included push splices so that I could use the plugs from these sensors to connect to the 5V plug on the EINSY board

Probably worth pointing out that many of us will start to see sudden successes now that ambient temperatures are dropping due to the time of year.

[tideline3d]

I run a farm of 25 printers and since 3.12.2 I've seen this much more often on a few of my printers. I run the exact same gcode hundred of times (small batch manufacturing). We have one print that fails commonly with this problem while other 15+ hour prints on the same machine won't fail at all. That failing print will print hundreds of times on our other machines with no problems. It's two 80mm circles with a flat bridge between them and it fails in the same spot as it come out of the radius towards the flat spot, either front left or back right of the print. There is no crash physically, we've watched it happen live and there's nothing wrong with the print itself.

We've tried turning off crash detection, but they'll still cause issues in the exact same spots. However recently we've tried stealth mode since that controls the steppers slightly differently, and those printers are running beautifully now.

@Prusa-Support is this a sign that the motor itself is slightly out of spec or the stepper driver on the board itself? We'd like to keep our farm all running with the exact same settings on the printers and are willing to replace hardware if necessary to accomplish that.

[Prusa-Support]

There have been several reports about several firmware versions so a new firmware version probably doesn't play a role, especially because there have not been close modifications on the firmware side closely related to this issue (probably for years).

@Escrich Please check if any layer shift occurs with crash detection disabled. If yes, there is a chance that this is a hardware problem: Customer Support can help via the support channels. If not, the layer shift may be a consequence of a fake crash but your printer is specifically affected by "soft homing": there is a chance of layer shift for all print resume processes that imply XY homing (e.g. Power Panic recovery).

@koprivajakub Yes, E-cooling only affects the extruder but the motor temperature is not concerning for the motor itself: if the temperature around the extruder is generally very high low-temp materials may be more likely subject to heat-creep in specific conditions. Probably you don't need to replace the motor as it can even reach 80°C in certain circumstances without posing a problem but they are approved for much higher temperatures.

@proachaz There are a lot of variables that may play a role and heat is among them but you actually made a point: you proved the Einsy cooling to be a winning strategy in your specific case. I hope more users can test that strategy and report back but I suspect it won't work for everyone as heat affects several parts to varying extents.

@tideline3d The motor is not necessarily failing but you can reach Customer Support for suggestions about motor-specific troubleshooting steps and tests (one above all, free the motor and try to feel varying resistance or blockages with your hand). If you notice print issues with crash detection off but printing "slower" helps then we may be looking at a mixture of hardware and print settings complications where reducing the "max volumetric speed" may possibly help.

Michele Moramarco Prusa Research

[circlesmiler]

@tideline3d @Prusa-Support Even if I have to repeat myself, I want to say again that I had success fixing this problem by doing a hardware reset. The problem occurs after a firmware update and was solved after a reset:

https://help.prusa3d.com/article/full-system-refresh-original-prusa-i3_133258

The error was the same as @tideline3d described. The same GCode failed after the update. I updated for the first time with the help of OctoPrint. Not sure, if this is also something that could be a problem.

[ryan-haver]

This continues to plague almost all my prints. I’ve printed a large eisny case and added a fan, but there is no difference.

I’ve had to disable crash detection to get anything to print reliably. This seems to be a firmware issue for me.

@circlesmiler im going to try a hardware reset and hope that it resolves the issue for me, as it has for you. Do you by chance have your printer in an enclosure?

[adamdport]

Even if I have to repeat myself, I want to say again that I had success fixing this problem by doing a hardware reset. The problem occurs after a firmware update and was solved after a reset

I did the hardware reset as described, including the reinstallation of firmware. Just moments ago I was able to reproduce a crash. Resetting does not solve the problem. I'm pretty salty about losing all my print statistics for a non-solution, I had 355 days of print time, almost a full year.

This is after installing the Big Einsy Case and installing a fan to cool it. I think the only other thing it could be is the power supply? I'll see what I can come up with for active cooling of that and report back what I find...

[circlesmiler]

@ryan-haver yes, I have an enclosure.

[numo68]

Even if I have to repeat myself, I want to say again that I had success fixing this problem by doing a hardware reset. The problem occurs after a firmware update and was solved after a reset:

https://help.prusa3d.com/article/full-system-refresh-original-prusa-i3_133258

For the record, neither did the full reset solve it for me. I also don't understand how it could help unless some kind of a crash detection tuning is saved in the NVRAM, which Prusa would surely know.

This is going on for three and a half years and 112 comments. It is clearly temperature-related, be it the motor or something on the board. It might well be some batch of the Trinamic drivers or a batch of motors or a combination of both where the tolerances met badly. If there is any hard- or software setting of the driver threshold specifying what counts as a crash, the setting might be on the edge.

We as the users can discuss for another few years but it would be really good to know what the Prusa developers have to say. Were they able to reproduce the issue? What was tested and did or did not help or at least change things? Is there a test firmware where the threshold can be experimented with? Is there a test g-code that can stress-test things without having to actually print something?

@Prusa-Support are you able to summarize what the state of knowledge is on the Prusa side? Thanks.

[Prusa-Support]

Again this is not related to a specific firmware release, a specific print condition, or a specific hardware component but it is caused by widely different mixed factors.

I can speculate this is mostly hardware-related (ambiental aspects, wear of various parts...) but there might be room for improvements on the firmware side.

Probably, the most closely related aspects are still the same ones listed about one year ago - https://github.com/prusa3d/Prusa-Firmware/issues/2653#issuecomment-1172911201 - and various firmware tweaking and tests have followed since. Replacing bearings & rods or reprinting/reassembling a slightly deformed printed part often helps but we can't exclude a problem of degraded motor or board. A factory rest is definitely a recommended common practice before moving to more advanced troubleshooting steps (including major reassembly or replacement of parts).

The problem is not easily reproducible because, despite the length of this thread, only a small percentage of printers may be affected, and in most cases, they find a solution via hardware replacement or the use of approved print settings (our stock print profiles).

We didn't find an "easy fix" but rest assured we are working on it.

Michele Moramarco Prusa Research

[tideline3d]

@Prusa-Support I have 4-5 printers on my farm affected by this issue now, the printers run hard, about 12-18hr a day, every day for the last couple of years on the same few gcode (date stamp on that gcode is Sep of 2021). We've printed thousands of these without issue across 24 printers. This has grown from 1-2 exhibiting the problem a few months ago, so I assume this is somehow hardware related.

Stealth mode is 100% reliable in resolving the problem for us but NOT just disabling crash detection. [Edit: Disabling crash detection in normal mode will still give failed prints in the same spots (while the print looks perfect in the spot before it fails). This usually manifests as a layer shift. ] We print PETG on .8 nozzle so already fairly slow, stealth mode only slows things down by 5min over an 8 hour print.

I assume the stealth chop is what's actually solving the problem, so we'll eventually replace a motor on one of the affected printers and see if that addresses the problem. Our other theory is it's the stepper driver on the board, but I'm fairly ignorant with the inner workings of that, just seems to be the only two variables left.

I can fairly easily reproduce this issue now if there's any data that could be gleaned from that. Not sure what kind of telemetry can be pulled about the motors, but I'm happy to dig in and pull any debug / memory dumps that might have data. Can also run a known working and known failing one side by side if that would give any better data.

Things we tried that did NOT help

• Factory reset of firmware - failed the next print after this
• Tear down / reassembly of Y axis - failed next print again (did not replace motor)
• Greasing of bearings / rods
• Loosening/tightening Y belt
• Disabling crash detection while still being in normal mode

[adamdport]

@tideline3d I'm confused–you got a ghost y-axis crash after disabling crash detection? That doesn't make sense.

However, I think that you're in a uniquely qualified position to help identify the cause of this issue!! Disabling crash detection for me will shift the problem from ghost y-axis crashes to ghost filament runout detections. For this reason alone I don't think it's motor related. In my opinion the problem stems from either a failing component in the Einsy board or a failing component in the power supply. Could you try swapping power supplies with one of your working machines and see if the crashes follow the power supply? If it doesn't, could you try swapping Einsy boards?

Hate to ask you to do all that work, but again, you're uniquely qualified with your setup...

[tideline3d]

@adamdport apologies, I still get failed prints in the same location but it tends to layer shift at that point. You are right I do not get ghost crashes detections at that point. Stealth mode gets me back to beautiful prints every time.

I do have a number of printers that I've had to turn off the filament sensor due to phantom runouts, I've not connected these two issues together though. You'll see I've commented on that issue as well. That was almost 100% related to a firmware update, I ran two years without that and immediately after updating the farm to 3.12.2 that issue started happening on multiple printers (I updated them all at once).

[tideline3d]

@Prusa-Support I went back into my failed prints bin to pull a few and validate the symptoms. On the prints that fail from this problem, about half of them have a layer shift on the X axis when returning from the crash re-homing sequence.

Is this a case of a false error message, is it actually the X axis that is out of spec? I poked around in the code a bit and see that the bits for X, Y and Filament Runout are all right near each other in the EEPROM. I'm no firmware coder for sure, but this seems like it could be a place for an 'off-by-1' type error? That could possibly explain the phantom filament runout errors as well? In other words could an X axis crash be throwing a Y crash error and a Y crash be throwing a filament runout error or something along those lines? My errors actually seem to be X axis related when I look through the trash pile.

Here's one of my failures, they all look the same I have a dozen or so in the trash pile currently. The extruder is traveling in the direction of the arrow and hits a 'crash' at the blue vertical line. Then when it homes and returns there's a gap and a blob because this is PETG at 250 on a .8 nozzle so there's a lot of leakage while it's rehoming. That shift you see is on the X axis of the print, Y axis is perfectly in line on subsequent layers. Seems to me that it's actually the X axis motor having an issue meanwhile I've been chasing Y axis improvements this whole time.

[tideline3d]

Another update, A4 (the printer from the orange print above) finally failed and it was indeed the Y motor. That motor started sticking when turning like a classic failed stepper motor. We've had a number of E motors go out like this, but the first Y motor to fail for us.

We're replacing the motor today and will watch that printer to see if it improves its symptoms.

Here's some videos of the failed motor

https://github.com/prusa3d/Prusa-Firmware/assets/12903320/496f455d-e5fa-4052-be84-87f8454e6671

https://github.com/prusa3d/Prusa-Firmware/assets/12903320/fb849dd7-93fe-48ed-bffd-b959627391db

[mrkimball288]

We're replacing the motor today and will watch that printer to see if it improves its symptoms.

Any improvements? I am also having issues with temps in an enclosure, it seems. On the chat w/ support now.

[Prusa-Support]

@tideline3d Don't get me wrong, these machines can surprise you when it comes to the initial investment vs. long-term reliability - compared to other non-industry-grade products in this segment. However, that's probably a sign of degraded hardware given your printers' long run. Otherwise, probably there wouldn't be problems in Normal Power mode with Crash Detection disabled.

As pointed out by @adamdport, when you have several printers of the same model, you can take advantage of them by swapping parts between affected and not-affected printers. I know one would rather not mess with other perfectly running printers, but it may be better than "blindly" replacing major HW parts sometimes.

Our Customer Support may help to test and evaluate a possibly damaged motor, but usually, once they start to give up, sooner or later you can simply feel blockage and uneven friction with your fingers (disconnect the motor + untether the belt) if you spin them by hand several times in one direction, and the other.

[EDIT_1] P.S. GitHub won't let me play or download the videos at the moment.

[EDIT_2] Eventually, I managed to display the videos. That's exactly it, a failing motor in all its glory. 🙂 Bad timing, I'm sorry, but you can count on Customer Support 24/7 on the official support channels. https://help.prusa3d.com/article/customer-support_2287

Michele Moramarco Prusa Research

[fitch22]

Not sure if this is the right thread to comment on, or whether I have a different issue. Much of the behavior described above sounds like what I see.

To begin with, I have been using firmware since early 3.x versions for a long time and never had an axis crash. Most recently I have been using 3.12.2 and that works fine. I just updated to 3.13.2 and started getting Y Crashes. Often when the printer does the mesh leveling at the beginning of a print it would detect a crash, re-home, and do another leveling. From there it would randomly detect Y crash throughout the printing, re-home and continue. Sometimes I would have to select YES from the screen to get it to continue. In no cases have I seen any layer shifting, the prints would turn out OK.

I reloaded 3.12.2 and all is working again, no more Y crashes. For me it appears it is 3.13.2 is different somehow.

For what it is worth, my printer is not a stock MK3S. I have different Y axis bearings that cost me a bit of Z height, and I have a Bondtech extruder. With these differences I have had to build my own firmware with the very few numerical differences for build volume and extruder gearing. But up until 3.13.2, I have never seen a crash of any sort.

Is there a way I can help? I don't really want to do a factory reset. I compared the eeprom layout from 3.12.2 to 3.13.2 and it looked like just name changes, but the two memory layouts are compatible.

[fitch22]

Bit the bullet, reloaded 3.13.2 and did full factory reset. Ran the setup wizard, and it made it through xyz cal OK. When it got to calibrating the first layer height I got a Y Crash detected. Besides being the first one I've seen (none using 3.12.2) it goofed up the firmware and some of the menus went missing. I power cycled and got back to where I was.

For now I have disabled crash detection and it appears to be printing fine. I wish someone could point me to the differences in stepper setup between 3.13.2 and 3.12.2, I could probably figure out what is going on. In this thread: https://github.com/prusa3d/Prusa-Firmware/issues/4476 it is mentioned that stepper current might be much less in 3.13.2 since he can move the axis while printing. I would 2nd that as the culprit causing my Y crashes.

[jorgelserve]

For now I have disabled crash detection and it appears to be printing fine. I wish someone could point me to the differences in stepper setup between 3.13.2 and 3.12.2

Here the changes between these two versions https://github.com/prusa3d/Prusa-Firmware/compare/v3.13.2-RC1...v3.13.2

@fitch22

[Prusa-Support]

There shouldn't be inttentional motor-related changes in FW 3.13.2 and we can't confirm the bug described in issue https://github.com/prusa3d/Prusa-Firmware/issues/4476 just yet as we struggle to reproduce the problem. We are sill investigating the issue https://github.com/prusa3d/Prusa-Firmware/issues/4476, however, it is not related to this thread - which is rather older. Please follow the other thread in the separate issue https://github.com/prusa3d/Prusa-Firmware/issues/4476 if the problem only affects FW 3.13.2 - any contribution to help us understand and reproduce the problem is appreciated.

Michele Moramarco Prusa Research

[TheWug]

Hey. I started running into this issue recently. I have observed something interesting: it seems like sometimes my machine encounters a "double crash", that is, it crashes once, then while it's rehoming or returning to where it was, it crashes again. When this happens, it seems to return to the site of the second crash, not the first (which is usually somewhere between home and the original crash, and sometimes at travelling z height, not extruding z height) and immediately begin extruding again, and it will then finish that entire layer at the wrong z level.

Perhaps the print quality issues are some sort of debounce problem caused by multiple detected crashes overwriting the correct post-crash return position with junk?

[3d-gussner]

@TheWug Thanks for the comment. We are testing the fix for this and hopefully can release it as FW 3.13.3. Stay tuned.

[3d-gussner]

If anyone wants to test a development version that solves the Ghost layer shifts, please send me a DM via email.

[3d-gussner]

Please update to FW 3.13.3 and give us some feedback, I would like to close this issue.

[adamdport]

@3d-gussner Not sure about everyone else but it's winter here. My enclosure doesn't reach the ~90ºF mark that causes this issue until at least spring, maybe summer. I haven't had this issue in months but expect to soon.

[3d-gussner]

@adamdport Thanks for the feedback, frankly this issue addresses different Ghost Y-Axis issues.

1. in enclosure
2. with 3.13.2 which has been fixed in https://github.com/prusa3d/Prusa-Firmware/releases/tag/v3.13.3

I hope to get feedback from the users reported the 2nd one.

[fitch22]

Not much for me to report other than I have not seen any axis crashes with the new firmware, but I have not had much to print.

I do have a question you might be able to answer. Since I have a custom printer, I need to build the firmware from source. In the past, I would simply clone the MK3 branch and modify as necessary and then build. I have usually checked to ensure that the MK3 branch and the current version tag represent the same code. However, the current repository the MK3 branch and the MK3_13.3.3 branches are different. My question is, what branch of the repository should I be building from? And as development proceeds with future versions, will the branch MK3_13.3.3 remain static or will it change? In other words, will you create a 13.3.4 branch for development or just keep modifying 13.3.3?

Thanks,

Bill

From: 3d-gussner @.> Sent: Friday, March 8, 2024 1:18 AM To: prusa3d/Prusa-Firmware @.> Cc: fitch22 @.>; Mention @.> Subject: Re: [prusa3d/Prusa-Firmware] [BUG] Ghost Y-Axis Crashes (#2653)

@adamdport https://github.com/adamdport Thanks for the feedback, frankly this issue addresses different Ghost Y-Axis issues.

1. in enclosure
2. with 3.13.2 which has been fixed in https://github.com/prusa3d/Prusa-Firmware/releases/tag/v3.13.3

I hope to get feedback from the users reported the 2nd one.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware/issues/2653#issuecomment-1985333491 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQUGIRLSXGWVUHYQTYP7ILYXF655AVCNFSM4MYHMP7KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJYGUZTGMZUHEYQ . You are receiving this because you were mentioned. https://github.com/notifications/beacon/ACQUGIQNM47MSNCD2H6SWULYXF655A5CNFSM4MYHMP7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOOZK4R4Y.gif Message ID: @. @.> >

[adamdport]

@adamdport Thanks for the feedback, frankly this issue addresses different Ghost Y-Axis issues.

1. in enclosure
2. with 3.13.2 which has been fixed in https://github.com/prusa3d/Prusa-Firmware/releases/tag/v3.13.3

I hope to get feedback from the users reported the 2nd one.

@3d-gussner I disagree that this issue is related to 3.13.2. 3.13.2 didn't come out until October 2023. This issue has been around since May 2020 with the bulk of the comments coming beore 3.13.2 was released. I'm not sure if this is what you intended but it would be very frustrating if you closed this issue after only getting feedback from "the 2nd one".

[Mark-DBA]

A few weeks ago my MK3Ss+ started to make some sort of clicking noise. Not all the time, but only during specific movements and speeds. Last week I got Y-Axis crashes. Disabling the crash detection results in perfect prints. I cleaned and lubricated the smooth rods, checkes belt tension (Y-belt was too tight). In the video you hear the sound. I don't see anything fysical. Anyone an idea what could cause the problem ? With crash detection on I get crashes in every single print, but no layer shifting with crash detection off... the motor is nog hot at all.

https://github.com/prusa3d/Prusa-Firmware/assets/77003816/a97d7fa7-098e-4968-9ab5-8cfb560666cc

[adamdport]

@3d-gussner I finally ended up replacing the Y-axis motor and haven't had a y-axis crash since. I've waited until we've had some warmer temperatures (ie. and warmer enclosure) to make this comment, but have successfully printed maybe 50+ hours in a 95ºF enclosure with no issues. It's hard to say that it's a "faulty" motor since it prints 100% fine in lower temperatures, but the problem does seem to be resolved even in higher temperatures now that I have a different motor installed.

If anyone's replaced their Y motor and still has the issue, please speak up. If you haven't, it may be worth a shot. @Prusa-Support if you're interested in investigating the issue with the motor that was giving me issues, I'd be happy to send it in, please let me know how to do that. Would save a lot of people the time and the $40 plus shipping for a replacement if you could figure out a software workaround...

[charminULTRA]

Also experiencing this

[Mark-DBA]

I replaced the Y-stepper motor by this one : https://www.amazon.com.be/dp/B07MCH5XWF?psc=1&ref=ppx_yo2ov_dt_b_product_details Works fine voor 30% of the price of the original, and my crash problem is solved.

[Prusa-Support]

Yeah. As pointed out in the past - https://github.com/prusa3d/Prusa-Firmware/issues/2653#issuecomment-1768297813 - this issue is oftentimes related to hardware or assembly problems. However, based on observations and speculations over the years, specific ambient and print conditions may matter as well.

We keep studying the phenomenon and improving the firmware in all possible ways. However, would this problem affects your printer, the first suggested step remains to contact our Customer Support for help with hardware and assembly evaluations.

Michele Moramarco Prusa Research

[ScottGibb]

Hi all I seem to be getting a similar problem, in that two things happen. If I run the system with crash detection on, the printer will always crash in the middle and basically wont print anything. If I run it in silent mode the printer will run fine, with the exception if there is a nozzle crash then there will be a skipped layer.

I find if I try to turn on crash detection during the print, the printer will crash and then rehome incorrectly resulting in a layer shift. Again the printer will continue to trigger crash detection and effectively stop printing. I only notice this layer shift if i turn off crash detection when the extruder goes back to printing.

In my journey to solve this, I installed these mods to help with belt tension and installation:

• Y Motor Holder
• Belt Tensioner
• Y axis Belt Holder

However this did not solve my issue at all I also bought this lubrication for the y axis and replaced the bearings:

• Bearings
• lubrication

Print Settings:

• Using Octoprint
• Stock Profiles for PETG
• Firmware 3.13.3
• Printer i3Mk3s+ (Transitioned to Mk3s+ from Mk3s, a year a go)

Ambient Temperature

• Roughly 25 degrees Celsius

An example of the most recent rehoming incident is below:

Any help/suggestions would be really appreciated!

[Escrich]

After yesterday's update, the ghost crashes detection, has been significantly increased