[BUG]Recovery From Power Panic Crashes on the Bed

[sarf2k4]

MK3S
3.14.0

MMU3
3.0.2

printed via Octoprint

Describe the bug
The print job just completed and the printer executing the end gcode sequence and there were short power outage. After a brief power outage that has like 1 second of outage, power panic triggers on my prusa printer, The printer tried to recover the remaining progress, that is I think supposed to be the start of end-gcode sequence. The behavior weren't acceptable a the printer tried to home in all 3 axis, however the printer disregards the trigger from pinda and crashed to the bed., back up, then crashes on to the bed again. Even after pressing the emergency stop/reset button on under the knob, the printer persists and crashes to the bed, back up, then crash again. After the crashing to the bed sequence, the printer regards as print paused.

To Reproduce
Wasn't sure how to produce, perhaps trigger the power panic when the printer is printing via octoprint perhaps? I'm not risking damaging my bed

Expected behavior
The prusa shouldn't home in z axis when doing power panic

G-code
I have Power Failure Recovery plugin installed on my octoprint with the following gcode, "Automatic Restart" were unchecked

Heating:
;M80 ; power on printer
M140 S{bedT}
M104 S{tool0T}
M190 S{bedT}
M109 S{tool0T}

XY Homing
G21 ;metric values
{klipper_z}
{enable_z}
G90 ;absolute positioning
G28 X0 Y0 ;home X/Y to min endstops

Z-Homing
G92 Z{adjustedZ} ;set Z with any homing offsets
;M211 S0 ; Deactive software endstops
G91 ;relative positioning
G1 Z-{z_homing_height} F200 ; correcting Z_HOMING_HEIGHT
G90 ;absolute positioning
;M211 S1 ; Activate software endstops

Extrusion/Priming
M83
G1 E{prime_len} F100
G92 E0
{extrusion} ;captured from gcode, M82 or M83
G1 X{last_X} Y{last_Y} F{xy_feed}; move to last known XY
;fan state, extruder reset, feedrate and linear advance settings will be injected here

Video
https://github.com/user-attachments/assets/8d57234f-94e6-4365-8ca7-4506acf73d34

Additional Note
I don't think the Power Failure Recovery plugin i the main culprit of such behavior since the "Automatic Restart" were unchecked and most of their settings are left untouched

[3d-gussner]

@sarf2k4 Thanks for the feedback.
I have not been able to reproduce your issue yet.

Do I understand it correctly:

• OctoPrint with PowerFailure Plugin
  • This Plugin works differently than PrusaLink 0.8.1 and Prusa Connect, it saves every x seconds the last known line
  • PrusaLink 0.8.1 after a power failure waits for the printer to report its state and in case of a powerpanic PrusaLink requests some information from the printer where it failed and recovers the PL print.
• Nearly at the end of the print you had a power outage
• Printer homes x and y
• Then it moves down and hits the bed.

Do you have the https://plugins.octoprint.org/plugins/ActivatePrusaHostTimer/ installed and active?
This Plugin ensures that the printer "knows" that the host is online and ready to receive data after a power panic event.

Here is what I think happened:

• After power panic the printer recovers with the Z height at 37.33 (video at 00:04)
• The Plugin injects some gcode
  • it homes x and y with G28 X0 Y0
  • sets with G92 Zxxx.xx to an different value than 37.33
  • changes to relative mode with G91
  • moves Z with G1 Z-xxx.xx some value down. And here it crashes into the bed.
    • Side note the PINDA is only used during homing and mesh bed leveling otherwise it would/may trigger at the first layer of prints. So it doesn't "protect" the printer to move down if instructed. Normally the printer would prevent to go below Z 0.00, but as the Plugin modified the "know" Z position and also change to relative mode it follows "blindly" the instructions.

In my opinion this is not an issue with the printer firmware but with the Plugin.

Ideal would be if the OctoPrint Plugin would work the "same" as PrusaLink 0.8.1 and requests after the power panic the saved values from the printer and then sends the correct instructions.

Removed the bug lable as I couldn't reproduce this issue and it looks like the OctoPrint Plugin sent the instructions which the printer just executed.

Without serial.log file it is hard impossible to see what really happened.

[sarf2k4]

I believe the "power failure recovery" were left untouched and the "auto restart" were unchecked. though I am still unsure if this plugin will inject anything as I don't turn on serial logging all the time; not recommended by octoprint. And this also one of unexpected event. Murphy's law?

it could be that the power panic occured during the lift z by x amount of mm during the end gcode sequence, power outage occured, where the z should lift by 20mm+ but interrupted during the power outage.

I never heard of "Activate Prusa HostTimer" until now. should i remove "power failure recovery" plugin?

in my own opinion regarding this event, even though it may not be a bug, at least put another layer of safety such that the z axis will not go any lower when the pinda has been triggered, not just rely on the soft limit of current z axis position. i believe there are gcodes to ignore those soft limits.

How about something like a soft interrupt for pinda, when issuing a M120, the soft limit/interrupt of pinda being triggered will be ignored or turned off. or another new gcode to turn off z axis soft limit, independent of turn off M120 perhaps.

[3d-gussner]

it could be that the power panic occured during the lift z by x amount of mm during the end gcode sequence, power outage occured, where the z should lift by 20mm+ but interrupted during the power outage.

I have been testing a lot and the power panic saves the current positions even it is moving up. You also can see in your video that at 00:04 it shows Z33.33. Without the logfiles and reported positions M155 S1 C5 it is hard to tell what happened.

I never heard of "Activate Prusa HostTimer" until now. should i remove "power failure recovery" plugin?

If you are using OctoPrint to stream gcode to the MK3S printer I would suggest that you install and active it. Then the printer "knows" that the host is still up and running.
Another suggestion is to add to OctoPrint Settings -> GCODE Scripts
-> Before print job start: M75
-> After print job completes: M77
-> After print job is cancelled: M603 and M77
-> After print job is paused: M601 and M76
-> Before print job is resumed: M602 and M75
See https://reprap.org/wiki/G-code#M75:_Start_the_print_job_timer what M75-M77 do, these are also used to update the print statistics if you print from a host like OctoPrint.

I can't give you any advice on the power failure recovery plugin.
Best advise I can give is to print from SD card as the PowerPanic there works the best and is most reliable.
You can still use OctoPrint to "monitor" the SD card print. Only issue with that is that OctoPrint connected via USB port by default resets the printer, so if your RPi also crashed and auto reconnects it will reset the printer. Workaround it to deactivate the reset when USB connection is established but when you want to update the firmware you need to re-enable it to be able to flash the firmware from PrusaSlicer. There is even an OctoPrint Plugin for that https://plugins.octoprint.org/plugins/PrusaResetMode/

Another option would be to use PrusaLink 0.8.1 and PrusaConnect but that is up to you, but also here I personally prefer to print from SD and just use PrusaLink as central monitoring platform.

SD card prints can recover from power panic automatically when the bed temperature didn't drop too low and you never notice the issue.

[sarf2k4]

Thank you for the octoprint gcode scripts, a lot has changed ever since.

That's the thing about the actual z axis vs reported z axis. The brief power outage perhaps happened during the z lift at the "end gcode" sequence where it instructs the printer to go to the target, but power outage in the middle, so the printer's firmware perceived it as the actual z axis already at the target.

I still think adding a layer of prevention on z axis slamming on the bed should be added and this should prevent further damage to the heatbed, doesn't matter in which scenario we are in, except M120 or similar has been issued.

I don't have any sd card reader either.

[3d-gussner]

I don't have any sd card reader either.

You should get one 😉 these are cheap.

May I ask in which region your are located, which AC voltages you have and if you have "often" power outages?

[sarf2k4]

I don't have any sd card reader either.

You should get one 😉 these are cheap.

May I ask in which region your are located, which AC voltages you have and if you have "often" power outages?

i'll consider about the sd card reader. i was waiting for a microsd to sdcard adapter that features male usb directly on to it. so far i found nothing

i live on 240v region, where they claimed the electricity are their pride,yet there are some outages, maybe 5-12 times a year. as mentioned previously, murphy's law

[sarusani]

Just a small input. You can upload your files to the SD card via OctoPrint and then print from SD. No SD card reader required.

[3d-gussner]

Just a small input. You can upload your files to the SD card via OctoPrint and then print from SD. No SD card reader required.

Uploading via a serial line with 115200 baud is very very slow!

[github-actions]

Thank you for your contribution to our project. This issue has not received any updates for 60 days and may be considered "stale." If this issue is still important to you, please add an update within the next 7 days to keep it open. Administrators can manually reopen the issue if necessary.

[github-actions]

This issue has been closed due to lack of recent activity. Please consider opening a new one if needed.