KlipperScreen cancels prints without user interaction

Frontends KlipperScreen
1

Basic Information:

Printer Model: Monoprice Maker Select Plus
MCU / Printerboard: BigTreeTech SKR Mini E3 V3.0
Host / SBC: Raspberry Pi 3B+
klippy.log + moonraker.log
logs-20250209-005650.zip (177.2 KB)

Describe your issue:

I have a print that keeps getting cancelled at layer 37/178. It’s happened twice now. klippy.log only shows Exiting SD card print (position 2711115) when the print fails. moonraker.log shows 2025-02-09 00:43:54,794 [klippy_apis.py:cancel_print()] - Requesting job cancel.... mainsail-access.log only shows the normal GET requests that happen every 30s (though it is interesting this happened the same second that cancellation was requested)

10.0.0.2 - - [09/Feb/2025:00:43:54 -0800] "GET /api/job HTTP/1.1" 200 157 "-" "Python/3.13 aiohttp/3.11.12"
10.0.0.2 - - [09/Feb/2025:00:43:54 -0800] "GET /api/printer HTTP/1.1" 200 193 "-" "Python/3.13 aiohttp/3.11.12"

How can I dig deeper to understand where this cancellation came from?

2

If the request to cancel is coming over a websocket connection it won’t show up in the access log. The requests you see are likely coming from Cura since they are using the OctoPrint compatibility API.

To get more information about the request enable Moonraker’s verbose logging. You can do this via ssh and modifying the following file:

~/printer_data/systemd/moonraker.env

Open the file with a text editor (nano or vim) Add -v to MOONRAKER_ARGS. Save the file and restart Moonraker.

This will create a very dense moonraker.log, but you should be able to find out more information about where the request to cancel is coming from. From the log you attached I can tell you have at least one localhost connection, likely KlipperScreen.

If you’d like to skip all of that, you could try the print with KlipperScreen disabled.

3

You nailed it, it looks like it was KlipperScreen. I’ll update the title. It’s interesting it happened at nearly the exact same time in the print both times.

IMG_0252 2
IMG_0252 21920×1440 171 KB

From KlipperScreen.log It looks like it happened soon after showing the screensaver both times, so it’s probably somehow related to that (which would explain the similar timing… The printer was in the other room when this happened / I promise I didn’t touch it / I don’t have a cat or anything to step on the screen :slight_smile:

2025-02-08 23:22:21,813 [screensaver.py:show()] - Showing Screensaver
2025-02-08 23:22:21,814 [screensaver.py:show()] - Hiding dialog
2025-02-08 23:23:46,371 [screensaver.py:close()] - Closing Screensaver
2025-02-08 23:23:46,385 [screen.py:wake_screen()] - Screen wake up
2025-02-08 23:23:46,494 [screensaver.py:close()] - Restoring Dialog <Gtk.Dialog object at 0x7f9002e980 (GtkDialog at 0x8d8f6f0)>
2025-02-08 23:23:46,657 [heatergraph.py:event_cb()] - Graph area: 269.1957092285156 390.9939270019531
2025-02-08 23:25:08,247 [KlippyGtk.py:remove_dialog()] - Removing Dialog
2025-02-08 23:25:45,815 [KlippyGtk.py:Dialog()] - Showing dialog Cancel (width=800, height=480)
2025-02-08 23:26:09,683 [KlippyGtk.py:remove_dialog()] - Removing Dialog
2025-02-08 23:26:09,683 [job_status.py:cancel_confirm()] - Canceling print
2025-02-08 23:26:09,689 [job_status.py:set_state()] - Changing job_status state from 'printing' to 'cancelling'
2025-02-08 23:26:09,696 [KlippyWebsocket.py:print_cancel()] - Sending printer.print.cancel
2025-02-08 23:26:09,982 [printer.py:change_state()] - Changing state from 'printing' to 'ready'
2025-02-08 23:26:09,983 [printer.py:change_state()] - Adding callback for state: ready
2025-02-08 23:26:10,000 [job_status.py:set_state()] - Changing job_status state from 'cancelling' to 'cancelled'
2025-02-08 23:26:10,197 [screen.py:set_screenblanking_timeout()] - Blanking timeout: 3600 DPMS:True

2025-02-09 00:42:57,814 [screensaver.py:show()] - Showing Screensaver
2025-02-09 00:43:40,191 [screensaver.py:close()] - Closing Screensaver
2025-02-09 00:43:40,201 [screen.py:wake_screen()] - Screen wake up
2025-02-09 00:43:47,416 [KlippyGtk.py:Dialog()] - Showing dialog Cancel (width=800, height=480)
2025-02-09 00:43:54,765 [KlippyGtk.py:remove_dialog()] - Removing Dialog
2025-02-09 00:43:54,766 [job_status.py:cancel_confirm()] - Canceling print
2025-02-09 00:43:54,776 [job_status.py:set_state()] - Changing job_status state from 'printing' to 'cancelling'
2025-02-09 00:43:54,784 [KlippyWebsocket.py:print_cancel()] - Sending printer.print.cancel
2025-02-09 00:43:55,062 [printer.py:change_state()] - Changing state from 'printing' to 'ready'
2025-02-09 00:43:55,063 [printer.py:change_state()] - Adding callback for state: ready
2025-02-09 00:43:55,079 [job_status.py:set_state()] - Changing job_status state from 'cancelling' to 'cancelled'
2025-02-09 00:43:55,257 [screen.py:set_screenblanking_timeout()] - Blanking timeout: 3600 DPMS:True

When I went to the printer this morning the screen wouldn’t wake up at all – it was black. I logged into the Mainsail interface and rebooted Pi and the print worked fine :man_shrugging:. I’ll watch for this and see if it happens again.

Probably also doesn’t help that the cancel button, and the cancel confirmation are in exactly the same spot :slight_smile:

4

Happened again this morning. Seems that KlipperScreen works fine for about a day before this happens. This time the failure didn’t happen after the screensaver, so that hypothesis is out. I wonder if I have a wonky screen. Still, it’s strange that it only starts happening after ~24hrs of power on. Also strange that it just so happens to be right on the cancel button. Though always possible I’m very unlucky :slight_smile:

2025-02-10 08:44:55,466 [KlippyWebsocket.py:get_dir_info()] - Sending server.files.get_directory  gcodes
2025-02-10 08:44:55,490 [screen.py:attach_panel()] - Current panel hierarchy: main_menu > gcodes
2025-02-10 08:44:55,932 [gcodes.py:load_files()] - Loaded in 0.370 seconds
2025-02-10 08:45:01,331 [KlippyRest.py:_do_request()] - 500 Server Error>>Internal Server Error for url>>http://127.0.0.1:7125/server/history/job?uid=None
2025-02-10 08:45:01,395 [KlippyGtk.py:Dialog()] - Showing dialog Print Spool-Wrap-ScrewNuts-PETG-86g.gcode (width=800, height=480)
2025-02-10 08:45:02,651 [KlippyGtk.py:remove_dialog()] - Removing Dialog
2025-02-10 08:45:02,652 [gcodes.py:confirm_print_response()] - Starting print: Spool-Wrap-ScrewNuts-PETG-86g.gcode
2025-02-10 08:45:02,652 [KlippyWebsocket.py:print_start()] - Sending printer.print.start
2025-02-10 08:45:02,922 [printer.py:change_state()] - Changing state from 'ready' to 'printing'
2025-02-10 08:45:02,923 [printer.py:change_state()] - Adding callback for state: printing
2025-02-10 08:45:02,935 [screen.py:set_screenblanking_timeout()] - Blanking timeout: 3600 DPMS:False
2025-02-10 08:45:02,935 [screen.py:_remove_all_panels()] - Removing all panels
2025-02-10 08:45:03,024 [screen.py:show_panel()] - Reinitializing panel job_status
2025-02-10 08:45:03,223 [screen.py:attach_panel()] - Current panel hierarchy: job_status
2025-02-10 08:45:03,242 [job_status.py:set_state()] - Changing job_status state from 'standby' to 'printing'
2025-02-10 08:45:03,256 [job_status.py:update_filename()] - Updating filename to Spool-Wrap-ScrewNuts-PETG-86g.gcode
2025-02-10 08:45:03,258 [job_status.py:_update_file_metadata()] - Update Metadata. File: Spool-Wrap-ScrewNuts-PETG-86g.gcode Size: 22355443
2025-02-10 08:56:17,344 [KlippyGtk.py:Dialog()] - Showing dialog Cancel (width=800, height=480)
2025-02-10 08:57:09,599 [KlippyGtk.py:remove_dialog()] - Removing Dialog
2025-02-10 08:57:09,599 [job_status.py:cancel_confirm()] - Canceling print
2025-02-10 08:57:09,604 [job_status.py:set_state()] - Changing job_status state from 'printing' to 'cancelling'
2025-02-10 08:57:09,609 [KlippyWebsocket.py:print_cancel()] - Sending printer.print.cancel
2025-02-10 08:57:10,321 [printer.py:change_state()] - Changing state from 'printing' to 'ready'
2025-02-10 08:57:10,321 [printer.py:change_state()] - Adding callback for state: ready
2025-02-10 08:57:10,343 [job_status.py:set_state()] - Changing job_status state from 'cancelling' to 'cancelled'
2025-02-10 08:57:10,400 [screen.py:set_screenblanking_timeout()] - Blanking timeout: 3600 DPMS:False

(~8:45 was me, 8:57 was after I had left the house)

Edit: By end of the day the screen was blanked and no longer responsive to touches (though the pi still worked)

5

For interest… What Screen have you installed on your Printer?

6

I was originally borrowing a DFRobot 5" MIPI display to test when I was getting the false touches.

I’ve since bought the equivalent one from BTT.

I think I’m not getting as many false touches any more. Though I now compulsively move the cursor away from the cancel button by tapping the top left of the screen. I’m not sure if that’s superstition at this point. Maybe I’ll stop doing that and see if the issue persists.