Unhandled exception during run

Basic Information:

Printer Model:
MCU / Printerboard: stm32f446
Host / SBC linux feixun n1
klippy.log

Unhandled exception during run
Once the underlying issue is corrected, use the “FIRMWARE_RESTART” command to reset the firmware, reload the config, and restart the host software.
Printer is shutdown

Describe your issue:

At first, there were no issues when printing File No. 2. Then, when I switched to print a different file, this kind of malfunction occurred. Specifically, during the printing process, it would stop directly. After tens of seconds, an error would be reported. Or it would stop for more than ten seconds, then resume printing, and after tens of seconds, an error would be reported. However, when it stopped, the temperature of the heated bed and the nozzle remained at the set temperature. Later, when I re - printed File No. 2 in gcode format, the same situation occurred. I continuously tested printing several other files, and the result was the same. I have tried restarting, updating the Linux Klipper and STM32 firmware, but the problem still persists.

The height at which the error occurs varies; it’s random.


klippy.log (1016.0 KB)

The error in your log is:

Unable to read tmc uart 'stepper_x' register DRV_STATUS
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown

This indicates issues with the UART communication to the stepper. If it is consistently the same, it could be a faulty TMC. Otherwise, triple-check the wiring, correct pin configuration, and jumper settings on the board.

Some printer boards are also believed to be suffering from hardware or design issues that make this error rather common, e.g. [BUG] TMC Connection Error · Issue #155 · bigtreetech/BIGTREETECH-SKR-mini-E3 · GitHub

1 Like

Thank you for your reply. I’ve found an issue. When I directly right - click to download the log on the web page, the downloaded file isn’t complete. This can be seen from the comparison of file sizes.

fulllog.txt (2.8 MB)


Now I’m uploading my complete log. From this complete log, you can see many errors like the ones in the picture. From the log, it can be seen that sometimes after this kind of error occurs, there is a pause for a period of time, then it runs for a while, and then the error occurs again. After that, a “firmware restart” shows up.

You have multiple issues in your log:

Unhandled exception during run
Traceback (most recent call last):
  File "/home/home/klipper/klippy/klippy.py", line 176, in run
    self.reactor.run()
  File "/home/home/klipper/klippy/reactor.py", line 292, in run
    g_next.switch()
  File "/home/home/klipper/klippy/reactor.py", line 347, in _dispatch_loop
    self._fds[fd].read_callback(eventtime)
  File "/home/home/klipper/klippy/reactor.py", line 192, in _got_pipe_signal
    func, args = self._async_queue.get_nowait()
  File "/usr/lib/python3.9/queue.py", line 199, in get_nowait
    return self.get(block=False)
  File "/usr/lib/python3.9/queue.py", line 165, in get
    with self.not_empty:
  File "/usr/lib/python3.9/threading.py", line 257, in __enter__
    return self._lock.__enter__()
RecursionError: maximum recursion depth exceeded while calling a Python object
Transition to shutdown state: Unhandled exception during run

This is caused by a haywire macro that calls FORCE_MOVE multiple times. This command should never be used during regular printing operations. Not sure what you are trying to achieve here. Fix or better yet, delete this macro. It is likely [gcode_macro blink_led].

You are calling this command throughout multiple macros. I strongly advise against doing so unless you have very good reasons and understand what you are doing.

Then we have:

Timeout with MCU 'mcu' (eventtime=8852.558622)
Transition to shutdown state: Lost communication with MCU 'mcu'
Dumping gcode input 0 blocks
Dumping 20 requests for client 548348020912

See Timeout with MCU / Lost communication with MCU

And finally, the error already discussed above.

It really seems to be the cause. After deleting this macro , the situation is good so far. The first print job was completed successfully without any errors. I set this macro definition before to assist with printing. Maybe there was a problem with the pin wire connection. Thanks again, expert, for helping me solve the problem that has been bothering me for several days.

# [gcode_macro blink_led]
# description: Blink my_led one time
# gcode:
#   SET_PIN PIN=DANGER VALUE=1
#   FORCE_MOVE STEPPER=stepper_z3 DISTANCE=-100 VELOCITY=20 ACCEL=10
#   FORCE_MOVE STEPPER=stepper_z3 DISTANCE=100 VELOCITY=20 ACCEL=10

# #   G4 P2000
#   SET_PIN PIN=DANGER VALUE=0



# [gcode_button my_gcode_button]
# # pin:PF7
# pin:PA3
# #   The pin on which the button is connected. This parameter must be
# #   provided.
# #analog_range:
# #   Two comma separated resistances (in Ohms) specifying the minimum
# #   and maximum resistance range for the button. If analog_range is
# #   provided then the pin must be an analog capable pin. The default
# #   is to use digital gpio for the button.
# #analog_pullup_resistor:
# #   The pullup resistance (in Ohms) when analog_range is specified.
# #   The default is 4700 ohms.
# press_gcode:
#     G90
#     blink_led
# #   A list of G-Code commands to execute when the button is pressed.
# #   G-Code templates are supported. This parameter must be provided.
# #release_gcode:
# #   A list of G-Code commands to execute when the button is released.
# #   G-Code templates are supported. The default is to not run any
# #   commands on a button release.