Best solution to recover a print half way though

Basic Information:

Printer Model: Custom DBOT style CoreXY
Printerboard: BTT Octopus 1.1
Host: Raspberry Pi 2 Zero W
klippy.log

klippy.log.zip (1.7 MB)

Describe your issue:

So I managed to cause my printer to fail half way through a 2 day print (I am aware of the issue, I did something stupid and don’t need to discuss why it happened further).

The print head is still in the same location where it failed. I have managed to extract the last position from the klippy log as 288.2102213884623, 99.97330646523385, 21.06093697280247 which appears to be correct.

My plan was to find the last processed GCODE line from the log file and then use that to cut away up to that line in the GCODE file, leaving in some of the start commands (this is what I usually do in Marlin or RepRap firmware).

Unfortunately, as Klipper reads the GCODE and then converts it to instructions to send to the main board, I cannot do this, so what would be the best way to determine the last GCODE command that was sent to the board, or at least, the last batch of GCODE commands?

I think I have managed to get pretty close by opening the GCODE in VSCode and then first finding the start of the layer Z21 and then stepping through the G1 commands from that point until I found a line that appears closest to the final co-ordinates.

This is OK I guess, but not perfect and pretty time consuming…

If anyone has any other ideas how I could make this a bit easier, that would be awesome :slight_smile:

From your log:

Virtual sdcard (107824347): ' E.01245\n;WIDTH:0.638804\nG1 F6554.352\nG1 X265.934 Y98.957 E.01172\n;WIDTH:0.609925\nG1 F6859.466\nG1 X266.238 Y98.879 E.01117\nG1 F6796.18\nG1 X266.495 Y98.873 E.00919\nG1 F6755.924\nG1 X267.055 Y98.995 E.02045\n;WIDTH:0.592176\nG1 F6933.669\nG1 X267.175 Y99.047 E.00452\n;WIDTH:0.578731\nG1 F7083.888\nG1 X267.295 Y99.1 E.00443\nG1 F6976.707\nG1 X268.514 Y99.892 E.04907\n;WIDTH:0.601258\nG1 F6599.766\nG1 X268.702 Y99.984 E.00735\n;WIDTH:0.553424\nG1 F7200\nG1 X268.889 Y100.077 E.00672\nG1 F7199.958\nG1 X269.478 Y100.23 E.01956\nG1 X269.773 Y100.237 E.0095\nSET_VELOCITY_LIMIT ACCEL=12000 ACCEL_TO_DECEL=6000\nG1 E-.7 F1800\nG1 X271.869 Y107.577 Z21.55 F30000\nG1 X273.358 Y112.792 Z21.55\nG1 Z21.15\nG1 E.7 F1800\nSET_VELOCITY_LIMIT ACCEL=8000 ACCEL_TO_DECEL=4000\n;WIDTH:0.786923\nG1 F5931.152\nG1 X273.501 Y112.974 E.0108\n;WIDTH:0.828823\nG1 F5608.65\nG1 X273.643 Y113.157 E.01138\n;WIDTH:0.870723\nG1 F5294.806\nG1 X273.786 Y113.339 E.01199\n;WIDTH:0.912624\nG1 F5013.416\nG1 X273.929 Y113.521 E.0126\n;WIDTH:0.933574\nG1 F4877.447\nG1 X274.042 Y113.618 E.0083\n'
Upcoming (107825371): 'SET_VELOCITY_LIMIT ACCEL=12000 ACCEL_TO_DECEL=6000\nG1 X274.065 Y113.637 F30000\nSET_VELOCITY_LIMIT ACCEL=8000 ACCEL_TO_DECEL=4000'
gcode state: absolute_coord=True absolute_extrude=False base_position=[0.0, 0.0, 0.0, 80038.90813000555] last_position=[274.042, 113.618, 21.15, 80357.27292000565] homing_position=[0.0, 0.0, 0.0, 0.0] speed_factor=0.016666666666666666 extrude_factor=1.0 speed=81.29078333333334
Reactor garbage collection: (52779.080458408, 54540.650903673, 0.0)
MCU 'mcu' shutdown: Timer too close

Just get over it and reprint. Will likely not properly work anyway.

It will, I have already printed 2 of this GCODE successfully. The timing error is an annoyance that is possibly related to the BTT TFT35 screen, as long as I don’t touch it and just use it for display the printer runs fine.

Also, I was able to continue the print as described above and it is all running OK, but thank you for your positive and constructive criticism @Sineos

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.