Open DFliyerz opened 4 years ago
On Tue, Jun 29 2021, Jack in TN wrote:
Off topic: Pointer to directions on how to set up to compile Prusa firmware? Thanks.... direct message is ok to jack at coats dot org
The main README should get you started
Hey I've had my prusa mk3s+ running smooth for a few months until recently. I changed the nozzle and moved it into an enclosure in an air conditioned room. I've taken been through most of the prusa help posts and whatever else is out there until finally landing here with you. I've lubed, loosened, re-calibrated, etc. and still getting Y-axis crashes. I've just turned off crash detection for this 16 hour print and its my 6th time printing this piece. I was using PLA and successfully printed this piece over a week ago but since trying PETG(all prusament btw) I've been dealing with these Y-Axis crashes. If this print fails I'll let it cool down completely and try with PLA to compare. I might try 3.10.1-RC1 Firmware. Either way, I'll keep an eye on this thread and try to report anything that may help.
IMO @joeybronzoni's post is more confirmation that it's temperature based. Was fine without an enclosure but in an enclosure he's getting false crashes. Was fine with PLA but with the hotter PETG temperatures he's getting false crashes. Thanks for the datapoint.
Wrapped LMU8 linear bearings on the Y-axis and the heated bed surface in insulation and the Y-crashes have stopped.
Wrapped LMU8 linear bearings on the Y-axis and the heated bed surface in insulation and the Y-crashes have stopped.
Insulation? Help a brutha out? I'm can't visualize what you mean? What kind of insulation? How? Thanks.
Some photos in this link. https://www.reify3d.com/blogs/news/fixing-prusa-i3-mk3s-spurious-y-axis-crashes
Insulation? Help a brutha out? I'm can't visualize what you mean? What kind of insulation? How? Thanks.
I'm 12+ hours into my print that has failed 4 times beforehand with 10's of multiple Y-axis crashes and this print looks great. There are no layer shifts, its a smooth structural print, looks tight. So yea -just pointing out that they seem to me like "ghost crashes" that only occur when too hot and printer is placed inside an enclosure. Hope this info helps. *Also, I'm not so sure I'm at the point of dropping $200 on "rova flex tape" for literally a few small pieces to wrap.
Some photos in this link. https://www.reify3d.com/blogs/news/fixing-prusa-i3-mk3s-spurious-y-axis-crashes
Insulation? Help a brutha out? I'm can't visualize what you mean? What kind of insulation? How? Thanks.
I swear that link was not showing for me last night! I swear it!!!!! Either way, thanks. I'll delete my what seems like the ramblings of a crazy man comment. Thanks.
I am observing the same Y axis crashes. Enclosed MK3S+ running 3.10.0.
I'm experiencing this as well, only discovered it at high temperatures when the enclosure is closed, around 38* or more inside the enclosure. I thought these printers liked to be in warm environments...
Is anyone from Prusa working on this?
~Not at the moment. I've personally never seen the issue on my printers (even when I was using an enclosure), but it's not out of the question that heat could affect the stallGuard for the Y axis. A hotter motor will most likely trigger stallGuard more easily. We could try making the stallguard a tad less sensitive for the Y axis. Here is a build of FW 3.10.1 that has SGT for the Y axis set to 4 instead of 3. Keep in mind I haven't tested this on my printer. FW3101-Build4697 - SGT_Y_4.zip I don't know what else I could try besides playing with this threshold.~
Scrap what I said in the previous comment. There is again interest to improve the Crash detection for firmware 3.12. We've made some changes to the crash detection implementation and we believe it could be more reliable as some edge cases were removed, while also optimizing for code size and speed. The changes regarding Crash detection are as follows for now:
Can anyone who is experiencing the false crashes try these changes? I want to see if using hardware filtering instead of software filtering of the stallGuard signal improves the issue people have with an enclosure. I've tested the changes on my stock MK3S and had no issues whatsoever and I'm curious if it improves the situation at all for the users who have issues with an enclosure (I don't have one anymore unfortunately). Here are the builds: FW3101-Build4697-MK3_crashDet_test-787b4749b470ed18ce000fe10b8161c72506739a.zip. A note of warning: The MK3 branch is very experimental at the moment. A lot of changes have happened in the past week and there might be some new bugs. I haven't had issues with the few prints I tried myself, but don't leave the printer unattended if you try these builds.
Scrap what I said in the previous comment. There is again interest to improve the Crash detection for firmware 3.12. We've made some changes to the crash detection implementation and we believe it could be more reliable as some edge cases were removed, while also optimizing for code size and speed. The changes regarding Crash detection are as follows for now:
- Use SFILT in the drivers instead of filtering the stall signal (SG) in software by the stepper interrupt. It should fix bugs for people that use a different microstepping resolution (the filtering is no longer hardcoded to x16). Improved the filtering at >=100mm/s (double stepping) and >=200mm/s (quad stepping). Improved filtering when multiple steppers are moving simultaneously, but one is moving slower than the other. Less load on the stepper ISR.
- Show what axis triggered the crash on the status screen (so instead of "Crash detected" it will say "Y Crash detected". Same goes for the screen which asks you whether to continue printing after 3 consecutive crashes.
Can anyone who is experiencing the false crashes try these changes? I want to see if using hardware filtering instead of software filtering of the stallGuard signal improves the issue people have with an enclosure. I've tested the changes on my stock MK3S and had no issues whatsoever and I'm curious if it improves the situation at all for the users who have issues with an enclosure (I don't have one anymore unfortunately). Here are the builds: FW3101-Build4697-MK3_crashDet_test-787b4749b470ed18ce000fe10b8161c72506739a.zip. A note of warning: The MK3 branch is very experimental at the moment. A lot of changes have happened in the past week and there might be some new bugs. I haven't had issues with the few prints I tried myself, but don't leave the printer unattended if you try these builds.
Yea thanks @leptun I can this weekend. I was dealing with some issues & crashes on one of my MK3S machines with the y-axis. I'll try to get that installed tonight or at least by tomorrow and I'll run some prints over the weekend. Looking forward to it. *I can't stop thinking about the Prusa XL....
@joeybronzoni Any update on the issue?
@leptun I just sent you an email. Check it out and I'll update you ASAP.
Running a print now! fingers crossed. Its a 26 hour print. TBC... ... ...
Yea, eh. The print failed on the first attempt. Not crash related. Second attempt 2 Y-axis crashes detected and had to stop print. Its 100% infill printing an AR-lower receiver. https://odysee.com/@hoffmantactical:3/Hoffman-Tactical-AR-15-Super-Lower:4 With prints like this I've let crash and continue the print ends up off 15-20 hours in and by the time it finishes it's not structurally sound enough to be used. I've had these print perfect on the prusa-mini+. I've dealt with the MK3S+ Y crashes for a while now in this enclosure. I've tested the belt tension and bearings previously. I'm running it on stealth mode now and I'll see if the print runs fine to completion. I'll be back in 26hr. In the meantime I found this and will eventually test this. Just not today. Big if works though. https://www.thingiverse.com/thing:3601879/files
Ouf. That's disappointing to hear. Did it make the situation worse than before or is it kinda the same? Stealth mode doesn't have crash detection, so it will not trigger any crashes. I'm sure that one will succeed unless some other issue happens. Can you please also post the gcode that you are using? I'd like to see the settings used. Maybe there is some weird setting that's causing issues.
Super-AR-15-Lower-V3.0.STL-crash-test-WITH-Support_0.15mm_PETG_MK3SMMU2S_1d2h50m.ZIP
Ah right the detection is off -my brain shutoff there. Eh. Here's the gcode. I will add that MK3 Y Axis Shift After Crash Detection 2 minute Fix tomorrow morn with detection on. @leptun but is it better or worse? Well it looked and felt more smooth of a print. I honesty was excited and thought for sure it was going to run without crash.
I ran some prints with the "quick fix" from: https://www.thingiverse.com/thing:3601879/files and I still get the crashes I have a new y-xis motor coming and I'm going to pop that in. Not that this will really help but I want to at least check that off the list. I hope someone else can chime in and test this firmware as well for confirmation.
@leptun Maybe I was wrong. So after struggling with issues with both MMU2S/MK3S+ printers I had enough. I stripped down a majority of the components and while continuing to search the forums. Here's what I found. 1) I may have had my rods too tight on the Y axis. After adjusting that and running some prints(and after the major weekend of disassembling & reassembling everything except I did not remove the bars from the body) I have a print running that will take 20+ hours. So far so good, I'd have a handful of crashes by now. So I was wrong and the firmware so far seems to be just fine while in the enclosure. But we'll see. I will report back after the print. I think this is going to be good.
@leptun If you have any updated firmware, I can try it out. I'm currently printing with ABS+ and ASA with MK3S+ & MMU2S in an Ikea Lack Enclosure and having Y-axis crashes all the time, altough I have just verified my Y-axis bearings (switched to misumi from the original nonames) and done the proper greasing ---> no change. The only way to get prints done with ABS/ASA and closed enclosure is to disable crash detection --> everything works just fine. I am using the currently latest firmware 3.10.1
If I can help getting the Y-axis ghost crashes fixed, I'll do it.
This has worked for me. I am located in Mexico. I print in an IKEA enclosure in a room that frequently reaches 28 C. My enclosure has a temp controlled fan and I do not allow the enclosure temperature to reach more than 33.5 C. (Lower bed temp accordingly or open door a little) 1. Got rid of bearings and changed them for plastic bushings (printer runs quieter and the y axis is easier to move. No erosion on rods), but still got many Y axis crashes. 2. Even when printing PLA with bed temp 50 I preheat the printer for a while at 85C bed temp before printing. This allows everything to expand. As temperature increases so does the bed height. I never print when the bed reaches print temperature. I wait until the enclosure warms up. If in doubt when the bed is stable you can use Pointerface (G80 and G81 commands). Use live Z adjustment if you get crashes in the first layers, this means the bed is still expanding. From the second later onward I decrease Z (increase separation from print) about 60 points. 3. Reading this blog found that spool holder friction may also increase ghost crashes. I was printing off a drier box…Now I moved back to the original Prusa spool holder. 4. I have reduced the acceleration to 600 in my last prints. I do not know if this helps, but the number of crashes has been greatly reduced by doing all of the above.
Thank you all for participating to this thread.
After a quick review I seemed to notice that the most frequently mentioned concerns are:
In fact, in some cases, printing in low temperature conditions (open enclosure), replacing the rods/bars helped or re-assembling some components helped.
This thread was created before the release of model MK3S+, where the U-bolts mountings for Y-linear-bearings were abandoned and substituted by metal-sheet-clips, which provide a gente grip on a larger larger surface while being more flexible. I wonder how many are the cases of frequent crashes in not so hot ambient temperatures (substantially below 30°C) for MK3S+ models. Please mind that:
If you happen to experience crashes in above conditions, I would suggest getting in touch with the Customer Tech Support for help. https://help.prusa3d.com/article/customer-support_2287
. This said, it is a fact that the StallGuard could be more sensitive when the ambient (and the motors) are at high temperature. 1) I'm wondering if @leptun's modified firmware was tested in stable high-temperature conditions. The motor temperature may also vary according to its use, so that the temperature conditions may deserve further study). 2) I'm wondering if the StallGuard modifications only concerns the Y-axis (so that we won't be looking at crashes on the other axis, which otherwise works fine). 3) I'm wondering if we are able to define a certain temperature threshold that increases the number of crashes, and if the StallGuard sensitivenes could ramp according to the ambient temperature.
Michele Moramarco Prusa Research
@Prusa-Support I appreciate you keeping an eye on this thread. To summarize your suggestions:
My responses:
From what I can tell, this issue is entirely dependent on motor temperature, as this never affects the first print–it only becomes an issue for me after printing in an (unheated) enclosure after several hours of printing.
Thanks again.
Edit: Yes, I emailed support about it in May 2020 and they told me to turn off crash detection :(
crash detections can in some rare cases be dependent on the geometry of the model, you can simply turn it off, if you are not experiencing any layer shifts
Your feedback is most valuable. Thanks for it. We are actively investigating this and trying to reproduce the error. The Prusa Enclosure should offer more testing scenarios and expedite our research in these regards.
By the way, based on the initial tests on the Prusa Enclosure, we recommend not exceeding ≈40°C as the ambient temperature around the operating printer - please keep the temperature rather lower in the case of custom enclosures with enclosed PSU. [this information is based on our manuals]
Rest ensured, we are working on this.
Michele Moramarco Prusa Research
Hi, I had the same issues reported here. I turned off the crash detection, but that was obviously just a temporary solution to be able to keep printing. Finally, I replaced the y-axis motor, turned back on the crash detection, and now it works fine.
PS: I have an Original Prusa i3 MK3S+ kit, purchased and assembled a month ago
Further testing in my case reveals it is indeed temperature related. The enclosure heats up above ambient temperature 10C+. I now wait until the enclosure has a stable temperature, some times around 35C or higher depending on bed temp, calibrate first layer, and start printing with no issues.
Thanks for your feedback. In recent times we improved our feedback data collection about this aspect. Ambient temperature, stepper motors, and rods/bearings are so far the most likely related to the issue, in spite of being within specifics. Sometimes the cause is a mixture of factors including belt tension, print settings, the lubrification process, and more...
We are confident enough that as long as the hardware is within the specifics and the printer is used in "normal" conditions (as per the manual) this will be solved via firmware fine-tuning. Meantime, we'll keep on testing and collecting feedback
Michele Moramarco Prusa Research
Not sure if it helps, but I'm leaving this here. I've started to have multiple Y crashes on my mk3s+ since 2 months or so, the thing was random, or at least I wasn't able to figure out the reason. I don't have an enclosure and I keep it in my living room, so normal temperatures @ 22C. This bugged me a lot so I decided to disassemble it and perform a thorough inspection. After I discovered that one of the Y rods is scratched, I have decided to replace multiple things as the printer is quite old - both Y rods, added Misumi bearings everywhere, new belts, SuperLube and a new nozzle. I was under the impression that the Y crashes went away after this maintenance but hell I was wrong... I managed to reproduce the crashes three times in a row with the same print and after I did some research on the internet I did a couple of things: I've sprayed some PTFE lube near Y motor rod, hopefully this lubricated it a bit and secondly I've sticked 2 heatsinks to the motor. It's hard to believe but now I'm into the second print without any crashes...I'm going to monitor this however and see how the printer behaves. I can only make a few assumptions for my case: -this is/was a temperature related issue with the Y motor; -was solved (at least temporary) by adding the heatsinks to the motor; -I also think that lubing the motor helped a bit as there is less friction, hence lower temperature overall; -another thing I was thinking about - the model I was trying to print was small and positioned on the front side of the bed, close to the end, not positioned in the mid as PrusaSlicer usually arranges it. This made the rest of the bed to cover the Y motor, being on top of it and it might be that the motor couldn't cool properly... -the model is the LOTR ring, I tend to believe that the round geometry and the inscription on the ring is stressing the motors in a harsher way and they run at higher temperatures compared with a simple rectangular box for example. I hope that this makes sense. I`ll try to keep you updated in case my mk3s Y motor starts to crash again, but for now I hope that my findings will be helping some folks.
Thanks for your precious feedback. I personally believe that all the listed aspects are almost equally important. In fact, as mentioned above, ghost collisions could occur due to a mixture of factors even if each single hardware piece is within specs. The worn smooth rods may have caused increased strain on the motor in the first place and may have partially led to further complications. An optimal tweaking of certain parameters in the firmware may help in the future. Until then, there could be several aspects to improve in the printer and printing conditions.
By the way, I believe that rounded shapes may stress the motor in a way that the X and Y motors are constantly stressed in all ranges of speeds in a sinusoidal pattern. What I believe stresses a stepper motor the most is small micro-stepping in the first place, and low speeds, where the stepper motor is constantly crossed by the current to hold the micro-steps for longer periods. I'm just speculating though.
We are taking notes and keeping up the investigation. Thank you again.
Michele Moramarco Prusa Research
FWIW I am also having y-axis crashes (resulting in layer shifting) on my stock MK3S+ in a Prusa Enclosure. It seems heat related. I never have an issue when printing with the enclosure doors open and the issue seems worse when printing ASA vs PETG - which I assume is due to the higher bed and nozzle temps required and therefore it reaching the "fail" temperature faster.
The crashes start happening when the enclosure temperature reaches about 33C and the ambient temperature as reported by the Einsy board reaches 55C - both which are within range based on the Prusa docs.
Like others, turning off crash detection also "fixes" the issue. I also added heatsinks to the TMC motor drivers based on feedback from Prusa support that they might be overheating but that didn't have any effect.
I haven't tried a heatsink on the motor yet and that will probably be my next step.
FWIW, I have just assembled an enclosure from PrinterBox with some mods and started getting these phantom Y axis crashes as well. It might well be that indeed round objects cause it, it definitely was the case for the one right now (I heard the autohoming bang), but I only found this thread now so I did not really pay attention. For now I have disabled the detection.
I am printing PETG with the stock profile (250/90). The firmware is 3.12.1. It is a bit hard to guess the temperature in various parts of the enclosure as messing with it immediately changes things but it is about 33-35 C around the Einsy and 38-40 max on the top of the enclosure where all the hot air goes. There is a temperature controller switching fans on. The Einsy has an own cooling duct bringing cool air from the outside (no idea how effective that is though, probably not much).
The Y motor is pretty warm to touch but not hot (50 C max). I could fix a temp probe there if it helps investigating but I am pretty sure that this will be reproducible with Prusa enclosure in their lab as well for at least some printers.
We have reason to believe that heat plays a role, and rounded shapes are more likely affected (based on the mere speculation explained above). Of course, though, that may not be all.
Thank you for keeping precious feedback coming.
Has anybody tried e-cool mode? That'd be experimental but it was successfully tested on original Prusa Research stepper motors. Honestly, I'm not sure if the feature significantly lowers the temperature on all motors, I think it only affects the Extruder Motor. Again please notice this feature would be for experimental use: results are not guaranteed.
Michele Moramarco Prusa Research
Has anybody tried e-cool mode?
I tried turning that on this weekend and still got the y-axis crashes.
I tried, it doesn't seem to work.
Sent from Outlook for iOShttps://aka.ms/o0ukef
From: ufodone @.> Sent: Monday, March 6, 2023 5:58:58 PM To: prusa3d/Prusa-Firmware @.> Cc: pvcata @.>; Comment @.> Subject: Re: [prusa3d/Prusa-Firmware] [BUG] Ghost Y-Axis Crashes (#2653)
Has anybody tried e-cool modehttps://help.prusa3d.com/article/experimental-menu-mk3-s-_161213#e-cool-mode?
I tried turning that on this weekend and still got the y-axis crashes.
— Reply to this email directly, view it on GitHubhttps://github.com/prusa3d/Prusa-Firmware/issues/2653#issuecomment-1456520976, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APITOBS3Z24HAWN3PHNMBCLW2YJVFANCNFSM4MYHMP7A. You are receiving this because you commented.Message ID: @.***>
Thanks for it. We keep investigating.
Michele Moramarco Prusa Research
I have today experienced the "phantom crash" for the first time during gyroid infill when printing Prusa PC Blend on my MK3S in an enclosure at about 37 C T_amb. Also suspecting high ambient temperature affecting the hall effect sensing for the crash.
That said I've been pushing my poor printer very hard, running off 3½ spools of PC Blend, printing non-stop for a week and a half, maybe he just needed a break 😂
I could solve this kind of problem (crash detection problem, "Wrong Y axis length") by doing a factory reset. I think because of some firmware updates and maybe old preferences that are not compatible, the problem occurs.
Hello Guys
I faced this issue on my prusa MK3s printer a few month ago. It is still in factory condictin with no modifications except i built a case out of plexiglass around it. The printer runs now for more than 2 years and i printed around 90d 23h hours. I did not make an effort to check the bearings in detail on the y-axis but the belt tensions and sliding of the print bed seems also be ok,
What i did is, i attached a temperature sensor on the side of the y-axis Nema17 stepper motor as shown in the attached picture. It is just a simple temperature sensor with an 7-segment display and not so professional or accurate.
I log the temperature during some of my prints with PLA and PETG, and as soon as the temerature on the sensor rises on around 43.3° C the ghost crash took place. This happens also when the housing was open when i printed with PETG.
For test purposes i put a fan with a blow hose in the housing to blow more or less directly to the y-axis motor like this:
And now i could hold the temperature, of course with open housing, at maximum around 36 °C and no crashes happens.
Maybe there is a defective Nema 17 stepper motor on my printers y-axis? I have the feeling the other stepper motors get also hot and have no issue in this temperature ranges.
Kind Regards
Thanks for keeping on reporting.
These motors are proven for very high temperatures so temperatures may not be a concern for the motor itself. We can't exclude high temperatures from being a cause of matter expansion, and cause misalignment and rubbing between parts as a consequence. We can't confidently say if the temperature affects the motor failure negatively or affects negatively anything else (but the motor). As of now, a very small percentage of printers are possibly affected by this problem and we keep investigating, but the temperature is not necessarily the main cause of the issue either (unconfirmed). The most frequent causes seem to be the belt tension or friction on the rods/bearings.
. @beelercoding Thanks for the pictures. In your specific case, the Y-motor pulley is very close to the motor body and I don't want temperature expansion to reduce the already negligible gap between the motor and pulley. No gap will cause friction opposing the motor movements and a too-small gap may catch debris, and maybe cause rubbing as a consequence of thermal expansion too. Also, your cooling set-up probably lowers the temperature of a large portion of the printer so that it may not be beneficial for the motor only but for all adjacent parts
Michele Moramarco Prusa Research
Prusa Mk3s, latest releases in both slicer software and printer firmware, I have same problem, I changed the linear bearings by a branded IKO high quality ones, in both, X and Y, (bearings currently supplied from Prusa looks like low quality ones), both belts changed by a Prusa supplied ones, and still after adjusting and calibrating everything, the ghost Y crashes are still happening, in the same way as before to change everything, the only I can imagine now is that the point of the current in miliamps, to be detected as a crash, has been decreased, then when at printing process you have accelerations, the increase in the current is perceived as a crash, this same change in X, results in lost of accuracy at zero positioning after a ghost crash, because even if you have a real crash, the system goes to X stall sensing "zero hardware position", and could be back to recover the printing position, but in this case, lowering the detection level, what you get is a point, a bit before or after the end, with some amount of current increase, that results in a diferente "zero" position, then what you get is an error in Y but a real layer displacement in X, that is great to make a mesh in your head, from my point of view, after one week checking almost everything, and rebuilding the mechanical performance, the problem is clearly inside the firmware.
https://github.com/beelercoding>
I have the ghost Y blocking, even with cold motors, I have a bit more space at sprocket in order to be sure that the sprocket will never touch the motor body, I could probably get the error in least a minute after switch on the printer, simply sending gcodes via Pronterface.
I have not any kind of enclosure
Now the solution to be able to use the machine, is to have the shock detection disabled, the current status is shock detection disabled, thermal image disabled, not a great experience with new firmware releases
@Escrich Did you try a full firmware reset? This did the trick for me.
https://help.prusa3d.com/article/full-system-refresh-original-prusa-i3_133258
I started having frequent y-axis crashes now that I have my MK3S+ inside a Prusa enclosure. I'd never had a y-axis crash before putting it into the enclosure. Based on my observations, the following are variables contributing to the crashes.
Contributing Variables
anyway, despite of your observations, the printer must work in all conditions listed above by you, as before, the only difference is the firmware, the mistake is in the firmware, I love my Mk3s as is, but I have no inconveniences to switch it to klipper, I have at home hardware enough to do it, then this surrender will imply that I will never buy anything more on Prusa shop
This problem has happened to me also after upgrading the firmware 3.13.0. I was working fine, but the new MMU firmware was released and I heard great things. It is a huge upgrade for the MMU!! But at the same time my mk3s+ was also upgraded to talk with the new mmu2 firmware. After this the MMU2 is AWESOME, but the printer started throwing ghost y crashes. I feel like others that tolerances might have been changed. I have tried replacing the bearings and rails, no difference. Currently I have a knock off y-axis motor ordered just to see if that makes a difference. If I have any progress I will post.
@proachaz My hunch is that this issue is actually caused by EINSY temperature, not the motor itself. I used an infrared temperature gun to see if the y motor was hot and it wasn't bad. ...but when you installed the MMU, you packed even more wires into that tiny little einsy case and now there's even less air flow.
I haven't tried it but was considering printing a bigger einsy case (https://www.printables.com/model/31558-big-einsy-case) to see if that would help, but would probably be better off rigging up a small computer fan on the einsy case to see if that helps. If anyone tries that I'd love to hear the results.
@adamdport Heat kills, so this is a direction I can see. It seems as the print goes the problems get worse, so as it heats it gets worse...makes sense. I am trying a fan blowing on the back side of the einsy case while printing the same print that has been failing. I added the mmu a while back and didn't have these problems. BUT as everywhere it is very hot where I live and the room the printer is in can get over 90 degrees. I will let you know if the print gets farther. I will try the case just cause it needs more space in there.
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.