[BUG] Power loss recovery does not continue printing #19602

cguerrero1205 · 2020-10-03T16:34:39Z

Bug Description

My Ender 3 pauses after a power outage, heats the bed and nozzle, returns to where it was before the power outage, but the nozzle stays still at that point.

My Configurations

Marlin.zip

Steps to Reproduce

Start an impression.
I cut the power manually.
I turn on the machine again.
I click on "resume printing" in the " power loss recovery" menu.
The nozzle and bed begin to heat
After the temperature is reached, the nozzle moves to the point where it was before the power failure, but stays still at that point, the machine does not move anymore and on the LCD it says "printing", but I said before, the nozzle doesn't move anymore.

Expected behavior: Print needs to resume where it left off.

Actual behavior: It remains in an eternal pause.

Additional Information

Provide pictures or links to videos that clearly demonstrate the issue.
See How Can I Contribute for additional guidelines.

katherinehackworth · 2020-10-04T04:39:49Z

I was about to make an issue for the exact same problem. It seems like it only does a single print move after it resumes, and then hangs indefinitely. I'm on a SKR Mini E3 v1.2 with the BTT UPS 24V for power loss recovery, and it looks like you're on the stock board. Same exact issue here. Still looking around to see if this is an isolated thing or a bug in 2.0.7. I can add my config files if needed too.

cguerrero1205 · 2020-10-04T15:35:16Z

I was about to make an issue for the exact same problem. It seems like it only does a single print move after it resumes, and then hangs indefinitely. I'm on a SKR Mini E3 v1.2 with the BTT UPS 24V for power loss recovery, and it looks like you're on the stock board. Same exact issue here. Still looking around to see if this is an isolated thing or a bug in 2.0.7. I can add my config files if needed too.

Hi Katerine.
I've been checking the configuration of the Marlin I have loaded on my printer, but I can't find any problems. I even reloaded it with the sample configuration files for Ender 3, only activating the Power Loss Recovery, but I still have the same problem.

katherinehackworth · 2020-10-04T22:42:21Z

I've added my config files in a Gist here for posterity's sake.

cguerrero1205 · 2020-10-04T23:43:51Z

I will install some previous version of Marlin, to see if it solves the problem.

pkfloyd · 2020-10-05T09:16:30Z

hi,
have the tevo/homers tarantula pro, with MKS Lgen v1 and have de same problem.

cguerrero1205 · 2020-10-06T15:15:23Z

Hello.
I still can't solve the problem. How are you doing with the problem?

pkfloyd · 2020-10-06T18:42:30Z

hi,
i have change the powerloss.cpp and powerloss.h from marlin 2.0.6 to 2.0.7 and it work, now i have porwer_loss resume with no pin (always save in card)

cguerrero1205 · 2020-10-06T19:43:26Z

hi,
i have change the powerloss.cpp and powerloss.h from marlin 2.0.6 to 2.0.7 and it work, now i have porwer_loss resume with no pin (always save in card)

Great! I will try to do the same.

cguerrero1205 · 2020-10-06T19:47:53Z

Then the problem is in the PLR library. I will try to compare those libraries in Marlin 2.0.6 and 2.0.7, to find the error. Hopefully some official Marlin developer will see this thread and can help.

pkfloyd · 2020-10-06T20:22:48Z

i have tried to do this, but don´t now anything about coding :(

pkfloyd · 2020-10-08T18:22:39Z

hi, have you find the issue?

ths file change work?

cguerrero1205 · 2020-10-08T18:31:55Z

hi, have you find the issue?

ths file change work?

Hi, I have spent hours reviewing and comparing the powerloss files, but they made many modifications from version 2.0.6 to 2.0.7 and I haven't found the problem.
Likewise, I changed the files in the PLR library, but now the problem is that the Z axis starts from the wrong height.
As I said before: the hope is that some Marlin developer will see this thread, and hope that they will make some solution.
I've also been looking at the bugfix version, but so far they haven't talked about PLR.

pkfloyd · 2020-10-08T18:34:47Z

the two files, its only for PLR, why change your Z axis...? strange...

cguerrero1205 · 2020-10-08T18:39:30Z

the two files, its only for PLR, why change your Z axis...? strange...

Yes, I think it may be that, while the printer is off, the Z-axis goes down because the motor is not braked and that causes the position in the Z-axis to be lost.

At the moment, I have the printer running with PLR disabled, praying that the power does not cut again, as in recent days (I lost a print that took 20 of 22 hours).

Has PLR worked well for you after replacing the files?

pkfloyd · 2020-10-08T19:13:40Z

the test i made yes, work great.

i will test again.

it locks the ender 3 v2 with 2.0.7 have the same issue. lets wait for news.

cguerrero1205 · 2020-10-08T19:24:09Z

Yes, it's like I told you: between the changes they made from Marlin 2.0.6 to 2.0.7, it was in PLR, they changed a lot of things, I guess something went wrong. The strange thing is that until now we have very few people reporting that problem, I don't know if it is something that doesn't affect everyone at the moment of updating.

pkfloyd · 2020-10-08T20:07:01Z

maybe people don't notice.
after installing 2.0.7 teste printing and runout sensor. i notice PLR bug with some lucky on the beginning of piece.

borsegbr · 2020-10-09T01:52:21Z

Same problem with skr 1.4 turbo and btt tft35 v3.0

configs.zip

serial prompt say:

echo:Active Extruder: 0
M106 P0 S255
echo:Bed Leveling ON
echo:Fade Height 2.00
echo:Now fresh file: /LASER~1.GCO
open failed, File: LASER~1.GCO.
//action:resume

pkfloyd · 2020-10-09T07:06:48Z

More people with this issue. Ok, need to wait for correction.

thanks

borsegbr · 2020-10-09T09:23:52Z

in addition after abort resume serial say

Deletion failed, File: PLR.
Power-loss file delete failed.

and if i try to print from media is void i have to select change media couple of time and file appears
seems that sd is not correct inizialize in resume print procedure
maybe @thinkyhead that knows well code can help us

pkfloyd · 2020-10-09T18:00:27Z

hi, today a test again and its work fine the PLR, (i have change the powerloss.cpp and powerloss.h from marlin 2.0.6 to 2.0.7 ) and use vscode com compile.
i have mks Lgen 32bits board and use cura 4.7.1.

don't now anything about coding.. think i have luck with the file change.

borsegbr · 2020-10-09T23:22:26Z

hi, today a test again and its work fine the PLR, (i have change the powerloss.cpp and powerloss.h from marlin 2.0.6 to 2.0.7 ) and use vscode com compile.
i have mks Lgen 32bits board and use cura 4.7.1.

don't now anything about coding.. think i have luck with the file change.

not for me still not working with 2.0.6

cguerrero1205 · 2020-10-10T22:16:32Z

Today they made a PLR correction in the bugfix version. It's time to do a quick test to see if it solves our problem, although they don't mention anything about it.

#19676

pkfloyd · 2020-10-11T08:50:17Z

hi, never use a bug fix.
how cant a download and test to?

ellensp · 2020-10-11T09:13:15Z

@pkfloyd go to https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x click on big green CODE icon and download zip
Then update config file as needed. Compile and upload

borsegbr · 2020-10-11T19:55:54Z

Today they made a PLR correction in the bugfix version. It's time to do a quick test to see if it solves our problem, although they don't mention anything about it.

#19676

even worst, when i start printing any gcode lcd show resume from powerloss: 3d printer halted: please reboot

pkfloyd · 2020-10-15T20:24:14Z

hi, today i compile the marlin 2.0.7.1 and have the same issue.

PLR don't work. wend its turn on, say "resume" but nozzle go to piece and don`t move.

sjasonsmith · 2020-11-14T17:11:09Z

A pull request was merged 9 days ago that may resolve this. Please be sure to test with the latest bugfix-2.0.x code.

@Sergey1560 are you still working on finding a better solution?

swanlm · 2020-11-16T07:51:04Z

Just some feedback; I had exactly the same issue as described in this bug. Today I took the latest bug fix build and put this on my printer. I tested the power restore feature and

The nozzle lifts up as expected when power is removed
I am asked if I want to resume when power is switched back on
If I resume, the printer homes on X and Y, heats the bed and nozzle and then continues printing from where it left off.

So this looks to be fixed.

Sergey1560 · 2020-11-16T08:40:37Z

A pull request was merged 9 days ago that may resolve this. Please be sure to test with the latest bugfix-2.0.x code.

@Sergey1560 are you still working on finding a better solution?

Yes, I am trying to find the real reason.
The problem is somewhere in the file system with fileExist funciton, not in the "powerloss".

Aracos · 2020-11-19T10:16:16Z

Still got the same Problem ( Compiled the latest Bugfix yesterday ) for a Tronxy XY-2 Pro with V6 Board.
Goes to X Y Home, Heats up, then nothing. Touchscreen says printing.

borsegbr · 2020-11-19T10:31:54Z

#20035 (comment)
This for me fix the problem, now work well

Aracos · 2020-11-20T22:14:04Z

Yep. Fixed it for me too. Just found out i compiled the Release Version and not the Bugfix.

slgorin · 2020-11-22T23:37:13Z

no, still not fixed. When it resumes, it homes, raises z, the bltouch senses height on the part and when the print resumes, the z height is higher than where it left off and it does not stick to the part. have tried it twice with and without pause.

borsegbr · 2020-11-23T00:10:36Z

no, still not fixed. When it resumes, it homes, raises z, the bltouch senses height on the part and when the print resumes, the z height is higher than where it left off and it does not stick to the part. have tried it twice with and without pause.

this is not related to this issue

Marlina-Marlino · 2020-11-23T00:14:56Z

Hello
I have the same issue and I tried to figure it out.

My board is MKS SGEN L V1.0
Dirvers MKS TMC2209 V2.0
Marlin 2.0.7.1

I noticed that there is an option in Marlin 2.07 (Advanced Configurations) which is

#define SDCARD_CONNECTION LCD

if you specify the SDCARD location to be either onboard or in the LCD, I think this will solve the issue and help Marlin Firmware to get access to the PLR file

please use the same SDCARD SLOT you specified in your Marlin version
Please check and report back if the problem is solved

swanlm · 2020-11-23T06:24:05Z

Hi I have an SKR Mini E3 v2.0 and so specify: #define SDCARD_CONNECTION ONBOARD That was defined long ago and still the bug existed for me. So I don’t think this would be the solution. The latest bug fix with the workaround solves the problem for me.

…

On 23 Nov 2020, 02:15 +0200, Marlina-Marlino ***@***.***>, wrote: Hello I have the same issue and I tried to figure it out. My board is MKS SGEN L V1.0 Dirvers MKS TMC2209 V2.0 Marlin 2.0.7.1 I noticed that there is an option in Marlin 2.07 (Advanced Configurations) which is #define SDCARD_CONNECTION LCD if you specify the SDCARD location to be either onboard or in the LCD, I think this will solve the issue and help Marlin Firmware to get access PLR file Please check and report back if the problem is solved — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

boelle · 2020-11-23T09:54:26Z

Marlin 2.0.7.1

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.

boelle · 2020-11-23T09:55:24Z

@cguerrero1205 when will you be back?

cguerrero1205 · 2020-11-23T15:52:41Z

Hello.
I just got back yesterday.

I just loaded the Bugfix-2.0.x version and the problem is fixed, but I still don't know whether to close this thread, as @Sergey1560 is still investigating the origin of the problem. I think that if it were necessary to close it, @thinkyhead would have closed it when he made the correction in Bugfix-2.0.x.

sjasonsmith · 2020-11-23T17:16:33Z

Let’s give @Sergey1560 some time to investigate and get back. I believe the earlier fix was a workaround, without understanding or fixing the true root-cause.

Sergey1560 · 2020-11-24T08:49:52Z

I have not yet been able to find the exact problem, there is a slight lack of time for everything. But when it possible, I continue to work.

I have a suggestion. Maybe we should open a new issue, with a description of how to reproduce the problem in a simple way? This will possibly attract the attention of other developers. The problem is more important than it seems, it is not with the Power loss recovery module, but with the operation of the file system and may be reflected in the future in some other place.

The possible involvement of more experienced developers will help fix the problem faster.

How to reproduce the problem in a simple way, without need of Power loss recovery:

I add simple test function to Marlin/src/sd/cardreader.cpp:

// Test file read
void CardReader::check_file_read() {
  const char path[] = "/test.g";
  SdFile *diveDir;

  SERIAL_ECHOLN("Test read fucntion:");
  
  if(!card.isMounted()){
    card.mount();
  }
  
  const char * const fname = diveToFile(true, diveDir, path);
  if (!fname) return;

  if (file.open(diveDir, fname, O_READ)) {
    SERIAL_ECHOLN("First file open - Ok");
    file.close();
  }else{
    SERIAL_ECHOLN("First file open - fail");
  }

  if(fileExists(path)){
    SERIAL_ECHOLN("File exist");
  }else{
    SERIAL_ECHOLN("File not exist");
  }

  if (file.open(diveDir, fname, O_READ)) {
    SERIAL_ECHOLN("Second file open - Ok");
    file.close();
  }else{
    SERIAL_ECHOLN("Second file open - fail");
  }
}

This function is not for merge, just for testing the problem.

Revert Fix #19602 #20035, by uncommenting "diveDir->close();" in fileExists.
Add call of the card.check_file_read() somewhere. I add it in the end of setup().
Place file "test.g" and try it.

Output for me is:

Test read fucntion:
First file open - Ok
File exist
Second file open - fail

Crunch69 · 2020-12-02T22:44:31Z

I have been pulling my hair out for 2 days only to find many people are having the exact same problem

nvumnov · 2020-12-05T14:07:29Z

Isn't anyone interested in this problem. The long-standing problem has not yet been solved. By the way, bugfix also has this problem.

maxlinux2000 · 2020-12-07T23:07:57Z

still occurs on marlin 2.0.7.2

cguerrero1205 · 2020-12-07T23:14:35Z

Isn't anyone interested in this problem. The long-standing problem has not yet been solved. By the way, bugfix also has this problem.

The bugfix version should not present the problem, since they added the solution in one of their interactions.

cguerrero1205 · 2020-12-07T23:15:16Z

still occurs on marlin 2.0.7.2

Try with bugfix version

github051 · 2020-12-08T04:58:01Z

I tried with the latest bugfix version and the issue is the same.

borsegbr · 2020-12-08T07:34:52Z

Describe your issue and post configs file Il mar 8 dic 2020, 05:58 github051 <notifications@github.com> ha scritto:

…

I tried with the latest bugfix version and the issue is the same. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19602 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADAKLAQNFUHKRPDP3PSLC7LSTWW6NANCNFSM4SDBNIJA> .

github051 · 2020-12-13T09:40:19Z

I tried with the latest bugfix version and the issue is the same.

Finally, with the latest bugfix, power loss recovery is working fine. My board is MKS Robin v1.4 and to detect the power loss i'm using the MKS Power det module.

Here is my settings:
#define POWER_LOSS_RECOVERY
#if ENABLED(POWER_LOSS_RECOVERY)
#define PLR_ENABLED_DEFAULT true // Power Loss Recovery enabled by default. (Set with 'M413 Sn' & M500)
//#define BACKUP_POWER_SUPPLY // Backup power / UPS to move the steppers on power loss
//#define POWER_LOSS_RECOVER_ZHOME // Z homing is needed for proper recovery. 99.9% of the time this should be disabled!
//#define POWER_LOSS_ZRAISE 2 // (mm) Z axis raise on resume (on power loss with UPS)
#define POWER_LOSS_PIN PA2 // Pin to detect power loss. Set to -1 to disable default pin on boards without module.
#define POWER_LOSS_STATE LOW // State of pin indicating power loss
//#define POWER_LOSS_PULLUP // Set pullup / pulldown as appropriate for your sensor
//#define POWER_LOSS_PULLDOWN
#define POWER_LOSS_PURGE_LEN 20 // (mm) Length of filament to purge on resume
//#define POWER_LOSS_RETRACT_LEN 10 // (mm) Length of filament to retract on fail. Requires backup power.

// Without a POWER_LOSS_PIN the following option helps reduce wear on the SD card,
// especially with "vase mode" printing. Set too high and vases cannot be continued.
#define POWER_LOSS_MIN_Z_CHANGE 0.05 // (mm) Minimum Z change before saving power-loss data

#endif

github051 · 2020-12-13T10:07:10Z

I hope we can close this issue.

boelle · 2020-12-13T11:22:53Z

It seems this has been fixed in the bugfix version, all the other versions are just frozen copies of bugfix

will close this one, we can reopen if it can be demonstrated that the issue is still there

github-actions · 2021-02-11T14:05:23Z

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.

thisiskeithb mentioned this issue Oct 9, 2020

[BUG] No print after power loss procedure #19662

Closed

sjasonsmith added the F: Print Recovery label Oct 10, 2020

swanlm mentioned this issue Oct 13, 2020

[BUG] Power Loss Resume - Print Head does not move after resume #19725

Closed

boelle closed this as completed Dec 13, 2020

akurekin mentioned this issue Dec 18, 2020

SKR MINI E3 V2.0[BUG] (Power loss bigtreetech/BIGTREETECH-SKR-mini-E3#444

Open

mrv96 mentioned this issue Jan 9, 2021

[BUG] Power Loss Recovery doesn't works Desuuuu/Marlin#16

Closed

github-actions bot locked and limited conversation to collaborators Feb 11, 2021

[BUG] Power loss recovery does not continue printing #19602

[BUG] Power loss recovery does not continue printing #19602

Comments

cguerrero1205 commented Oct 3, 2020

Bug Description

My Configurations

Steps to Reproduce

Additional Information

katherinehackworth commented Oct 4, 2020 • edited Loading

cguerrero1205 commented Oct 4, 2020

katherinehackworth commented Oct 4, 2020

cguerrero1205 commented Oct 4, 2020

pkfloyd commented Oct 5, 2020

cguerrero1205 commented Oct 6, 2020

pkfloyd commented Oct 6, 2020

cguerrero1205 commented Oct 6, 2020

cguerrero1205 commented Oct 6, 2020

pkfloyd commented Oct 6, 2020

pkfloyd commented Oct 8, 2020

cguerrero1205 commented Oct 8, 2020

pkfloyd commented Oct 8, 2020

cguerrero1205 commented Oct 8, 2020 • edited Loading

pkfloyd commented Oct 8, 2020

cguerrero1205 commented Oct 8, 2020

pkfloyd commented Oct 8, 2020

borsegbr commented Oct 9, 2020 • edited Loading

pkfloyd commented Oct 9, 2020

borsegbr commented Oct 9, 2020 • edited Loading

pkfloyd commented Oct 9, 2020

borsegbr commented Oct 9, 2020

cguerrero1205 commented Oct 10, 2020

pkfloyd commented Oct 11, 2020

ellensp commented Oct 11, 2020

borsegbr commented Oct 11, 2020

pkfloyd commented Oct 15, 2020 • edited Loading

sjasonsmith commented Nov 14, 2020

swanlm commented Nov 16, 2020

Sergey1560 commented Nov 16, 2020

Aracos commented Nov 19, 2020

borsegbr commented Nov 19, 2020

Aracos commented Nov 20, 2020

slgorin commented Nov 22, 2020

borsegbr commented Nov 23, 2020

Marlina-Marlino commented Nov 23, 2020 • edited Loading

swanlm commented Nov 23, 2020 via email

boelle commented Nov 23, 2020

boelle commented Nov 23, 2020

cguerrero1205 commented Nov 23, 2020

sjasonsmith commented Nov 23, 2020

Sergey1560 commented Nov 24, 2020 • edited Loading

Crunch69 commented Dec 2, 2020

nvumnov commented Dec 5, 2020

maxlinux2000 commented Dec 7, 2020

cguerrero1205 commented Dec 7, 2020

cguerrero1205 commented Dec 7, 2020

github051 commented Dec 8, 2020

borsegbr commented Dec 8, 2020 via email

github051 commented Dec 13, 2020

github051 commented Dec 13, 2020

boelle commented Dec 13, 2020

github-actions bot commented Feb 11, 2021

katherinehackworth commented Oct 4, 2020 •

edited

Loading

cguerrero1205 commented Oct 8, 2020 •

edited

Loading

borsegbr commented Oct 9, 2020 •

edited

Loading

borsegbr commented Oct 9, 2020 •

edited

Loading

pkfloyd commented Oct 15, 2020 •

edited

Loading

Marlina-Marlino commented Nov 23, 2020 •

edited

Loading

Sergey1560 commented Nov 24, 2020 •

edited

Loading