Prusa-Firmware
Prusa-Firmware copied to clipboard
prusa3d
[BUG] Ghost Y-Axis Crashes
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.
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?
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 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). What is the temperature of your Y-motor? Are all your cables connected correctly?
Hello, I'm currently facing the exact same issue. Loads of Y-crashes starting from around 15mm height. The printer has been working fine for months. Crashes started today. Here is all I can tell about it:
- I had to get to the PTFE tube in the heatbreak in order to remove a small piece of PLA that was preventing the filament from reaching the hotend. I can't see about anything that could have triggered the issue doing so though, but it's best to mention that operation, just in case. it had been several days since I last printed something.
- Calibration is OK, belt tension X:271, Y:271.
- Bed is moving smoothly and freely but still, I added Prusa lubricant to the rods.
- I, however, noticed that the PETG profile I was using was misconfigured : 1st layer temp was 240/85, and other layers temp was 250/90 and not the other way around, so most of the print was done at fairly high temp. I build the Ikea LACK enclosure and only one door was half opened so the temps was around 45°C in the enclosure.
- I tried opening both doors as well as the top and lowered the temp to 240/80, but the print running at the moment suffered 16 Y-crashes already, after 45min of printing.
- I was running the previous firmware when I started facing the issue today. I upgraded to the latest one but the issue is still there.
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
https://youtu.be/IBGHnGUcXes
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, Any news on these crash detection issues? I'm having the same issues you described with my Y Axis. Spurious crashes. Thanks, Sebastian
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?
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. I know these are crashes on the Y Axis because the Fail Status page displays it. In my case the Y Crashes reduced the print quality by a lot. The printer was zeroing itself, in many cases it left ablob or a not connected line to the object and when it continued the nozzle crashed into that line in the next layer and everything got worse. I texted with Prusa Chat and they recommended to flip the printed object by 90° and try again. It became interesting after I sent them a video on a different topic (rambling noises even so I lubed all the bearings before assembly). I am often creating smaller objects and when the printer adds layers of infill the nozzle and the bed have to move very quickly. Since that was my first and only printer I had no reference to other printers and was not aware that these might induce vibrations. The friendly Prusa employee encouraged me to adjust speeds in the Slicer to achieve a smooth print. I did so and that improved my printing quality enormously. I had no more crashes. After all that I wonder why I didn't make up that idea by myself, I totally trusted in the Prusa Stock settings- and those are not made to match every print. Now printer happy, Strohbinsky happy.
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.
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
https://youtu.be/IBGHnGUcXes
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.
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 https://github.com/prusa3d/Prusa-Firmware/issues/2653#issuecomment-821879391, 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:
- preheat enclosure and printer for ASA, so that room temp is around 45C and bed 100C
- let it sit for 15+ minutes minimum, so that the whole frame heats up
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.
In my case I think it is related to the bed temperature expanding the bearings and tightening the U bolts... I tried lowering the bed temperature of an ABS piece from 100 to 85 and the failures disappeared, then with the printer off turned the Y axis bars by hand (place them in a position they were they had not yet been touched by the bearings) and in the next ABS piece the failures became much worse... I had to lower the temperature to 50 C to make the failures go away. Print quality improved a lot..I will loosen the U bolts a bit....hopefully I am on the right track
I was printing the Voron parts out of ASA. On some of the parts that were simpler (boxy) it didn't have trouble. On other models it seems to happen consistently after about an hour of two of printing, when it gets to multiple island features that are smaller so the x/y axes needs to rapidly change direction more, z axis going up and down etc. Motors were getting too hot to touch!