Prusa-firmware: Print fails after "heating" (Axis crash & crash detection does not recover properly)

[uniacke1]

Running 3.5.2-RC1.

Just had a larger print fail in the same place twice due to what appears to be a firmware glitch. First all movement stops and the screen displays "heating", just like in #1521. Then when it resumes it just wanders off the print bed and crashes the axes.

I've verified the bug is not Slic3r as the gcode from both the release and current alpha are identical barring comment changes.

The offending G-code, STL, and some images are attached. The unusual thing is the print right before this was very similar in nature, but completed without issue. Failure happens on the second layer just as it gets close to the front right corner.

First image is the first attempt, was in silent mode so no crash detection. Second image was in normal mode and detected the crash but completely failed to resume correctly. Belts are good and tight so it is unlikely they are slipping during the crash.

File was re-sliced in between first and second prints to ensure it wasn't a bad file or G code glitch.

I'm flashing back to 3.5.1 and re-doing the print (thank goodness this is a $10 roll of filament and not something pricey!) to see if it persists.

Backtray.zip

[uniacke1]

Update: Just had it happen on the same gcode file (but different place, about halfway through the fifth layer) in 3.5.1. So there is something about this print that exposes a firmware glitch or problem with my printer.

[uniacke1]

Having thought about this some and considering others have seen heating without failure, I wonder if it re-executes the last G-code it was partway through when resuming. So if your print has lots of small steps and direction changes, it's not noticeable, but if it happens during a long straight shot (like my infill above) it makes the nozzle just wander off as it tries to re-do the part of the line it already completed.

[AnHardt]

That's very likely.
Haven't analysed Prusa-Firmware/Marlin cloth enough to be definitiv, but i do know MarlinFirrmware/Marlin.
There, not only the rest of the current move is lost, but the complete planner-buffer. (in emergency stop or power failure)

[inquisitiveKangaroo]

Hi,
thank you for the report, we appreciate it.
related with
Pause during print for heating #1521
3.5.2 heat bed temp fluctuations #1542

[ezeackermann]

the only firmware that work fine is 3.5.1. The next releases have the temperature fluctuation. Also I see that the heated bed are more time on with the latest releases. I see this in the powermeter of my UPS.

[tiboine]

I had this problem with FW 3.7 (MK3).
How is FW 3.7.2?

[ezeackermann]

I have the same issue when I print across all the bed (from left bottom corner to right up corner) 45 degrees. I think that is a problem with the calibration or with the limits of the bed. Also in the last print I receive the Heating message. Is true that here in Argentina this days are very cold, I don’t know if the room temperature have anything to do with it

[uniacke1]

I've not seen it anymore in 3.7.2 but in all fairness that's not conclusive - I disabled my filament sensor at the time and only re-enabled it now I'm running a skelestruder with redundant sensing (reads both filament and bearing. Bearing-only indirect mods would still give me false runouts). Feels like this is the way it was meant to work; runouts sense reliably and it's even noticed something was wrong during some heat creep jams. I'd hear it clicking and then checking the filament.

[kazibole]

I just experienced this today on an MK3 running firmware 3.7.2. The issue appears to be related to a false filament sensor runout detection and/or the filament sensor recovery. The serial terminal showed that the filament sensor gets triggered (this is when the LCD screen shows "Heating..."), performs the filament test, then recovers. However when it recovers it continues straight past where the print should end, almost as if it lost its current position or executed previous gcode that had already been executed. Or perhaps the filament sensor gets triggers in the middle of a straight line gcode, and upon the filament sensor recovery, it restarts that straight line gcode from the beginning instead of where it actually paused. In both my examples it reached the maximum build plate area and triggered a crash.

[jelson]

+1 -- I am consistently seeing this failure. The offending print looks very much like the one pictured above, i.e. a large rectangular area that nearly fills the print bed with 45-degree-angle fill. Several times during the 2nd layer, the printer pauses with "Heating...", and when it resumes it runs off the edge of the bed and crashes the head. This is with a Prusa i3 mk3, firmware 3.7.2-2363 and gcode from PrusaSlicer-2.0.0 win64-201905201652.

[wavexx]

@uniacke1 @kazibole A relevant PR which should fix the crashes has been merged. Are you able to test a build of the current FW in order to test it?

You might still see the filament sensor leaving marks, but it shouldn't crash anymore.

[uniacke1]

Sorry, wish I could help but I've since upgraded to the MMU2S which changed to an IR sensor.

[kazibole]

@wavexx I have since upgraded my MK3 to MK3S, so I don't know if I would be able to reproduce the issue.

[albjerre]

I have just had the same issue three times in a row. I re-sliced the print in between print 1 and 2. But the results were the same. The display didn't say "reheating" though as some other have mentioned. The print was fine until midway on the second layer. Then the printer suddenly stopped for a few seconds before moving on. It made the inconsistent lines you can see on the photo. It did that two or three times, until it at the last stopped suddenly moved very fast out to the edge of the build plate and crashed.
I am using Prusa Mk3, firmware 3.8.1, PrusaSlicer 2.2.9, Spectrum PETG filament, 0.2mm quality profile.

[wavexx]

Could you try with the latest 3.9.0 beta firmware?

[albjerre]

Turning off the filament sensor solved the problem for me.

[wavexx]

That's one solution, although we'd like to fix with with the filament sensor on :)

[acekrystal]

I have the same problem. I had the "heating" and pausing while printing already for a long time. But this is the first time I see him totally crashing into the sides of the max travel distance after continuing, or continue printing in totally the wrong places.

[albjerre]

@wavexx Yes, of course that would be better. Unfortunately I just don't have the time to fiddle with beta firmware.

[Jugsy]

Experiencing this exact issue on MK3 with 3.8.1

I'm trying with the filament sensor off to confirm, but I'll also try 3.9.0 with fil sensor on and report back