[BUG] Marlin crashing at the end of print on Anycubic Kossel Plus

[vonfuri]

Bug Description

At the end of each print from SD card, printer seems to software crash.

Printer: Anycubic Kossel Linear Plus Electronics: Stock parts, Trigorilla 1.1 board FW: Marlin 2.0 with bug fixes // Downloaded on 29.02.2020

My Configurations

Configurations.zip

Steps to Reproduce

1. Start a print from SD card
2. Wait until it finishes

Expected behavior: [What you expect to happen] 3.1 Print should finish normally and end gcode execute without printer crashing.

Actual behavior: [What actually happens] 3.2 Printer software crashes during some stage of end gcode, parts always finish printing.

Additional Information

There are 3 kinds of crashes I have identified:

1. Printer does not execute end gcode and crashes
2. Printer executes part of end gcode and crashes
3. Printer executes whole end gcode and crashes

Each of these different crashes leads to one of the following things:

• with bomb-like ticking sound which is continued by continuous beeping sound which reminds me most of "flatlining" sound. (most common)
• simply by getting stuck on LCD without anything updating (happened couple times during troubleshooting) (silent crash)

• going to the "loading screen" where it just shows the bars (second most common) on at least part of the screen, sometimes whole screen.

All of these software crashes end up to same result: printer not responsible to commands, power cycling it off/on again makes it work normally until next print finishes. Sometimes the printer seems to halt at the point where it starts executing the End Gcode, and at other times it finishes the end Gcode before crashing. Parts always print complete before crash occurs.

Upon inspecting the crashing event via serial monitor on most reproduced tries: it's usually either unreadable symbol mess when the crash happens and on some occasions I have been able to get this out of it: " Error:Heating failed, system stopped! Heater_ID: 0 Error:Printer halted. kill() called! "

Following steps have been taken to confirm it's not caused by them: -Tested 3 different slicers (Cura 4.4.1, Cura 4.5, Prusaslicer 2.1.1) -Reflashed firmware -Tested same same gcodes with stock firmware from Anycubic. No crashing. -Checked the thermistor wires and connectors to be okay -Reformatted the SD card, sliced new files and safely ejected it. -Tested with another known good SD card. -Tested with several different end gcodes to confirm they are not the cause. -Printing from PC via USB does not result in printer crashing

Footage of one crash happening: https://youtu.be/RUkSf1Vlpaw

[ellensp]

Can you attach a short example gcode that fails? Want to run it on test machine see if I can replicate a crash.

[ellensp]

The sounds in youtube is identical to a heating error. Which is followed by printer halted. These are normally both displayed on LCD and console. but not for you apparently.

[ellensp]

I would defiantly try the current bugfix, as many bugs have been found and fixed.

[vonfuri]

Can you attach a short example gcode that fails? Want to run it on test machine see if I can replicate a crash.

Here's a gcodes which i've tested to lead to a failure from SD card: First file X_level had my old (bad end gcode which had mistake with retraction) second file D_DD007 has fixed end gcode and they both lead to same crashes. crashing gcodes.zip

[rado79]

there are more then one M104 S0 and M140 S0 commands in your endscript. you can try to erase the duplicates and put it once at the end of your endscript.

;TIME_ELAPSED:406.962071
G1 F4200 E552.54077
**M140 S0
M104 S0
M140 S0**
G1 E-1 F300
G91
G1 Z50 F3600 ; move 50mm to the right of the current location
G1 X50 F3600
M84
M82 ;absolute extrusion mode
**M104 S0**
;End of Gcode

;TIME_ELAPSED:932.287570
G1 F4200 E986.33613
**M140 S0**
M107
G1 Z50 F3600 ; move 50mm up
G1 X50 F3600 ; move 50mm right
M83
G1 E-1 F300 ;retract fil
**M140 S0**
M107
**M104 S0**
M84
M82 ;absolute extrusion mode
**M104 S0**
;End of Gcode

[vonfuri]

there are more then one M104 S0 and M140 S0 commands in your endscript. you can try to erase the duplicates and put it once at the end of your endscript.

Hey! Indeed - like I stated in my earlier post I had bad end gcode originally, this has now been fixed. It seems like CURA 4.5 is adding extra things there as failsafe (namely M107 M104 S0 as print ends) before my "manual" end gcode starts on the second one. Curious. But wasn't the cause of crash as prusa slicer sliced files also result in crashes :/

End gcode i'm using currently(it's the D_DD007.gcode file in zip):

G1 Z50 F3600 ; move 50mm up
G1 X50 F3600 ; move 50mm right
M83
G1 E-1 F300 ;retract fil
M140 S0
M107
M104 S0
M84;

[sjasonsmith]

I had reproduced this issue using his bed leveling print, but won’t have time until at least next week to investigate further. I didn’t have a serial connection active to observe prints, but there was no beeping. Just a delay then a reboot.

[RasmusAaen]

I have the same problem. Running bugfix-2.0.x from today on a SKR_GEN_L (mega2560). This gcode will make the printer freeze at the end of the print:

M140 S60 ; bed temp
M104 S205 ; extruder temp
G28 ; home
M190 S60 ; wait for bed temp
M109 S205 ; wait for extruder temp
G1 X-5.0 Y-5.0 F3000.0 ; go home
G1 Z5 F1000 ; Raise nozzle when heating
G92 E0.0 ; reset extruder
G1 X110 Y110 F2000
M104 S0 ; turn off temperature
M140 S0 ; turn off heatbed
M107 ; turn off fan
G1 Z20.2 ; Move print head up
G1 X10 Y210; home X axis
M84 ; disable motors

The problem only occurs when printing the file from the SDCard. I can print it without problems through Pronterface. The freeze happens before the G1 Z20.2 command. Most of the time the printer is stuck until I manually reset or power cycle it, but once in a while it will reset by itself. There is no output on the serial console.

[Azrael321]

Config.zip

Hi there, ich have the same problem. I'm using Marlin 2.0 with bug fixes from today. I have an MKS Gen L Board.

This is my End Script:

M104 S0          ; turn off extruder
M140 S0          ; turn off bed
G91              ; relative positioning
G1 E-1 F300      ; retract the filament a bit
G1 Z+1 F1000     ; move Z up a bit
G90              ; absolute positioning
G28 X0 Y0        ; home XY
G1 Y190 F5000    ; use this line if you want the bed to move to the front. delete if not.
M107             ; shut off fan
M18 S30          ; disable all steppers after 30s

After the G28 command, my Printer performs a soft restart

Edit: i added my config files.

[thinkyhead]

If your BUFSIZE is set to 4 (I'll check your configs) then I suspect Marlin is probably crashing at the moment that the last command is read. The end-of-file code has been modified recently, so we can try reverting some of those changes until we find the culprit.

[RasmusAaen]

Yep - BUFSIZE is 4:

// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
#define BUFSIZE 4

Anything we can do to test/verify?

[nalimcos]

I've been having end-of-print crashes too on a MKS Gen L board (silent crashes only though).

EVENT_GCODE_SD_STOP was "G28 X Y\nG0 X230 Y-30", switching to "G27" seems to have solved the problem for me. (However, I made other changes to my configuration so I can't be sure) BUFSIZE is 4 here too.

[timberwolfl]

End of print crashes for me too on Creality V2.2 board

[thinkyhead]

EVENT_GCODE_SD_STOP is probably the problem, since injecting g-code always comes with caveats. I'll see what's up with it.

EDIT: Hmm… While EVENT_GCODE_SD_STOP could have issues, it only applies to an aborted print, not a normal print completion.

[nalimcos]

Oh right, sorry. The other things I remember changing were classic jerk vs junction deviation, s-curve acceleration, and linear advance. I'm probably still missing something...

[Azrael321]

Since my last comment, i printed some parts and the fault is a little bit different. Half of the time after G28 the printer performes a soft restart. And the other times it just freezes, so i need to do a hard restart.

[donniebergh]

Hello-

I have the same problem - this may help:

When the SD Print completes the firmware re-boots and I sometimes get the thermal error on the extruder just prior to the re-boot. On long prints I noticed at about 96% complete the extruder/bed heaters get set to 0, I start getting a message (several messages) in the serial monitor (Repetier Host) saying "Not SD printing". Printing continues and when the last line is printed the re-boot occurs. The last line homes the X axis.

I too have had the code just lock up at the end of printing and I have to reset the controller. But not all of the time - may one third of the time.

I've traced the message to "cardreader.cpp" about line 587. It appears to me that the print status gets turned off before the print is complete.

My controller is a "HICTOP 3D Printer Control Board MKS Base V1.3 RepRap Arduino-Compatible Mother Board". I using the "Marlin bugfix-2.0.x" firmware code. The previous "Marlin-1.1-5" firmware worked just fine and I have been using it for a while.

I use Simplify3D to perform the slicing, I use "Repetier Host" to monitor the prints and I always print from an SD card.

[donniebergh]

This too may help -

I loaded the non-bug fix Marlin 2.0 code and ran Azrael321 test from above and captured the Repetier logs:

Note the G28 worked and the bed did move per the "G1 Y190 F5000" line of code.

Logs3.txt

[thinkyhead]

with bomb-like ticking sound which is continued by continuous beeping sound

That is a thermal runaway.

simply by getting stuck on LCD without anything updating

For reference, the normal behavior is to end the print and wait for a click. The "Click to resume" message is suppressed so the print time will still be displayed.

Anything we can do to test/verify?

Yes. The problem is probably in some aspect of finishSDPrinting. It starts to run as soon as the SD file is done streaming and works asynchronously to try to get all the final tasks completed at the right point. Test #17082 to see whether it helps.

[nalimcos]

I'll test it too over the next few days, as I found my printer in a rather sorry state this morning - after successfully finishing a print:

• The bed moved down until it crashed and the steppers started missing steps
• The hotend kept heating; Marlin read 298C after reset, although printing temp was 210C
• The extruder also kept running until the material degraded from the heat and clogged the nozzle.

The uncaught thermal runaway is pretty concerning.

End Gcode:

G0 X230 Y-30 F18000
M104 T0 S0
M104 T1 S0
M140 S0 ; turn off heat bed
M84     ; disable motors

Config: config-nalimcos-endcrash.zip

Marlin version: 2.0.4.4

[thinkyhead]

The uncaught thermal runaway is pretty concerning.

Definitely. The check for over-temperature which should kill the machine is fairly simple. Please test to see if you can induce a thermal runaway at all. Re-compile with the max temp set to something low and easy to reach and if it fails to trigger then we'll have to add logging and see where it's losing track.

Marlin read 298C after reset, although printing temp was 210C

It sounds like a case of the heater being stuck on after Marlin had crashed or gotten stuck in a loop. Temperatures should surely be getting turned off before the point where Marlin is adding M33 onto the end of the queue. For setups with LED lighting the closing code also adds an M0 command. And for everyone it includes M33 to show the total print time on the screen.

[donniebergh]

I have been doing some debugging of Marlin 2.x and I have the following observations-

I think Marlin 2.x is processing GCode out of sequence - see the screen shot attached. It appears G0-G1 codes go into a queue for processing. And all other codes get actuated on immediately.

For example - my test GCode file has some ending code to turn off the heaters, display a message, wait a bit (10 seconds) and display another message. I put some debug displays in the Marlin code and discovered my end code is being process as soon as it read off the SD Card - not at the end of print processing.

I observed that when the LCD display shows about 97% - the heaters get turned off while the print is still being performed. When the print finishes my first message appears, the 10 second dwell happens but the second message is not displayed. At the end of the dwell one of several events occur:

1- Thermal error - maybe because the temperature was set to zero way too soon. 2- The firmware locks up the printer and I have to do a hard reset. 3- The firmware reboot the printer.

-- Sometimes any of these events trashes the EEPROM and I have to clear it.

Looking at the screen shot I've noted when the M104 gets processed while the printing process is still in operation. The display "Donnie sees temperature change - 0" is a debug statement I put in temperature.h at about line 634.

There seems to have a problem with Marlin code in the past handling synchronizing commands and may be related to these issues. I found this article from about 2015:

https://github.com/MarlinFirmware/Marlin/issues/2125

I have also attached the log file.

The "startOrResumeJob" route seems to be being called at the end of the logs just before the software crashes.

Another oddity I noticed is "relative extrusion" no longer works. That may also be a result of Marlin not processing GCode in the proper order.

Logs9.txt

[thinkyhead]

It appears G0-G1 codes go into a queue for processing. And all other codes get actuated on immediately.

That is correct. A movement command is "completed" when it is queued. To wait for the actual movements to complete you must use M400. This is well documented but users new to 3D printing may need to be reminded.

[thinkyhead]

discovered my end code is being process as soon as it read off the SD Card - not at the end of print processing.

Sometimes this is wanted. This is why the firmware supplies M400 to wait for moves in the planner to complete. If your ending G-code very much depends on moves being completed, you should insert M400 at the top. Some commands do this on their own, but not all can be guaranteed to do so.

[thinkyhead]

Another oddity I noticed is "relative extrusion" no longer works. That may also be a result of Marlin not processing GCode in the proper order.

Relative / Absolute mode is applied at the high level to G0/G1/etc commands as they arrive, so there is no issue there. We have this very well established. Welcome to Marlin.

The previous issue with commands being injected at the wrong point at the end of the SD card print has been addressed in the current bugfix branch. The "immediate queue" was being used (which sends commands to the command processor directly, ahead of the regular queue) and it needed a more sophisticated approach.

The current method waits for a signal from the cardreader that the job is complete, and then places commands in the regular command queue. The SD card reader places commands in the queue as it reads them, and there is no backing buffer. So we know at the end of the SD card job that the last command read from the file has previously been placed in the queue.

[donniebergh]

I have been printing with Marlin 1.x (version less that 2.0) for years (about 6 years) with "relative extrusion" on and no M400 code. So I see these two items as new requirements - if so I can live with them.

I have tested with "relative extrusion" off and an M400 GCode line in the end script. The print finished properly without a thermal over run - but moments later the firmware still crashed and rebooted the printer.

I put in a few more debugging displays and attached a snippet of the log in case it will help figure the crashing.

logs.txt

[thinkyhead]

Please test the current bugfix-2.0.x to see whether SD print completes without crashing.

[vonfuri]

Please test the current bugfix-2.0.x to see whether SD print completes without crashing.

Testing, will report back asap.

Edit: Print 1: 6 minutes, finishes print normally, does not crash and goes to click to resume confirmation.
Print 2 15 minutes, finished normally. Confirmation boxes are magic! Print 3 30mins, finished normally. Print 4-6 1h each, finished normally

On my part I would consider it fixed based on these quick tests, I'll wait to see more comments from other users suffering from this and run some more prints myself to be sure before I'll close the issue. Being very hopeful that it's sorted now!

Big thank you to everyone who's helped with troubleshooting and fixing this issue! Success logs.txt

[donniebergh]

I was using about a week old bug fix as the the current bug fix is/was confused about the status of the SD card. Yesterday's bug fix thinks the SD is present when it is not and vice versa.

But the latest bug fix code works - hooray!!!

[trustfm]

I can confirm that i have the same problem with vonfuri using the 2.0.4.4 version

[JonathanMurray272]

Ended up here while trying to determine what was causing the same error running 2.0.4 on my Ender 5 Pro. Current bugfix installed, problem has been resolved. Thank you very much!

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.