[BUG] Slic3r PE power loss feature Z height bug

[yarus23]

Slic3r PE every layer raise Z by 0.4mm then move XY then returns it back. Something like that:

;BEFORE_LAYER_CHANGE
;Layer 184
;33.2mm
;Printing layer 184 at 33.2mm
G1 Z33.600 F12000.000
...
;AFTER_LAYER_CHANGE
;Layer 184
;33.2mm
;Printing layer 184 at 33.2mm


; PURGING FINISHED
G1 X115.369 Y102.090
G1 X116.743 Y102.206
G1 Z33.200

So to handle this we need in function save_job_recovery_info() in line 217

      // Save on every new Z height
      (current_position[Z_AXIS] > 0 && current_position[Z_AXIS] > job_recovery_info.current_position[Z_AXIS])

make current_position[Z_AXIS] != job_recovery_info.current_position[Z_AXIS]

This is actual for 2.0 too (line 137)

[boelle]

so this is a bug with slic3r PE?

[yarus23]

I suppose no because in Cura for example there is an option to increase Z while retracting so it is a bug of Marlin. It should save on every Z change

[boelle]

just trying to understand as i also use slic3r pe and no issue here

[yarus23]

Probably because if you save when Z 2mm higher it is Ok, so tests needed

[revilor]

There is a reason for not saving recovery info on every Z change (limited write cycles an SD card can handle during it's lifetime) so the line you call a bug is actually a feature. When you disable Z hop in your slicer the recovery file will be written on every layer change. With Z hop enabled the recovery file will be written when the first Z hop on a layer happens. Both ways there is one save point per layer and that's the intended behavior.

[yarus23]

Almost all modern memory cards can withstand at least 100,000 Program/Erase Cycles, and some cards can withstand as many as 10 times more cycles than standard cards. What this all means is that, according to the card manufacturers, you could fill a memory card every day for a couple decades without having any problems. All the card. And broken complex model on the other hand (my case) when Marlin cannot restore correctly. It is a bug, not feature, it cannot restore correctly in 50% cases. Why you name it feature?

[AnHardt]

I'm struggling to say it's meaningless, if the 'power loss recovery feature' is losing 2mm, 2 layers, 1/2 a layer or just the content of the planner buffer. It means it does not work without losses. At least not without investing major work.

But seemingly some can use this, as it is, to their advantage. So what we have is better than nothing.

There is a chance to make it perfect, but this will require: hardware power loss detection, some remaining power in the power supply, homing z to max and/or decelerated stop and saving/reloading the remaining planner buffer and submove.

[yarus23]

Yes, you are right, but 98% of cases user manually pauses the process, and 2mm leads to broken model

[AnHardt]

What i tried to tell you is:
The concept of 'power loss recovery feature' is deeply broken. After recovery you will always have a broken (functional) part. Don't use it - except in a real power loss - then, in a few cases, the result may look more or less acceptable.
Using 'power loss recovery feature' as a replacement for a 'pause' by will, for me, seems to be the pure madness.

[boelle]

i agree with @AnHardt, the only effectice thing to do is to get an UPS unit.

powerloss recovery will never work, as soon the bed is cold the print can release and you will have to start over

should you be able to get it printing before bed is cold the next problem is that it knows only what layer it was at and will start from there, maybe half that layers was printed and it will print again.... it will be a total mess

so far its only prusa that got it close to right on the mk3, and that is because mcu gets a signal as soon mains power is gone, at the same time bed is turned off autoamtic without the mcu does anything

the psu has enough power left that the printer can save it's precise location and move the nozzle away

even that will never be 100% correct, if its printing perimeter it can still be seen

@thinkyhead i think we can close this one as marlin is not at fault, we have firmware wise done the best we can

[yarus23]

98% os use cases of this code is not power loss but when user pause manually. Pause and powerloss code is mostly the same. If you do not want to make “pause” feature correct then why this code is in repository at all?

[thinkyhead]

98% os use cases of this code is not power loss but when user pause manually. Pause and powerloss code is mostly the same. If you do not want to make “pause” feature correct then why this code is in repository at all?

The age old question of how sausage is made…. Not in a way you want to witness.

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