How to continue playing more elegantly

mcu(stm32h723xx)
Version: v0.13.0-976-gf7955b1a

Load: 0.00, Awake: 0.00, Freq: 520 MHz, Temp: 37°C

mcu CB2(linux)
Version: v0.13.0-957-gc9e917a1f

Load: 0.02, Awake: 0.00, Freq: 50 MHz,

mcu EBBPLUS(stm32g0b1xx)
Version: v0.13.0-976-gf7955b1a

Load: 0.01, Awake: 0.00, Freq: 64 MHz,

Host(aarch64, 64bit)

Version: v0.13.0-1060-g045b5b7c7-dirty

OS: Debian GNU/Linux 12 (bookworm)

Distro: HuaiOS 2.2.2 (bookworm)

Load: 0.21, Mem: 351.1 MB / 1.6 GB , Temp: 38°C

wlan0 (192.168.3.224) : Bandwidth: 3.6 kB/s , Received: 646.0 kB , Transmitted: 5.5 MB

can0 : Bandwidth: 0.3 kB/s , Received: 279.7 kB , Transmitted: 25.6 kB

During the use of the device, if there is a power outage or a shortage of materials, it is necessary to add a follow-up process. Has anyone encountered this situation? Is there a more elegant way to operate on the upper computer? For example, measuring the height of the current printed file based on the floor height Height Can two parameters be input into the corresponding file to achieve the function of continuous printing? The current situation involves deleting GCODE code based on these two parameters in the computer to achieve continuous printing, which feels quite cumbersome. Is it feasible to implement this function on the upper computer?

I googled ‘Klipper print recovery’, and found a couple github links that might be useful or work for you. I have no experience with these and cannot suggest any. But here’s the first three I found.

Good luck!