[BUG] Stopping print from menu on Ender-3 V2 fails, sometimes results in SD card filesystem destruction

[signetica]

Bug Description

Stopping a print from the menu doesn't stop the print properly, leaving the stepper motors engaged. Removing the SD card after stopping the print will leave the SD card unusable until it is reformatted.

My Configurations

The configuration files are the stock files released for the latest release, in the distributed
Configurations-release-2.0.7, from examples/Creality/Ender-3 V2/.

This problem is present in 2.0.7 and also in the latest bugfix-2.0.7 branch.

Steps to Reproduce

After starting a print, use the menu to stop the print.

The extruder will return to home, stop for a moment, and then return to the print and stop once more. The stepper motors will remain engaged.

One can successfully manually disengage them using the appropriate menu item.

If one then removes the SD card the bed will move forward and the extruder will move to the far left, as is generally done after finishing a print. However, the card will no longer be readable as the filesystem will have been overwritten; it will need to be reformatted with a new FAT32 filesystem.

[thisiskeithb]

Stopping a print from the menu doesn't stop the print properly, leaving the stepper motors engaged.

This is normal since the default EVENT_GCODE_SD_ABORT code is G28 XY. But it's odd that it homes X & Y and then returns to the print. Are you printing from a host or just via SD?

If you want to disengage the steppers too, you need to add M84 so it'll look like:

#define EVENT_GCODE_SD_ABORT "G28XY\nM84" 

However, the card will no longer be readable as the filesystem will have been overwritten; it will need to be reformatted with a new FAT32 filesystem.

Have you tried a different SD card to rule out a bad card?

[signetica]

The previous release I was using, which came with the printer, would move the extruder clear of the print and stop there. The return to the print is new. I'm quite sure that stopping a print (in that release) from the menu disengaged the motors, but I'll check again. I am printing from an SD card, with no other connection to the printer. It's also new to have the printer begin moving again while inactive when I remove the card - it usually would only react to a card removal event if it was still engaged in printing anytime before the final click on the menu confirming that the print was finished. Since this only is a problem with this release of Marlin and the card acts normally on other devices and on earlier releases of Marlin, it's probably not the card. If I don't abort the print the problem does not occur. I'll try the previous release to see what happens, and I will communicate the results. Thanks.

…

On Sat, Oct 3, 2020 at 7:57 PM Keith Bennett ***@***.***> wrote: Stopping a print from the menu doesn't stop the print properly, leaving the stepper motors engaged. This is normal since the default EVENT_GCODE_SD_ABORT code is G28 XY. But it's odd that it homes X & Y and then returns to the print. Are you printing from a host or just via SD? If you want to disengage the steppers too, you need to add M84 so it'll look like: #define EVENT_GCODE_SD_ABORT "G28XY\nM84" However, the card will no longer be readable as the filesystem will have been overwritten; it will need to be reformatted with a new FAT32 filesystem. Have you tried a different SD card to rule out a bad card? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[thisiskeithb]

@CRCinAU Have you heard of any users experiencing these issues on the Ender-3 V2?

[signetica]

I've tested various versions of Marlin and have information about them, but I am unable to draw any firm conclusions.

The Creality firmware versions (both 1.x and 2.x) respond to a stop request from the menu by raising the extruder, homing in the x-y plane, disengaging the motors, and turning off the heaters. Removing the SD card at this point causes no response. The data on the card is not overwritten when the card is removed.

On Marlin 2.0.6.1 and 2.0.7, the stop request causes the extruder to rise slightly and home in the x-y plane. It then stops briefly, and it sounds as if the stepper motors are disengaged. Then they re-engage, the extruder is sometimes brought to 0 in the z direction, and then it is always returned to the point in the x-y plane where it was when the stop request was made. Sometimes the stepper motors are disengaged at this point and sometimes they are not.

At any time after this point, if the SD card is removed the extruder is brought up and to the left, and the plate is moved forward. The motors are kept engaged. The filesystem on the card is sometimes damaged.

I was unable to build earlier versions of Marlin because of various problems related to the incompatibility of the versions of various packages. I was unable to build Creality's version of the firmware for the same reasons. So I'm unable to easily figure out why Creality's firmware behaves differently.

To venture a guess about what's happening, I'd say perhaps there is a process that periodically writes to the SD card while a print operation is in progress. Removing the card while the print operation is in progress causes the extruder to rise and the plate to move forward, and if the write is in progress sometimes the SD card is left in an unusable state.

And this is a problem because asking the printer to stop from the menu doesn't completely stop the print operation. Either this is a problem that developed after Creality's latest release or they have corrected the problem on their own and the fix has not made it into the repository.

Hope this helps - let me know if I can provide more information.

[CRCinAU]

@CRCinAU Have you heard of any users experiencing these issues on the Ender-3 V2?

I have heard reports of the printer hanging after aborting a print from the SD Card via the screen and needing a reboot to be able to use the printer again - however I haven't been able to confirm or deny either way...

I haven't heard about the SD Card corruption parts - but it may well be related or similar...

[signetica]

I had a chance to look at the code and it appears that the following patch will correct the problem:

diff --git a/Marlin/src/lcd/dwin/e3v2/dwin.cpp b/Marlin/src/lcd/dwin/e3v2/dwin.cpp
index 85263a89a..11f8c3f57 100644
--- a/Marlin/src/lcd/dwin/e3v2/dwin.cpp
+++ b/Marlin/src/lcd/dwin/e3v2/dwin.cpp
@@ -2215,14 +2215,12 @@ void HMI_PauseOrStop() {
           checkkey = Back_Main;
           // Wait for planner moves to finish!
           if (HMI_flag.home_flag) planner.synchronize();
-          card.endFilePrint();
+          card.flag.abort_sd_printing = true;
+          marlin_state = MF_SD_COMPLETE;
           #ifdef ACTION_ON_CANCEL
             host_action_cancel();
           #endif
-          #ifdef EVENT_GCODE_SD_ABORT
-            Popup_Window_Home(true);
-            queue.inject_P(PSTR(EVENT_GCODE_SD_ABORT));
-          #endif
+          Popup_Window_Home(true);
           dwin_abort_flag = true;
         #endif
       }

[boelle]

Faster if you submit a PR with the changes

[thinkyhead]

Thanks for the patch! This screen needs all the love it can get.

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