RE: Crash detection false positive
Ha - I was starting to go nuts and wonder what it was.
About a week ago I was running a print and had a whole layer shifting after a "crash".
Tried different setups and had zero issues.
last night ran the same gcode as I needed more copies, but it crashed.
I hit resume and It crashed again trying to relocate the extruder to a different point. So definitely acceleration. Brought down the speed to 90% and hasn't crashed since.
probs went a bit too juicy trying to get a 14 hr print to run quicker (12h).
As some say it can be a crash, load/current/speed. But what I saw today I think that even the XY axes could get a bit skewed moving tension on the belts (losing on one while increasing it on the other axis) just enough for the printer to either shift a layer (detection off) or crash.
My concern is that if this is the case then it's a design issue more than an electronics issue.
Currents, accelerations and everything can be solved by math and clever programming.... firmware.
If there was to be a printer design/stiffness issue then the only way to solve it would be precisely to disable crash detection and slow prints down via the slicer. 🤔 (Or re-design a bunch of things.... a new printer)
I'm running 5.1.2 as well. And sliced this with 2.7.0 if I'm not mistaken.
RE: Crash detection false positive
Good morning,
I received my first XL I actually have the same problem, hoping that a solution will be found quickly, with my MK4 no problem
RE: Crash detection false positive
Well, as I wrote before (and if I did not, I should have) it is strange that Prusa is delivering printers as if everything is okay, but knowing there is an issue that impacts print quality. They should focus on problems like this and get them fixed before ramping up production.
Yes I do understand that production and product 'improvement' are different things done by different people but still: the older printer we have does not have this problem, the new one we got does. Belt tension on the new printer is definitely higher than on the old printer and they have identified this as being an issue with belt tension at some point so they should fix this.
Don't get me wrong; I am a big fan of the XL. It not only delivers outstanding print quality but is very reliable. The older XL is being used as a production printer and is running for 6 months without any problems, the newer XL is also working great apart for the false positive crash detection issue.
But they should get this fixed NOW or you will see a whole lot of unhappy customers
RE: Crash detection false positive
Yes because this is not just a false crash detected, but a belt tension problem because we clearly understand the problem
RE: Crash detection false positive
I was getting false crashes all the time, especially with long print @ 45 degrees across the bed, the motors don't seem to be able to keep up and go out of sync at higher travel speeds; the reason that it's bad with 45 degree movements is because 1 motor is doing all the work at that angle.
I did a lot of testing “ghost printing” (with no filament), I still got occasional crashes with travel speed reduced to 350mm/s, didn't get any with it set at 200mm/s, but I didn't test anywhere in between. I tried adjusting the belts and even tried them tighter than spec, as suggested by Prusa support, but it made no difference.
The 3rd time that I spoke with Prusa Support about this they, they suggested that I update to the Alpha 6.0.0. Firmware, which I did, and I have not had a "crash" since.
RE: Crash detection false positive
I tried adjusting the belts and even tried them tighter than spec, as suggested by Prusa support, but it made no difference.
I find this a strange suggestion, especially since the problem seems to be originated by setting the belts too tight at delivery according to the github issue on this.
On my older XL I never had false crash detections but on the new one I had a lot of crash detections. The new printer has higher belt tension than the old one.
The 6.0.0 firmware has the new phases stepping feature activated by default. As stated in the release notes, this does not work together with the crash detection feature so that is turned off. Hence, no more false crash detections 😮
Meanwhile I have my accelerations and printing speeds turned down a lot from the default in the structural@XLIS 0.4 profile. The default profile resulted in sub-optimal quality and a lot of problems when using grid infill (small parts knocked off from the bed due to the nozzle scraping over the infill). Never had the problem since.
I rather have a printer that is (a bit) slower than having sub-optimal print results with possible failures.
RE: Crash detection false positive
Were your machines running the same firmware?
After I build my printer, before I ran it, I checked the belts and they were a bit tight, so I backed them off to 82hz. After I started getting problems (the first time I was printing a longer item, diagonally across the bed), I tightened them back up, but it made no difference.
When testing with the older firmware, I tried all of the level of crash detection & with it turned off too, the only difference is that when it "crashes" with CD on, it re-homes and carries on, but with CD off it goes around crashing into everything, then drops the tool head if it moves too far to the right or crashes when it tries to dock.
All of this went away with 6.0.0., which makes sense as the phase stepping changes the way that the motors are driven.
RE: Crash detection false positive
Yes, both machines had the same firmware (5.1.3 if I remember well) and I used the same printer profiles in PrusaSlicer, so both used the same speed and acceleration settings.