[BUG] SD-Card removal during print stalls printer with heaters on

[asko58]

This thread is related to my previous post, as can be seen here:

#15337

I have been able to track down the error, it seems to be a faulty connection or software error that makes Marlin unable to read the SD card for a few moments. As I have mentioned the heaters stay on and do not shut off. I have now reproduced the behaviour on SKR 1.3 and I think this is a severe security issue (possible fire hazard):

How to reproduce

• use Marlin 2 (mine is from early 09/2019) on SKR 1.3
• print from SD card
• remove SD card while printing
  (optional: - re-plug SD card)

expected behavior:

• Marlin detects removal and throws an error/ shuts down system and heaters OR
• Marlin continues as soon as file on SD is readable again

actual behavior:

• Marlin just stalls/stops, heaters stay on forever

[AnHardt]

As long as the heaters are still regulated i'm not very scared. The filament will be cooked in the nozzle - that's all.

[Haxk20]

As long as the heaters are still regulated i'm not very scared. The filament will be cooked in the nozzle - that's all.

While this is true its still not good. Imagine doing a big print overnight and the printer does this and will just put a nice glob of plastic over your nozzle which isnt nice either. Now heating the PLA for that long time can produce fumes which arent exactly healthy.

[asko58]

As long as the heaters are still regulated i'm not very scared. The filament will be cooked in the nozzle - that's all.

While this is true its still not good. Imagine doing a big print overnight and the printer does this and will just put a nice glob of plastic over your nozzle which isnt nice either. Now heating the PLA for that long time can produce fumes which arent exactly healthy.

That is just my opinion. I definitely think the system should not go into a loop with heaters on.

[Haxk20]

@asko58 The printer shoudlnt go into the loop the first place.
The SDcard has not been taken out so i expect the printer to print just fine.
Weird is that it does this same thing even over USB prints.
So basically the printer is unusable until bug #15337 is still opened and not fixed.

[asko58]

Interesting that you are experiencing the problem over USB. So the SD card can not be the only problem...

Anyhow: Although I don't have a deep insight into Marlin code, I tried to track down the SD issue. Please feel free to confirm or correct me if I'm wrong.

• when Marlin loses connection to the card the LCD's OnMediaRemoved() event is called
• that again calls the extensible's handling methods e.g.

void DGUSScreenVariableHandler::SDCardRemoved() { if (current_screen == DGUSLCD_SCREEN_SDFILELIST || (current_screen == DGUSLCD_SCREEN_CONFIRM && (ConfirmVP == VP_SD_AbortPrintConfirmed || ConfirmVP == VP_SD_FileSelectConfirm)) || current_screen == DGUSLCD_SCREEN_SDPRINTMANIPULATION ) ScreenHandler.GotoScreen(DGUSLCD_SCREEN_MAIN); }

As far as I can see this piece of code just goes back to the main screen but does not trigger any other events. I do not understand the communication between ScreenHandler and Marlin main code (does sendInfoScreen trigger events via memory addresses?), but comparing it to

void DGUSScreenVariableHandler::SDCardError() { DGUSScreenVariableHandler::SDCardRemoved(); ScreenHandler.sendinfoscreen(PSTR("NOTICE"), nullptr, PSTR("SD card error"), nullptr, true, true, true, true); ScreenHandler.SetupConfirmAction(nullptr); ScreenHandler.GotoScreen(DGUSLCD_SCREEN_POPUP); }

I think the last piece of code does call events.

The question now is: Ain't there a way the removed event could set the SD's flag card.flag.abort_sd_printing? That way Marlin's loop() code would stop the print, wouldn't it?

---

Possible temporary workaround:
Including a M85 S30 command at the start of the printing process (before first real printing move) should make the printer shut down when the command queue gets stuck for more than 30 seconds.

[Haxk20]

Interesting that you are experiencing the problem over USB. So the SD card can not be the only problem...

Anyhow: Although I don't have a deep insight into Marlin code, I tried to track down the SD issue. Please feel free to confirm or correct me if I'm wrong.

* when Marlin loses connection to the card the LCD's OnMediaRemoved() event is called

* that again calls the extensible's handling methods e.g.

void DGUSScreenVariableHandler::SDCardRemoved() { if (current_screen == DGUSLCD_SCREEN_SDFILELIST || (current_screen == DGUSLCD_SCREEN_CONFIRM && (ConfirmVP == VP_SD_AbortPrintConfirmed || ConfirmVP == VP_SD_FileSelectConfirm)) || current_screen == DGUSLCD_SCREEN_SDPRINTMANIPULATION ) ScreenHandler.GotoScreen(DGUSLCD_SCREEN_MAIN); }

As far as I can see this piece of code just goes back to the main screen but does not trigger any other events. I do not understand the communication between ScreenHandler and Marlin main code (does sendInfoScreen trigger events via memory addresses?), but comparing it to

void DGUSScreenVariableHandler::SDCardError() { DGUSScreenVariableHandler::SDCardRemoved(); ScreenHandler.sendinfoscreen(PSTR("NOTICE"), nullptr, PSTR("SD card error"), nullptr, true, true, true, true); ScreenHandler.SetupConfirmAction(nullptr); ScreenHandler.GotoScreen(DGUSLCD_SCREEN_POPUP); }

I think the last piece of code does call events.

The question now is: Ain't there a way the removed event could set the SD's flag card.flag.abort_sd_printing? That way Marlin's loop() code would stop the print, wouldn't it?

Possible temporary workaround:
Including a M85 S30 command at the start of the printing process (before first real printing move) should make the printer shut down when the command queue gets stuck for more than 30 seconds.

Screen.GotoScreen is the function that switches the screen so its most likely that that functions calls some event. I havent took a look at marlin code ever so cant say for sure.

[asko58]

Can any of the experts confirm the problem is caused by missing commands in the firmware?

[thinkyhead]

Seems right to me that a "mysteriously lost" SD card (or SD detect pin changing state) should trigger at least a PAUSE with PARK and timed cooldown, and perhaps a complete shutdown (KILL) if the machine is not attended-to within a reasonable timeframe.

[asko58]

If you gave me a hint on the how Marlin deals with a lost card (events called) I'd be happy to give it a try.

[boelle]

@asko58 still an issue?

[InsanityAutomation]

Yes, and some card refactoring is planned so it doesnt make sense to change before thats done.

[thinkyhead]

If you gave me a hint on the how Marlin deals with a lost card (events called) I'd be happy to give it a try.

If an SD_DETECT_PIN is defined and the card is removed, that can be responded to with pause, if available, and a shutdown otherwise. And if there's no detect pin, when the printer is SD printing it can take note whether a long period of time has passed since the last command arrived from the SD card and pause in response to that.

[boelle]

@InsanityAutomation is the card refactor still in the works?
@thinkyhead so this pause thing is in place the user just have to set it up?

[InsanityAutomation]

Nothing is in place for it at the moment. Work needs to be done but we've been busy with other commitments.

[Haxk20]

Still an issue.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[jagoosw]

I've just started looking to solve this and am confused as to why it doesn't work already. On line 1315 in MarlinCore.cpp in the main loop the SD status is checked and "abortSDPrinting" is called which seems to shut down everything including the heaters unless its disabled.

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[rhapsodyv]

Today another user with similar issue. Looking at marlin options, I think the best approach for any printing interruption is just use HOTEND_IDLE_TIMEOUT. It will handle any type of printing (serial, sd, with and without sd detect pin), and it will protect the printer.

[Stefar77]

This one is almost more then a year old?! It only took me more then 15 minutes to find this bug because I was unsure why it was stopping without any feedback to the user and I fist suspected the TMC controllers because I needed to finish the drivers a bit.
The moment I realized what was happening I removed the endFilePrint(); from the release function and it fully solved my issues.

People having this issue should just remark the endFilePrint(); in Marlin/src/sd/cardreader.cpp under void CardReader::release(){
It maybe isn't the best solution however after loosing half a kilo of filament after 2 days of printing I got pretty pissed at Marlin 2.x and worst case scenario the printer keeps some file descriptors open when your SD card is a bit buggy.

Since I removed that line prints don't fail anymore even if I remove the SD card a couple of times during a print.
Yesterday I already noticed my display changing from "Printing" to "Media Inserted" so it already saved me once for real!

So basically if you pull the SD card for 1 second with endFilePrint() active, Marlin just sits there in a invalid state for ever and menu still think it's printing.

[rhapsodyv]

I just sent a fix to abort the printing, if card is removed during a printing from SD.

[rhapsodyv]

The fix was merged. I will close this.

[Stefar77]

I just sent a fix to abort the printing, if card is removed during a printing from SD.

Does it put a message on the display when it stopped with the reason?
I was pretty mad about it because I thought I fixed my 'driver' issue and after 2 days of printing it failed on 90% of my print and it turned out not to be the drivers but the damn SD card reader.

Ps. Since I replaced my X stepper motor I haven't seen "Media Inserted" message yet, the stepper is a lot smaller and makes the printer vibrate a lot less when doing some parts of the infill... (but the stopping was pretty random so probably will see it again soon unless I fix it or replace the cheap display) haha
edit: Spoke to soon again, haha. It's probably the vibrations of the printer when jerking the Y axis so I may need to check the solder joints on the SD card reader later. For now I'm glad I remove the endFilePrint() call.

[github-actions]

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.