Odd crash detection problems
I'm trying to print some storage drawers. They're nothing special, just 2-3 hour prints. I'm using a 0.60mm nozzle, 0.32mm layer heights and the same PLA settings I've used for countless similar prints in the past. Firmware is 3.8.1RC. PrusaSlicer is 2.1.0. For some reason, I'm consistently getting a pause, what looks like a long retraction, then CRASH DETECTED messages and what looks like layer shifting. This happens consistently at layer 3 in the same location on several prints. Here are 4 separate failed prints:
I've tried rotating the print on the bed to no effect. I took Octoprint out of the picture and tried the print directly off SD card with no change. I finally got it to complete after one crash message by slowing the print speed down to 75% using the front knob.
The printer itself has no issues with large parts using the same profiles.
I tried re-slicing with other settings with no change. Unfortunately, I'm traveling so can't upload a 3MF project file. The STL is the double-wide, double-tall drawer from this collection on Thingiverse. The repeatability makes me think it's a PrusaSlicer bug causing this problem. Before I open a GitHub issue, I wanted to check to see if anyone else has experienced this issue, or has any suggestions to try.
RE: Odd crash detection problems
Bob it sounds like this issue reported on github https://github.com/prusa3d/Prusa-Firmware/issues/2259 which is a firmware issue rather than a slicer issue. The github post has pics atatched which look a lot like yours.
DRracer commented 5 days ago
RE: Odd crash detection problems
Ah, yep. That looks like the problem. I had hoped to get some cabinets completed before hitting the road for a couple of weeks, but finally had to give up. I'll track that issue. Thanks.
RE: Odd crash detection problems
Good old Prusa QC and lack of regression testing strikes again.
ps: and it sounds like they've found the interrupt stack being broken does matter ... lol. I wonder if they'll fix it.
RE: Odd crash detection problems
I think they are really hitting limits on what is possible with the existing 8 bit cpu or maybe their best developers have already moved onto the new 32 bit platform.
Normal people believe that if it ain’t broke, don’t fix it. Engineers believe that if it ain’t broke, it doesn’t have enough features yet.
RE: Odd crash detection problems
I think they are really hitting limits on what is possible with the existing 8 bit cpu or maybe their best developers have already moved onto the new 32 bit platform.
Not really - if you examine the MK3 filament sensor code, it is pretty obvious they are misusing the interrupt stack. A while back when I was fighting filament sensor issues, I did a fairly deep dive into the code and found they were clearing an entire register rather than the bit they were concerned with, and, they were clearing it randomly so multiple occurrences of the flag were being lost; along with other, probably important interrupts from other processes. And coding problems like this are a culture problem inside companies. So the same issues will exist as they migrate to new hardware.
RE: Odd crash detection problems
Aha, I remember reading about an issue with ATMEL chips where by doing something like this where you seem to adding and deleting from the stack, you could end up with the STACK colliding with the .bss
And we wonder why we have trouble with the eeprom and garbage data!.
Normal people believe that if it ain’t broke, don’t fix it. Engineers believe that if it ain’t broke, it doesn’t have enough features yet.
RE: Odd crash detection problems
Bobstro:
Not to be obtuse or obvious, but did you turn off the filament sensor and see if the print completes or is that not an option? I know that is not the final solution and it is good to identify the issue, but those symptoms are very similar to prior filament sensor false crash issues noted previously
I know you have had your printer up and running for a while, but this is not the first time that the filament sensor causes the weird false crash issues, I had it pop up on a prior firmware upgrade and have resorted to leaving the filament sensor off unless I am doing a print that is near to running out and needs it... That thing is buggy after firmware upgrades.
When I get my mini I will not be springing for the filament sensor...
Strange women, laying in ponds, distributing swords, is hardly a basis for a system of governance!
RE: Odd crash detection problems
Good old Prusa QC and lack of regression testing strikes again.
I'm honestly not sure if this is a new issue, or one that goes back to earlier releases. I was just trying to print some drawers before leaving on my trip!
RE: Odd crash detection problems
The interupt and filament sensor issue goes back to at least 3.2. Probably farther. My first bump into it was when my filament sensor detected a run out condition and I was presented with a "Do you want to perform a POWER FAIL RECOVERY ?" lol
RE: Odd crash detection problems
The interupt and filament sensor issue goes back to at least 3.2.
Sounds likely. I'm just puzzled that I've printed very similar parts in the past without issue and am having no problem with other prints. It's these drawers in any orientation that fail consistently and it happens on a fairly innocuous layer with no exciting retraction or other actions. If I ever get home again, I'll try the print again with the filament sensor disabled.
RE: Odd crash detection problems
[...] Not to be obtuse or obvious, but did you turn off the filament sensor and see if the print completes or is that not an option? I know that is not the final solution and it is good to identify the issue, but those symptoms are very similar to prior filament sensor false crash issues noted previously
I was finally able to test late last week. Printing from the SD card with the filament sensor disabled is working, at least well enough to finish most of my bins.
leptun commented 9 days ago
That confirms my theory. The print stops because the filament sensor is not sure if there is filament so it stops, moves the filament back and forth and determines that there is filament. At that point it tries to continue, but for some reason it just goes crazy and overshoots.
Maybe running in stealth mode just uncovers a flaw in the filament check resume for the MK3 because it is triggered more often because of the reduced acceleration (just a theory)