Crash on Bed MAXTEMP but it was normal
I recently assembled a new MK3S printer. First two small prints were fine. I tried printing a larger model and it has crashed twice. First was a communication error in the log with Octoprint on a Raspberry PI4. I turned on serial logging in Octoprint and this time it halted on MAXTEMP for the bed, but the temperature was normal right before the crash. I turned the printer back on and the bed holds temperature normally.
The print was run on SD card and I was using Octoprint just for monitoring. The RP4 has a local LCD display and I connect from my PC. Used Prusa Slicer to create the gcode.
Here is the log right before the crash:
2020-09-04 17:08:10,799 - Recv: ForceBabyYoda_Repair_0.1mm_PLA_MK3S_10h34m.gcode
2020-09-04 17:08:10,803 - Recv: SD printing byte 5046363/46626695
2020-09-04 17:08:10,804 - Recv: 01:26
2020-09-04 17:08:10,806 - Recv: ok
2020-09-04 17:08:11,174 - Send: M105
2020-09-04 17:08:11,306 - Recv: ok T:210.2 /210.0 B:59.9 /60.0 T0:210.2 /210.0 @:98 B@:46 P:33.4 A:39.9
2020-09-04 17:08:11,689 - Send: M27
2020-09-04 17:08:11,916 - Recv: ForceBabyYoda_Repair_0.1mm_PLA_MK3S_10h34m.gcode
2020-09-04 17:08:11,917 - Recv: SD printing byte 5047916/46626695
2020-09-04 17:08:11,918 - Recv: 01:26
2020-09-04 17:08:11,920 - Recv: ok
2020-09-04 17:08:12,690 - Send: M27
2020-09-04 17:08:12,929 - Recv: ForceBabyYoda_Repair_0.1mm_PLA_MK3S_10h34m.gcode
2020-09-04 17:08:12,932 - Recv: SD printing byte 5048546/46626695
2020-09-04 17:08:12,934 - Recv: 01:26
2020-09-04 17:08:12,936 - Recv: ok
2020-09-04 17:08:13,690 - Send: M27
2020-09-04 17:08:13,854 - Recv: ForceBabyYoda_Repair_0.1mm_PLA_MK3S_10h34m.gcode
2020-09-04 17:08:13,858 - Recv: SD printing byte 5049806/46626695
2020-09-04 17:08:13,858 - Recv: 01:26
2020-09-04 17:08:13,859 - Recv: ok
2020-09-04 17:08:14,691 - Send: M27
2020-09-04 17:08:14,825 - Recv: ForceBabyYoda_Repair_0.1mm_PLA_MK3S_10h34m.gcode
2020-09-04 17:08:14,829 - Recv: SD printing byte 5051261/46626695
2020-09-04 17:08:14,830 - Recv: 01:26
2020-09-04 17:08:14,831 - Recv: ok
2020-09-04 17:08:15,692 - Send: M27
2020-09-04 17:08:15,779 - Recv: ForceBabyYoda_Repair_0.1mm_PLA_MK3S_10h34m.gcode
2020-09-04 17:08:15,783 - Recv: SD printing byte 5052521/46626695
2020-09-04 17:08:15,784 - Recv: 01:26
2020-09-04 17:08:15,785 - Recv: ok
2020-09-04 17:08:16,175 - Send: M105
2020-09-04 17:08:16,295 - Recv: ok T:209.9 /210.0 B:59.9 /60.0 T0:209.9 /210.0 @:104 B@:40 P:33.3 A:39.8
2020-09-04 17:08:16,554 - Recv: echo: 3.9.0-3421
2020-09-04 17:08:16,562 - Recv: echo: Last Updated: May 18 2020 17:11:15 | Author: (none, default config)
2020-09-04 17:08:16,563 - Recv: Compiled: May 18 2020
2020-09-04 17:08:16,566 - Recv: echo: Free Memory: 1675 PlannerBufferBytes: 1792
2020-09-04 17:08:16,570 - Recv: echo:Hardcoded Default Settings Loaded
2020-09-04 17:08:16,571 - Recv: adc_init
2020-09-04 17:08:16,693 - Send: M27
2020-09-04 17:08:16,909 - Recv: CrashDetect ENABLED!
2020-09-04 17:08:18,020 - Recv: FSensor ENABLED (sensor board revision: 0.4 or newer)
2020-09-04 17:08:18,208 - Recv: Sending 0xFF
2020-09-04 17:08:18,216 - Recv: echo:SD card ok
2020-09-04 17:08:18,736 - Recv: Not SD printing
2020-09-04 17:08:18,737 - Recv: ok
2020-09-04 17:08:18,738 - Send: M27
2020-09-04 17:08:18,740 - Recv: Error:Temperature heated bed switched off. MAXTEMP triggered !
2020-09-04 17:08:18,769 - Recv: // action:cancel
2020-09-04 17:08:18,771 - Changing monitoring state from "Printing from SD" to "Error: Temperature heated bed switched off. MAXTEMP triggered ! - // action:cancel"
2020-09-04 17:08:18,781 - Send: M112
2020-09-04 17:08:18,782 - Send: N3 M112*34
2020-09-04 17:08:18,784 - Send: N4 M104 T0 S0*37
2020-09-04 17:08:18,785 - Send: N5 M140 S0*96
2020-09-04 17:08:18,790 - Changing monitoring state from "Error: Temperature heated bed switched off. MAXTEMP triggered ! - // action:cancel" to "Offline (Error: Temperature heated bed switched off. MAXTEMP triggered ! - // action:cancel)"
2020-09-04 17:08:18,798 - Connection closed, closing down monitor
Any suggestions? Why is it polling firmware info?
Thanks!
RE: Crash on Bed MAXTEMP but it was normal
Update: I tried printing again with Octoprint off and it stopped not very long into the print but no errors listed on the LCD display.
RE: Crash on Bed MAXTEMP but it was normal
Turns out that the Einsy board was bad causing random crash resets. The replacement board works great! No crashing.
RE: Crash on Bed MAXTEMP but it was normal
Good to hear you have it running again.
--------------------
Chuck H
3D Printer Review Blog