Notifications
Clear all

Crash detection false positive  

Page 1 / 2
  RSS
tsamisa
(@tsamisa)
Estimable Member
Crash detection false positive

I encountered a strange issue lately that i'm not sure if it a firmware error (currently on 5.0 alpha) or something with that has to do with the printer. When the tool has to travel a rather large distance (more than half the hotbed) it accelerates , breaks suddenly and there is a crash detection error. I set the sensitivity to low, used another stl but i get the same results. The only solution is to disable crash detection for that print. I know that i should open a call with prusa chat but before waiting for half an hour and the another half answering generic questions i was wondering if someone encountered something similar.

Posted : 12/11/2023 4:42 pm
GuyH
 GuyH
(@guyh)
Reputable Member
RE: Crash detection false positive

It's a bug and has been reported by a few of us on github. As it's an alpha you're essentially testing for Prusa is you run it.

Posted : 12/11/2023 8:57 pm
tsamisa
(@tsamisa)
Estimable Member
Topic starter answered:
RE: Crash detection false positive

Thanks. 

Posted by: @guyh

It's a bug and has been reported by a few of us on github. As it's an alpha you're essentially testing for Prusa is you run it.

 

Posted : 13/11/2023 5:01 am
kurisun
(@kurisun)
New Member
RE: Crash detection false positive

I assumed it was due to the alpha firmware as well, but it is pretty jarring to hear that collision ping.  Doesn't happen to me on all prints, but there was a few where it went to do a large move and triggered it.. mostly in the early layers.

Posted : 13/11/2023 2:32 pm
Jeggo
(@jeggo)
Estimable Member
RE: Crash detection false positive

Same here with 5.0.1 alpha 2

Does it speed things up if I comment the issue on github?

Posted : 23/11/2023 9:55 am
Jeggo
(@jeggo)
Estimable Member
RE: Crash detection false positive

Just upgrade to 5.1.0 beta. Issue seems not to be fixed. Just printing with disables crash detection.

Posted : 23/11/2023 1:02 pm
Jeggo
(@jeggo)
Estimable Member
RE: Crash detection false positive

Just found the issue on github.

https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3381

Not solved neither assigned 😥 

Posted : 23/11/2023 1:16 pm
Jeggo
(@jeggo)
Estimable Member
RE: Crash detection false positive

Moved to firmware 5.1.0 final this morning. The crash issue is still not solved. But I found a work around for this.

The crash detection should be based on monitoring the current of the stepper motors (just like in the sensorless homing sequence at the beginning of the print job).
So what causes a high current? Either a crash or high load/speed. So I reduced the travel speed in the print settings in the slicer. I started with 50% of the default speed of 400mm/s with and XY crash sensitivity set to "low" (settings/hardware). Print of the Prusa "First Layer" test was successful. I also tried 75% and 90% of the original travel speed. All prints were successful. Even with XY crash sensitivity set to "medium" works.

So the reduction of travel speed to 360mm/s seems to solve the problem for me. This is only a minor increase in printing time but offers you the security of crash detection. 

Posted : 24/11/2023 2:07 pm
GuyH
 GuyH
(@guyh)
Reputable Member
RE: Crash detection false positive

they’ve disabled crash detection in the final firmware so it shouldn’t be running if that’s true

Posted : 24/11/2023 2:18 pm
Jeggo
(@jeggo)
Estimable Member
RE: Crash detection false positive

I did a test with crash detection on with 5.1.0 final and got the same results (crashes) as with the earlier versions. So I think, crash detection is still working and the slightly reduction of travel speed seems to solve the problem.

So far I only had the crash problems with prints, that have a lot of long travel moves. For most of the models this will not happen.

Posted : 24/11/2023 3:38 pm
GuyH
 GuyH
(@guyh)
Reputable Member
RE: Crash detection false positive

From the release notes. 

Original Prusa XL - Current Input Shaper limitations

In this firmware release, the Crash Detection feature is temporarily disabled on the Original Prusa XL because overly tight belts may trigger a false crash detection. We’re currently working on improvements in belt tension tuning and once it’s done, we’ll release an updated firmware that will re-enable crash detection on the XL. It will likely be accompanied by a new belt tuning app profile.

Posted : 25/11/2023 1:03 pm
Jeggo liked
Jeggo
(@jeggo)
Estimable Member
RE: Crash detection false positive

I am just printing my first bigger part and just got a false crash detection. I am a little bit confused. When Prusa claims, that they have disabled it in firmware 5.1.0.

How could this happen?

Posted : 27/11/2023 3:06 pm
Jeggo
(@jeggo)
Estimable Member
RE: Crash detection false positive

Just want to confirm my earlier comment. Although the release note of firmware 5.1.0 claim that the crash detection is disable, it does not seem to be totally correct.

I printed a test part which is over 400mm long and has little towers at each end. So the print head has to move appr. 400mm to reach each tower. This happens more than 15 times while it is printed. If I use the 0.2mm quality setting with 0.6mm nozzle (standard no input shaper) I got about 7 crash detections.
Same part with the same settings only reduced travel speed from 400mm/s to 300mm/s. No crash at all!

If the crash detection is really disabled, why can I still see the settings at the printer and could turn in on or off?

Posted : 30/11/2023 11:55 am
GuyH
 GuyH
(@guyh)
Reputable Member
RE: Crash detection false positive

Do you get the issue if you disable crash detection on the printer? 

Posted : 30/11/2023 3:54 pm
Rob65
(@rob65)
Active Member
RE: Crash detection false positive

This still happens.

My new XL multitool has a test report dated 22.02.2024 and has firmware 5.1.2 installed and I do get regular false crash detections during printing.

This ruins my prints, especially when this happens on a tool change since now the filament oozes out of the nozzle, either ruining the print or preventing support material to be laid down correctly.

I love my XL but it seems a bit strange to me that a company with quality in mind still has an issue that long before properly fixing it.
Most annoying: they are delivering me a new printer that still has this (known !!!) issue

 

Posted : 02/03/2024 9:42 am
tsamisa
(@tsamisa)
Estimable Member
Topic starter answered:
RE: Crash detection false positive

Unfortunately  the only solution that worked for me was reducing travel speed from 400 to 360 in Prusaslicer

Posted : 02/03/2024 5:51 pm
Rob65
(@rob65)
Active Member
RE: Crash detection false positive

Well ... steps lost are mostly caused by high acceleration, not high speed.

I noticed that Prusa reduced the machine limits in the newer setting for the XL. The accelerations for X and Y were reduced from 9000 to 7000.
I reduced the accelerations to 6000 and the maximum feedrate for X and Y from 450 to 400 and have not seen the error since in over 12 hours of printing on my machine. Before, it used to almost always have a false crash detection during startup of the print (just before starting the bed measurements).

This seems to have almost no impact on printing time.

Posted : 03/03/2024 9:12 am
tsamisa
(@tsamisa)
Estimable Member
Topic starter answered:
RE: Crash detection false positive

Well on my 2.7.2 Prusaslicer indeed  the default acceleration setting is now 5000  for travel moves. ?I'll give it a try then with the default 400 speed. The max feedrate is still 450 but this is set as the max limit. If the travel speed is set to 400 when does it actually get to 450  (thus the need to change the max settings)?

Posted by: @rob65

Well ... steps lost are mostly caused by high acceleration, not high speed.

I noticed that Prusa reduced the machine limits in the newer setting for the XL. The accelerations for X and Y were reduced from 9000 to 7000.
I reduced the accelerations to 6000 and the maximum feedrate for X and Y from 450 to 400 and have not seen the error since in over 12 hours of printing on my machine. Before, it used to almost always have a false crash detection during startup of the print (just before starting the bed measurements).

This seems to have almost no impact on printing time.

 

Posted : 03/03/2024 12:27 pm
Rob65
(@rob65)
Active Member
RE: Crash detection false positive

If the travel speed is set to 400 when does it actually get to 450

I don't know but I think it's best to set the printer limits instead of relying the print-settings to take care of this.
Next time, you'll use a different print setting that may increase the speed again and then you are wondering why you get crash detections ...

Anyway ... it seems like Prusa is "fixing" this by changing the PrusaSlicer settings instead of making sure the limits are set in firmware. So we do have to keep an eye on future changes in these settings ...

 

Posted : 03/03/2024 3:03 pm
tsamisa
(@tsamisa)
Estimable Member
Topic starter answered:
RE: Crash detection false positive

Anyway i gave it a try with the  updated Prusaslicer settings and it still crashes. The only difference between your values and Prusaslicers is that the maximum limit is set to 450 and travel to 400. I'll keep setting my travel limit to 360 (maybe it works with 380) since it doesn't actually cause such a bit overhead in speed. Maybe it would be more evident in case you have a lot of objects printing the same time. I know its not much but it makes you wonder if this are actually the limits of XL. Maybe if we loosen the belt tension a bit things will improve but i dont wont to mess with his for now.

Posted by: @rob65

If the travel speed is set to 400 when does it actually get to 450

I don't know but I think it's best to set the printer limits instead of relying the print-settings to take care of this.
Next time, you'll use a different print setting that may increase the speed again and then you are wondering why you get crash detections ...

Anyway ... it seems like Prusa is "fixing" this by changing the PrusaSlicer settings instead of making sure the limits are set in firmware. So we do have to keep an eye on future changes in these settings ...

 

 

Posted : 03/03/2024 3:36 pm
Page 1 / 2
Share: