Y-Axis fake(?) Crash detections - let's debug  

RE: Y-Axis fake(?) Crash detections - let's debug

I have recently one user on czech forum, he was strugling with crash detections on 3.8.0 ,he downgraded to 3.7.2 and having no issue with the same printouts.

Which is a bit curious.

So could be ,that 3.8.0 crash "sensitivity" is higher than the previous 3.7.2 version. But this info only developers have.

Is difficult to say which one is better - sensitive detection can signalise "something is wrong" so do something about it or the printer is "too much sensitive" on neglectible details.

Will check if we have more cases.

I talked with support, whether they could implement in FW XY coordinates logging at the moment of crash detection, so the issue investigation could get more detailed info about the printer head position.

In my opinion they store it, otherwise the printer would not know where to continue after the extruder returns from home position.

RE: Y-Axis fake(?) Crash detections - let's debug

Posted by: @majorzbzzn

I upgraded to 3.8.0 and now the problem is even worse 🙁

Can you please let us know what was your situation before upgrade to 3.8.0 ? Was it ok or already bad?If so how bad?

RE: Y-Axis fake(?) Crash detections - let's debug

Posted by: @tim-m30

Posted by: dinots

Wow, thanks for the reply.  This frustrated me to no end.  This is my first 3D printer but I followed the manual very closely and the first couple weeks of prints were amazing.  Did the chat person indicate that the issue would go away when on Stealth mode?  That is what is happening for me.   I'll just keep it on Stealth for now until they get this worked out.

Happy Printing.

Crash detection is disabled in stealth mode.

@dinots

Instead of printing in stealth mode you could decrease the print speed in normal mode,which ensures your crash detection is active. Then you will see if the crashes happen less often also at lower speed like adrian-claudiu90 is reporting above. This could indicate some frictions, they have more significant effect at higher speed.(more crashes).

Additional question: during the whole time you never moved your printer? 

RE: Y-Axis fake(?) Crash detections - let's debug

Posted by: @majorzbzzn

@tim-m30

I did the test and you are right. There is a spot about 80% down the way where the bed gets stuck. If I give it a very light push it continues as normal. If we assume that this is indicative to the problem. What can I do to resolve it?

A sticky spot is tough to resolve over the telephone ... lol.  Things to look for are wires or cables that might snag; the U-bolts hitting the frame; or even a damaged rod. Any small nick will cause problems. Look at where the bearings are when it sticks, then feel along the rod in those spots with your fingers for any defects. 

RE: Y-Axis fake(?) Crash detections - let's debug

@tim-m30

Thanks, I will check. Meanwhile I can avoid printing at that area of the bed 😀

RE: Y-Axis fake(?) Crash detections - let's debug

@zoltan-l

I posted earlier. It is hard to compare but for a 2 hour print I had 2-3 crashes in 3.7.2 

With 3.8.0 I had 22 crashes for a 5 hour print. 

As I mentioned before. It is really hard to understand why there is a crash because everything seems normal.

RE: Y-Axis fake(?) Crash detections - let's debug

"crash" just means higher than normal motor forces detected. it can be nozzle dragging on a rough  layer or bearing friction causing extra forces or something caught in the motor gear changing belt tension as the motor revolves

RE: Y-Axis fake(?) Crash detections - let's debug

Greetings everyone from California.

I have a MK3S that has excessive crashes, even on totally normal parts with no curling or bumps that would cause a crash. This is with 3.7.2fw.

When I installed 3.8.0, the printer was unable to home without repeated "crashes". I downgraded back to 3.7.2 and it can home again but I still cannot complete any long prints without multiple crashes. My other MK3s is also experiencing some crash problems. I think part of my issue was my printer enclosure making the motors hotter, so I am now printing with the enclosure doors open and some enclosure vents opened again, but the problem persists.

I've felt the Y axis and it seems okay, but I still need to check my belt numbers and try the gravity trick to check for any rough spots on the bed. But my printers at home which are not Prusas never behave like this even with rough spots, perhaps because they don't use crash detection.

I've disabled crash detection on these MK3s prusas just now, but I can't recall if someone in this thread said that did not fix the problem. My problem is not real crashes, so maybe my prints will finish with this disabled. I will follow this thread for updates, but please let me know if I can troubleshoot.

Thanks,

Taylor Alexander

RE: Y-Axis fake(?) Crash detections - let's debug

Post a photo of the part where it crashes ...  otherwise you'll keep on guessing.

RE: Y-Axis fake(?) Crash detections - let's debug

Same issue here.

Many y-axis crashes detected on a brand new printer. Failed to print a benchy 3 out of 4 times.

Prusa mk3s.

Belt tension 257,249.

Latest firmware.

Support could not help. I had to send back the controller as apparently was defective/refurbished.

RE: Y-Axis fake(?) Crash detections - let's debug

@tim-m30

According to prusa, Numbers above 240 are slack, not tension.

RE: Y-Axis fake(?) Crash detections - let's debug

I'm also experiencing y-axis crashing seemingly out of the blue. Had my mk3s less than 1 week, upgraded to latest 3.8.1 before my first print and everything worked like a dream until today when I started getting constant crashing on the y axis (and only the y axis) for seemingly no apparent reason. 

This is a pre-assembled version, so everything should be good out of the box. My belt tensions are 249/279. I'm running a print right now with crash detection disabled to see if everything comes out ok. 

RE: Y-Axis fake(?) Crash detections - let's debug

Has there been any new information or updates on this?

I've suddenly started having Y crashes (only Y), the total has gone up over 100 over my last 20 prints or so.  Some prints are fine, some I watch it crash over and over, seemingly for no reason.  Belts are 260 and 262.  I can't fee any real difference between the axis, both seems smooth and well lubed (just a touch of PTFE-based super lube grease). 

Is there a heat component here?  It seems like it's mostly later in prints that I have issues.  The Y axis motor does seem warmer than the X, which from the belt status I don't know why that'd be the case.  I moved the bed back and forth after a long print, and I don't think anything is hitting from thermal expansion.  I'm considering sticking a small heat sink and fan on the motor, just to see if anything changes. 

On one print that was crashing I turned off detection, and it hasn't shifted layers, so I don't believe there's a real crash here.  I'm running 3.8.1, which from what I can see is the latest firmware. 

RE: Y-Axis fake(?) Crash detections - let's debug

@scottmg

My issue turned out to be absolutely no lubrication in the bearings (prusa did absolutely nothing to lubricate them from the factory). I tore the Y axis apart and tried sliding the bearings on the rail and they were difficult to push (instead of a smooth glide). I actually had to apply a fair bit of force to move them.

What I did was grease pack my bearings with this:

https://www.amazon.com/gp/product/B000XBH9HI/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1

And I regularly lubricate my rods with this:

https://www.amazon.com/gp/product/B000UKUHXK/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1

Its back to being the best printer I have ever used now. It actually works better than when I initially got it. I had issues since day one with PETG creating little "loops" that would catch on the hotend. Lubing the bearings and rods fixed that 100%. Seriously, properly lube your rods and bearings. Some oil on the rods would probably suffice if you don't want to tear the thing apart. 

I agree with what others say here and disagree with prusa support. If crash detection is triggering, something is wrong. Don't ignore it or just turn it off. 

RE: Y-Axis fake(?) Crash detections - let's debug

@inthepretendworld

Thanks for the info, when I get some time I'll at least pull the belt off and feel without the resistance of the stepper.  I haven't actually packed my bearings, but I never go too many prints without adding a little super lube (the grease that you linked), working things back and forth, then clean off the extra. 

I suppose with bad bearings or junk in the bearings, it could go from OK to sticky randomly.  Maybe I'll purchase some new bearings if I keep having issues.

RE: Y-Axis fake(?) Crash detections - let's debug

I've been having the same problems with phantom Y-axis crashes, and I noticed that they seemed to increase in frequency when using higher temp materials, and especially when using a cloth photo booth thing as a cheap enclosure. The Y motor seems hotter to the touch than the X motor right after the crash happens, so I'm thinking the motor overheating is leading to decreased efficiency, and the computer is seeing that as an obstruction and tripping the crash detection. Does that sound reasonable to anyone? Being right under the heated bed could be why the Y-axis is the only one that gets these crashes, or maybe it's just that the bed is heavier than the extruder assembly, so the Y motor has to do the most work and produces the most heat. 

Do other people having this problem see the same thing with the Y-axis motor temp? I'll see if I can find a heatsink that size I can stick on there to see if that changes anything. 

RE: Y-Axis fake(?) Crash detections - let's debug

Overheated motor can be not a reason, but a consequence of a bearings friction on Y-rods (for example) or other obstacle and the increased Y motor current grows to level, when the FW is detecting the crash. Increased motor temperature increases also a crash sensitivity. So my advice is to check the Y rods by moving the bed manually and checking whether you will recognize any increasing movement resistance. Check the belt tension should be around 260 -  280 and the bearings.

RE: Y-Axis fake(?) Crash detections - let's debug

Hello everyone,  

Thank you so much for all of the information and testing.  I am completely convinced that I figured out the problem that has plagued so many of us.  I will test my solution this week.  About two months ago I solved a VERY similar issue on another printer.  Then recently this issue on my mk3s has become more and more prevalent.  I read through all six pages of this thread searching for a solution.  Finally last night it came to me.  It all fits.  It all adds up.  Before I blurt out my solution I want to explain my reasoning and deductions.  All of this I summarized from your contributions and posts.

Symptoms and Conclusions:

• Fake Y crash meaning NOTHING is causing a mechanical crash. All of your Bearings, lube, rods, u bolts, belt tensions etc. are all in great shape but you still get a y crash detected.
  • Conclusion.  The problem must not be mechanical.
• Sometimes you can go one or more prints without an issue.  But when you get one you often get more during the same print.
  • Conclusion.  The problem is not random.  It is triggered by unknown factors that once triggered are likely to trigger repeatedly.
  • The problem could be caused by the timing or the environment.
• Increasing the current to the motor seems to help but not solve the problem
  • Conclusion.  This solution is only a band-aid that helps to hide the problem.  
• It doesn't matter where the object is placed on the bed.
  •  Conclusion.  Again not mechanical also not a position specific bug in the firmware
• The benchy usually causes a fake crash in near the same spots
  • Conclusion.  Their must be a combination of accelerations or jerks that are more likely cause the crash.  Maybe a firmware or Processor issue?
• The crash happens more on the Y than on the X
  • Conclusion.  The Y axis is heavier and needs more power to accelerate.

I had more conclusions but I know I am getting long winded so I will move on for now.  Two month ago I was heavily Modding my Lulzbot Taz 5.  As I was upgrading the firmware to a newer version I suddenly started having the Z axis skipping issues.  No belts so it was the motors just stuttering.  I tried to realign the z axis, I tried to lube everything, I then started increasing the current to the steppers to dangerous levels.  It helped but it did NOT solve the problem.  This was frustrating because it worked before the firmware upgrade.  How could it suddenly be broken?  Then it hit me.  The stepper drivers were getting too hot.  As it happened I had disabled the fan that cooled the control board.  I re-enabled that fan and solved the issue.

Here is my theory of the problem.  The stepper drivers on the control board are getting too hot.  That is why it doesn't always happen all the time.  During the winter it hardly every happened to my printer.  Now it is warming up it is happening more often.  (My printer is in the basement)  The Stepper drivers get so hot that they THINK they need to increase the current (or spike) to make the move.  it fits all the symptoms.  

How to solve it?  I am going to connect an always on fan to cool the stepper drivers.  Maybe a 24 v connected to the main power in.  Then I will retest everything. I know many of you are no longer actively trying to solve this issue but I will report back here and let you know how my testing goes.

RE: Y-Axis fake(?) Crash detections - let's debug

If your stepper motors are too hot, check, if they are not facing to much resistance , blocking bearings etc. When they are working on the edge of force, than you need only a bit more resistance and it is encountering a fake crash.

The motors should not be too hot, check help.prusa3d.com, where you can read about reasonable mototr temperature.

Crash detection is derivated from the stepper motor current which increases when the motor faces aganst resistance (steadily incresing) or obstacle (shock increase).

RE: Y-Axis fake(?) Crash detections - let's debug

@zoltan

Thank you for your reply and I fully understand what you are saying.  However I believe you misunderstood what I am saying.  I don’t think the stepper motors are getting too hot.  I believe the stepper DRIVERS are getting too hot.  The ones on the control board.  In school we learn that more electricity can flow through a cold conductor than a hat one.  So in theory the stepper driver also needs to stay cool or it may restrict the flow of the current.
The silver bullet that has me 99.99% convinced this is the issue is my recent experience with the lulzbot TAZ 5 printer.  While it’s stepper drivers are not as smart as the ones we are working with here they operate on the same basic principles.  Those older drivers can have their max current set.  That Lower set max current was enough to push the Z axis when those drivers where properly cooled.  When the active cooling was turned off however the same low current would cause the motors to stutter.  Increasing the Max current Setting helped drive the motors more but then the heat would increase and stuttering would begin again.  After the Active cooling Was turned back on all the stuttering stopped.  

Apply that example to our newer smarter stepper drivers and I would fully expect them to detect a crash because they had to increase the current a little to overcome the Increased ohm resistance.  That increase would be the result of the heat built up in the driver just like on my TAZ.  So we can most likely solve this problem the same way I did before.  Add active cooling to the drivers with a small fan.