-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Stopping print from menu on Ender-3 V2 fails, sometimes results in SD card filesystem destruction #19608
Comments
This is normal since the default If you want to disengage the steppers too, you need to add #define EVENT_GCODE_SD_ABORT "G28XY\nM84"
Have you tried a different SD card to rule out a bad card? |
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.
|
@CRCinAU Have you heard of any users experiencing these issues on the Ender-3 V2? |
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. |
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... |
I had a chance to look at the code and it appears that the following patch will correct the problem:
|
Faster if you submit a PR with the changes |
Thanks for the patch! This screen needs all the love it can get. |
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. |
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.
The text was updated successfully, but these errors were encountered: