[BUG] Ghost Y-Axis Crashes #2653
Comments
|
Can you check that your linear rods are lubricated? They could be causing to much resistance, causing the Trinamic drivers to think that they have crashed. |
|
This printer was freshly assembled, and the only lubrication was from what the bearings came with. How should I go about lubricating it? I have 3-in-1 oil as well as the lubricant supplied with the kit. |
|
You can use the lubricant supplied in the kit. This page has more information on lubricating the linear rods. |
|
I lubricated the linear rods as described, and it still crashed while printing the benchy. |
|
Can you check that all your wires are plugged in fully? Also, how much resistance does it take to move the bed? |
|
They are, and I'm not exactly sure how I could describe moving the bed. It's not easy, but it's not really hard? |
With the printer turned off can you move the axes with a single finger pressure? It should not take much. What I have done in the past is to loosen the belt by partially unbolting the motor to drop it down and relieve the belt pressure, so there is no motor friction in the mix. After you drop the motor you should be able to easily slide the axes from end to end with no binding at all, and very little noise. Any inconsistency here can cause problems with jamming, calibrations, layer shifts, you name it. My first thought is your U-bolts are too tight. They are very very easy to overtighten, and what happens then is the bearings will drag, and wear more than they should. The instructions really don't go into all this as much as they should, probably because it's tough to explain how to adjust these by feel to a non technical audience. How I have learned to do it is to tighten up the U to where it just touches the bearing, then tighten a 1/8 turn at a time until I cannot move the bottom of the U by hand. No more. It is plenty tight at that point. |
|
I'll check the tightness of the bearings |
|
I re-did the bearing tightening, but it crashed again on the benchy. I wonder if there's just a way to turn down the crash detection sensitivity, so it doesn't keep detecting false crashes. |
|
Try slowing the print down and see how it does. I am not questioning your skills at all but trust me getting these printers right is not as easy as you would think. There's a lot of fine tuning and tweaking and adjustong. You should consider yourself in the debugging stage. Does your print get thru self test and xyz calibration? |
|
It does, and I can print fine with the crash detection turned off. Btw this is with the files that are supplied with the printer, so I'd expect them to be able to get through the whole thing just fine. |
|
@DFliyerz does your problem persist? We have seen reports of Y-crashes for no obvious reason when printing in high temperatures (bed + enclosure). |
|
Hello,
Since I opened everything, Y-crashed seem to be a bit less frequent, and my MK3S have not yet stopped with the interactive menu asking to resume or abort the print. It just does a re-homing and moves on with the print. So maybe the temperature has something to do with it. Unfortunately, I don't have anything to mesure the motor temperature. Is there a way to retrieve it through software ? Edit: The printer eventually stopped, asking to resume or abort. I added a video of the problem. |
|
I also have had this issue since I got the printer Back in january. Persisted since 3.8.1 through to 3.9.1. rebuilt, retightened Y Axis many times. Belt rides straight. Bed moves smoothly. Tried changing ubolts to printed bearing mounts. Still persisted. Crashes happen at about same heights only on Y Axis. For truly no reason. I noticed in the code for tmc2130.cpp that there used to be a different specific value for stallguard threshold just for the y Axis. This was since commented And the value set for all Axis. Maybe this threshold needs adjusting again. |
|
I have the same problem for a week, the printer stops at a similar height, check the bed, belts and also lubricate the bearings, for the moment deactivate the crush detection, does anyone have any solution? |
|
Exact same issue since updating firmware to v3.9.1 Disabling crash detection is the only workaround to stop all the scarring in the print. Here is a video of it - happens at 0:29 I read on the Prusa forum that host stepper drivers can cause this. We were having consistent 35C+ days where I live, so this is a possible cause. I am in the process of moving the printer into an enclosure with the power supply and EINSY board relocated to separate electronics enclosure that will have fan forced cooling. I'll also add some heatsinks to the drivers on the EINSY to further assist with heat dissipation. I'll report back with my results.
|
|
Hey there, |
|
Just out of curiosity, how do you know it's an Y axis crash? I guess you're reading the serial log (octoprint?). Cooling the Einsy is good, however IC overtemp will not cause missed crash detection by itself (or at least, I don't think this should happen). What's more likely is that the motor itself gets hotter, increasing coil resistance and thus might require some threshold adjustment. Can you do this test: start a print and after the first layer, and touch (or measure! if you can) the X/Y motors to see if they run roughly at the same temperature. When you get the Y crash, do the same again. Does the Y motor run a lot hotter at that time? |
|
When the next crash happens I will let you know. Thank you! |
|
What I had to do to fix it, since prusa support failed to help me after swapping X and Y motors. Was to buy a new Y motor myself, which ended being the true fix for my Y axis crashes. |
|
In my case, using the Prusa V2 enclosure to print ASA, I was seeing frequent Y crashes above a certain Z level. The issue was caused by having the printer too far back into the enclosure, so that the cable bundle coming off the bed was hitting the back window. This also caused the belt self test results to report unexpectedly high values (270) or failing. By moving the printer forward to avoid this, the belt self test result is now reading 240. Furthermore this fixed the issue where crash detection was triggering during printing. |
|
In my case I do have a custom case made out of multiplex. It's big enough that the cable bugles cannot touch the walls. |
|
Just in case somebody is still running into this, I've created a PR #3089 that correctly shows which axis is affected during a crash, especially for repeated crashes that cause a "Resume?" prompt it would include all the axes affected. |
Did better cooling on the RAMBO board resolve the ghost Y axis crashes? |
|
Better cooling also helped me a lot, though didn't completely resolve it. I added a fan to the enclosure. My final solution will be to just not print high temperatures with the Prusa and instead use my Voron printer. |
|
Thanks Chris,
I've been printing in stealth mode for a while with no issue - so maybe
that is a good solution for the ghost crashes as well!
Jeremy
…On Sun, 18 Apr 2021 at 08:01, Chris Taylor ***@***.***> wrote:
Better cooling also helped me a lot, though didn't completely resolve it.
I added a fan to the enclosure.
My final solution will be to just not print high temperatures with the
Prusa and instead use my Voron printer.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2653 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHNTXB7MEHA6GUNCN7JHKYDTJHSJNANCNFSM4MYHMP7A>
.
|
|
@morphias2004 looking at the video it seems it always gets choppy when the extruder goes to the back-right corner, I guess it's the video only? I don't see anything in the print that would cause any non-smooth movement except the wipe at the seam, which is on the exact opposite corner anyway. Crashing in relation with print height seems mostly because there's more weight on the plate here, although the position doesn't make sense to me. One important thing could also be to ensure that the bed moves smoothy when it's hot. When printing enclosed with the bed at 100C and more, the bed flexes along with the spider underneath (and a bit everything around the printer). This can push the rods and the bearings can start to jam near the front or back depending on alignment. I never had this since I also print hot+enclosed frequently, but it wouldn't hurt to check:
with steppers disabled, move the bed and check for resistance. Simply realigning the rods on the frame while the printer is hot could help. @catid do you notice a relation with the object that you're printing, or does it simply fail seemingly randomly? How often does it happen? |
|
Who would be willing to test a branch that changes the crash threshold logic and report back on false or missed crashes? https://github.com/wavexx/Prusa-Firmware/tree/sg_logic_tweaks I can provide some prebuilt FW versions if someone is interested in testing. I also did get some false crash detections, but they're really rare for me and thus hard to test for. |
|
@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). |
|
@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.
|
|
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 trim.72B7D1E6-3A06-4C35-B570-DCB3C1D24881.MOVtrim.A9F63FF2-5E68-4B21-9D53-03F319BE7EE1.MOV |
Any improvements? I am also having issues with temps in an enclosure, it seems. On the chat w/ support now. |
|
@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. 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] [EDIT_2] Michele Moramarco |
|
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. |
|
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: |
|
|
There shouldn't be inttentional motor-related changes in FW 3.13.2 and we can't confirm the bug described in issue #4476 just yet as we struggle to reproduce the problem. We are sill investigating the issue #4476, however, it is not related to this thread - which is rather older. Michele Moramarco |
|
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? |
|
@TheWug Thanks for the comment. We are testing the fix for this and hopefully can release it as FW 3.13.3. Stay tuned. |
|
If anyone wants to test a development version that solves the Ghost layer shifts, please send me a DM via email. |
|
Please update to FW 3.13.3 and give us some feedback, I would like to close this issue. |
|
@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. |
|
@adamdport Thanks for the feedback, frankly this issue addresses different Ghost Y-Axis issues.
I hope to get feedback from the users reported the 2nd one. |
|
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 <#2653 (comment)> , 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: ***@***.*** ***@***.***> >
|
@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". |
|
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. 79118796-AD29-47AF-8CE5-A224584516FF-20734-000003056D8F0A51.Copy.mov |
|
@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... |
|
Also experiencing this |
|
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 |
|
Yeah. As pointed out in the past - #2653 (comment) - 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 |
|
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: However this did not solve my issue at all Print Settings:
Ambient Temperature
An example of the most recent rehoming incident is below: Any help/suggestions would be really appreciated! |
|
After yesterday's update, the ghost crashes detection, has been significantly increased |
and others
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.
The text was updated successfully, but these errors were encountered: