[BUG] Marlin stops/stuck saying "Media Inserted" or "Printing" randomly

[Stefar77]

Bug Description

When printing larger prints the printer randomly stops. (SKR 1.3, tested with all A4988 drivers and TMC5161 drivers)
I went from Marlin 1.9 to Marlin 2 because I switch from RAMPS 1.4 to SKR 1.3 and not I cannot print bigger works anymore.

• With 2.0 it stops with "Printing..." on the display and with -bugfix I noticed it says "Media Inserted" on the display when it happens.
• With endFilePrint(); line removed it has not stopped yet; (even after removing the SD a couple of times)
  Still testing and switched back the 5161 drivers again because that clearly wasn't the issue.

Configuration Files

config.zip

• Only fixed the 5161 driver templates and debugging but when it randomly stopped with no further information in the TMC drivers with larger prints I reverted back to the cheap drivers but still have the same problem so it's not related to the drivers.

Steps to Reproduce

Print something big and wait for it to fail. (last fail cost me ~0.5 kilo filament)
Edit: Just tested and you can reproduce fast and easy by printing something and re-seat the SD card.

Expected behavior:
Stops moving axis after a random amount of time, hotends stays hot.
TFT still works, connecting to serial still works, I can pause in this state and movement works but it will never unpause.

Expect the firmware to give some sort of error and disable the hotend at least, this is a fire hazard!

** Probably related **
#15337, #17161 [both are closed but seem like the same issue]

[Stefar77]

Marlin/src/sd/cardreader.cpp
void CardReader::release() {
endFilePrint(); <-- Removing this line fixed my problem (I think)

Maybe make this function run on a timer ~1 second after it detected removal of the card so if it's a misread of the detect pin or something it recovers and when someone does remove the card it should stop after a second or 2 with an error message on the LCD and maybe ask to resume.

[Stefar77]

Currently switched back the TMC5161's and printing some tests.

• Edit: Currently still printing but apparently the SD card has disconnected again..
  

[boelle]

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

[Stefar77]

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

-- Noticed I uploaded the older config files only

I'm running bugfix-2.0.x at the moment with the change mentioned above, without it it fails pretty much every long print.
config.zip <-- config I;m using in bugfix-2.0.x at the moment.

Current print had already failed because apparently this Chinese display is a piece of crap and the long flat cables don't help.

[rhapsodyv]

Your problem is related with SD_DETECT_PIN. You are using SD from LCD, that uses EXPA2_04_PIN (P1_31) pin. I would say you have an electrical or cable issue, because the state of the SD_DETECT_PIN is changing in the middle of the print.

Try commenting SD_DETECT_PIN on Marlin/src/pins/lpc1768/pins_BTT_SKR_V1_3.h, line 289.

If it works, try checking everything related with that PIN and with the cable. Try using onboard SD to check if the problem happens too.

[Stefar77]

Your problem is related with SD_DETECT_PIN. You are using SD from LCD, that uses EXPA2_04_PIN (P1_31) pin. I would say you have an electrical or cable issue, because the state of the SD_DETECT_PIN is changing in the middle of the print.

Try commenting SD_DETECT_PIN on Marlin/src/pins/lpc1768/pins_BTT_SKR_V1_3.h, line 289.

If it works, try checking everything related with that PIN and with the cable. Try using onboard SD to check if the problem happens too.

It's the SD card for sure, just finished a pretty long print without issues.

But it's still an issue that Marlin just does the endFilePrint(); and that doesn't disable the hotend or put an error on the display like 'Interrupted' or something. Also it's still in half printing state because you have a pause and stop option. Pressing the pause makes it say Pause but you cannot un-pause.

You can test this by starting a print and removing the SD card for just a second.

[rhapsodyv]

Marlin is calling endFilePrint() because SD_DETECT_PIN is telling Marlin that you don't have any SD inserted, and a cycle after, it is telling the you have the Media Inserted. The problem is not endFilePrint(), is SD_DETECT_PIN issuing wrong values during the print.

And Marlin wasn't supposed to have the SD removed during a print. It will let Marlin with wrong states in memory. I don't think we need to handle that. You can fill an issue about that, but it's really look like a corner case.

[sjasonsmith]

@rhapsodyv I’m going to reopen this. I agree that if the firmware is aware enough to stop the print on SD removal, it should also probably turn off heaters.

[Stefar77]

@rhapsodyv I’m going to reopen this. I agree that if the firmware is aware enough to stop the print on SD removal, it should also probably turn off heaters.

Thanks! I agree. At least if there is an LCD put an error message "Print interrupted" or something.
And it does leave Marlin in a invalid state, if you remark the endFilePrint() maybe it's leaking some filedescriptors but at least it doesn't crash for up to 9 hours if someone happens to get a cheap Chinese display. :-)

Ps. It's not that big of a deal because I'm buying a quality screen later but good error handling is pretty important specially if you are printing something that costs 2 kilo of filament and someone pulls the card for just a second by accident....

[rhapsodyv]

@rhapsodyv I’m going to reopen this. I agree that if the firmware is aware enough to stop the print on SD removal, it should also probably turn off heaters.

endFilePrint is not "I'm printing, I need end a printing". It is: "I just need to turn off flags of sd printing". It's called always that you removed the SD card, even if you are printing using serial. So we can't just disable the heaters in this method. We can check for sd printing, but we depend on sd detect and it impossible to handle any serial print.

I closed that issue, because that issue is a false alarm. And just said that I don't think we need handle bad hardware. But I also said that if the user want, he can open a issue about that. I just think that this thread already have too much confusion for the issue that we are taking about.

So, I really think it should be closed, and any other issued opened.

[rhapsodyv]

Our best bet for that is turning on HOTEND_IDLE_TIMEOUT. It will stop heaters when hotend stay idle for some timeout. It solves the SD card removal, disconnection when printing over serial and any other type of printing interruption.

@Stefar77 Did you try HOTEND_IDLE_TIMEOUT?

[sjasonsmith]

@rhapsodyv pointed out that this is already reported and has been discussed in another issue, I will close this as a duplicate.

[sjasonsmith]

Duplicate of #15390

[Stefar77]

Our best bet for that is turning on HOTEND_IDLE_TIMEOUT. It will stop heaters when hotend stay idle for some timeout. It solves the SD card removal, disconnection when printing over serial and any other type of printing interruption.

@Stefar77 Did you try HOTEND_IDLE_TIMEOUT?

It was indeed still disabled by default and I forgot to enable it and makes this less of a fire hazard. 👍
However I don't like the lack of feedback when something stops the printer and the state it enters when it has an SD card issue or 'accident'.

I started out suspecting the TMC drivers at first because I've seen a lot of people using them having the same issues.
The lack of feedback from the printer is the worst issue, if it says "SD Card error" when it stops it would be so much easier troubleshooting if your printer stops after 2 days of printing and you wasted half a kilo of filament because you think you fixed your driver issue.

[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.