[BUG] Incorrect offset of extruder on Power loss recovery

[Abasz]

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

Yes, and the problem still exists.

Bug Description

When recovering the print on Ender 3 (4.2.2, 256k board) from the SD card, after selecting resume the extruder position offset is seemingly not being set properly as a significant amount (which depends on % of the print that has been completed) of filament gets extreded (making a huge blob).

Basically when the gcode tells the printer to move the extuder to position 4.5 from 4.4 on the next step as the extruder position known by the firmware seems 0, it actually turns the stepper motor 4.5 instead of 0.1.

After this is set, print continues as expected, this issue is only with start, nevertheless, ruining the print.

Bug Timeline

I have not fund reporst of this bug before

Expected behavior

I expected to continue to extruder from where it has been left off (i.e. relative to the old position) rather then relative to 0.

Actual behavior

A significant amount (which depends on % of the print that has been completed) of filament gets extreded (making a huge blob) on PLR resume.

Steps to Reproduce

1. Enable PLR in firmware
2. generate a power loss
3. resume

Version of Marlin Firmware

bugfix-2.0.x latest

Printer model

Ender 3 (2022 model, with 256k 4.2.2 board HR4988 driver)

Electronics

No response

Add-ons

No response

Bed Leveling

No response

Your Slicer

Cura

Host Software

SD Card (headless)

Additional information & file uploads

No response

[mehmetsutas]

I have been working on this issue for the last 3 days. I think the problem is as follows:

• Stepper ISR continuously records position to info.current_position.
• At power failure info is written to sd.
• On resume info is read from the sd and resume process starts
• On the resume process there are some moves and stepper isr records new positions to info again
• At the last lines of resume process, X and Y positioned and E position is set to the values of info.current_position. (But at this moment the info is not the data that is read from the SD PLR file. It was already updated by stepper isr with the last positions).

The problem is solved when the saved locations of x,y and e are read from info to temporary variables at the start of resume procedure as done for the Z position and SDPOS. (Tested)

@thinkyhead maybe above explanation may help for the solution. I did not want to mess up the code but the solution seems simple.

[github-actions]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[Abasz]

This is still an issue with the latest big fix

[github-actions]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

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