[FR] Allow POWER_LOSS_RECOVER_ZHOME and Z_SAFE_HOMING to work

[moham96]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

Hi
I enabled POWER_LOSS_RECOVER_ZHOME while enabling Z_SAFE_HOMING which caused this error POWER_LOSS_RECOVER_ZHOME cannot be used with Z_SAFE_HOMING.
So I understand that these settings can't be enabled simultaneously because the printer can't ensure that the Z homing will not collide with the model, unfortunately for my setup enabling these settings at the same time is necessary because my X gantry always falls a few millimeters down after the power is lost which causes wrong z height when the print resumes.
So I changed the homing positions to a safe position where it doesn't collide with the model

 #define Z_SAFE_HOMING_X_POINT 0
 #define Z_SAFE_HOMING_Y_POINT 10

And disabled that error in the SanityCheck.h file

The firmware compiles fine now, but the resume function doesn't work properly:

After triggering the power loss function using the POWER_LOSS_PIN the printer homes two times(which is weird) and then the print starts from a higher layer than what it was before power loss (i.e if the printer stopped at 0.2 z height it would resume at 0.6 z height)

Bug Timeline

not sure

Expected behavior

I would expect the printer to home once and then continue the print exactly where it left of in X, Y, Z axis.

Actual behavior

The printer is resuming the print job where it left of in the X and Y axis but is the position is not correct in regards to the Z axis

Steps to Reproduce

1- enable the POWER_LOSS_RECOVERY settings as follows:

  #define POWER_LOSS_RECOVERY
  #if ENABLED(POWER_LOSS_RECOVERY)
    #define PLR_ENABLED_DEFAULT   true
    #define BACKUP_POWER_SUPPLY       
    #define POWER_LOSS_ZRAISE       5 
    #define POWER_LOSS_STATE     HIGH
    #define POWER_LOSS_PULLDOWN
    #define POWER_LOSS_PURGE_LEN   10 
    #define POWER_LOSS_RETRACT_LEN 10
    #define POWER_LOSS_MIN_Z_CHANGE 0.05
    #define POWER_LOSS_RECOVER_ZHOME
    #if ENABLED(POWER_LOSS_RECOVER_ZHOME)
      #define POWER_LOSS_ZHOME_POS { 0, 10 } 
    #endif
  #endif

2- enable Z_SAFE_HOMING and set the safe position similar to POWER_LOSS_ZHOME_POS, also comment out this line to be able to compile.
3- Start a print job and when it starts printing trigger the power loss by shorting the POWER_LOSS_PIN to vcc(take note of the current Z height before triggering the power loss)
4- Restart the printer and click resume

5- You will notice that the printer homes twice and and start printing in the wrong height.

Version of Marlin Firmware

Marlin bugfix-2.0.x (Sep 12 2021 21:53:19)

Printer model

Creality Ender 3

Electronics

BigTreeTech SKR 1.4 with TMC 2209s

Add-ons

BLTOUCH

Bed Leveling

UBL

Your Slicer

Cura

Host Software

OctoPrint

Additional information & file uploads

Configurations.zip

[moham96]

It looks like the problem is introduced in this commit.
The double xyz homing is happening because both of these lines are getting executed

Marlin/Marlin/src/feature/powerloss.cpp

Line 413 in 8df3e62

gcode.process_subcommands_now_P(PSTR("G28R0" TERN_(HOME_XY_ONLY, "XY"))); // No raise during G28

Marlin/Marlin/src/feature/powerloss.cpp

Line 420 in 8df3e62

sprintf_P(cmd, PSTR("G1X%sY%sF1000\nG28Z"), dtostrf(p.x, 1, 3, str_1), dtostrf(p.y, 1, 3, str_2));

[moham96]

Ok maybe the second problem is not with power loss because each time i turn on the printer and start a print i have to change the z probe offset (The offset is saved to EEPROM correctly but i have to increase it or decrease it after each power off/power on to have the correct layer height) this seems related to #22322

On the other hand i discovered a new issue: after resume, the printer homes, turn on heaters, purges filament, return back to the saved position, but then it retracts a bit of filament while moving the head which causes a gap in the model ( this retract is proportional to the start move i.e if the first move after resuming is a long line then the retract is long, if the first move after resume is a small move between two points then this retract is short, in other words it seems that somehow the XY movement is being used also for E!) , should i open a separate issue for this ? maybe it's caused by this line

Marlin/Marlin/src/feature/powerloss.cpp

Line 545 in 718227a

sprintf_P(cmd, PSTR("G92.9E%s"), dtostrf(info.current_position.e, 1, 3, str_1));

[thinkyhead]

It looks like the problem is introduced in this commit.

No. This is a feature request, not a bug report. It has never been possible to do safe-homing of Z during resume from power-loss, because that would likely crash into the print, unless the Z safe homing point was set to an edge point. The new feature POWER_LOSS_RECOVER_ZHOME adds a position where Z can be homed during resume, but since G28 Z always uses the Z safe homing position when Z_SAFE_HOMING is enabled, that point is superseded. This feature request is simply requesting that compilation of Power-Loss Recovery to be allowed (via some new option setting) when Z_SAFE_HOMING is enabled and set to some point near the edge of the bed, instead of just emitting an #error that forbids it.

[thinkyhead]

should i open a separate issue for this ?

Yes! Adding comments here ends up sending email notifications to the person who posted the feature request, so please be courteous and create a new bug report. Or, better, we can just work on that issue as part of #22828.

[resimkulubu]

I have bltouch on my printer and when I enable Power Loss Recovery, as soon as it switches to printing, I get this error: reset the printer and start printing.
skr 1.4 turbo
tmc 2209
bigtreetech tft 3.5- v3

When Power Loss Recovery is turned off, it smoothly bed-levels and switches to printing. please do not give up your support
Marlin-bugfix-2.0.x.zip

When I make the settings like this, it works, but it starts printing from the beginning.

#define POWER_LOSS_RECOVERY
#if ENABLED(POWER_LOSS_RECOVERY)
#define PLR_ENABLED_DEFAULT false // 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_ZRAISE 2 // (mm) Z axis raise on resume (on power loss with UPS)
#define POWER_LOSS_PIN -1 // Pin to detect power loss. Set to -1 to disable default pin on boards without module.
//#define POWER_LOSS_STATE HIGH // 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.

[resimkulubu]

Yazıcımda bltouch var ve Güç Kaybı Kurtarma'yı etkinleştirdiğimde, yazdırmaya geçer geçmez şu hatayı alıyorum: yazıcıyı sıfırlayın ve yazdırmaya başlayın. skr 1.4 turbo tmc 2209 bigtreetech tft 3.5- v3

Güç Kaybı Kurtarma kapatıldığında, sorunsuz bir şekilde düzleşir ve yazdırmaya geçer. lütfen desteğinizden vazgeçmeyin Marlin-bugfix-2.0.x.zip

Ayarları bu şekilde yaptığımda çalışıyor ama baştan yazdırmaya başlıyor.

#define POWER_LOSS_RECOVERY #if ENABLED(POWER_LOSS_RECOVERY) #define PLR_ENABLED_DEFAULT false // Güç Kaybını Kurtarma varsayılan olarak etkindir. ('M413 Sn' & M500 ile ayarlayın) //#define BACKUP_POWER_SUPPLY // Güç kaybında stepperleri hareket ettirmek için yedek güç / UPS //#define POWER_LOSS_ZRAISE 2 // (mm) Devam ederken Z ekseni yükselmesi (UPS ile güç kaybında) ) #define POWER_LOSS_PIN -1 // Güç kaybını algılamak için pin. Modülsüz kartlarda varsayılan pini devre dışı bırakmak için -1'e ayarlayın. //#define POWER_LOSS_STATE HIGH // Güç kaybını gösteren pin durumu //#POWER_LOSS_PULLUP tanımlayın // Pullup / pulldown'ı sensörünüze uygun olarak ayarlayın //# POWER_LOSS_PULLDOWN tanımlayın //#define POWER_LOSS_PURGE_LEN 20 // (mm) Devam ederken temizlenecek filamentin uzunluğu //#define POWER_LOSS_RETRACT_LEN 10 // (mm) Başarısız olduğunda geri çekilecek filamentin uzunluğu. Yedek güç gerektirir.

Why is no one supporting?

[thisiskeithb]

Fixed/implemented in #22828

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