Klipper Shutdown when starting to print 3rd layer

General Discussion
1

Basic Information:

cannot fine any information on the make or model of the unit.
BIGTREETECH Octopus motherboard
klippy.log (3.5 MB)
moonraker.log (49.5 KB)

Fill out above information and in all cases attach your klippy.log file. Pasting your printer.cfg is not needed

Describe your issue:

The printer was working good then something happen when someone else used it and they no longer works here. The printer start off like normal and prints 2 layers then stops at the start of the 3rd layer. I tried 4 different jobs that worked before and even two new ones. I does not matter if I print one item or 6 items at one time. it still stops at the beginning of the 3rd layer.

Can anyone help me?
what other information do you need.

2

There are two (hard to diagnose) errors in your log:

TMC 'extruder' reports GSTAT:      00000001 reset=1(Reset)
TMC 'extruder' reports GSTAT:      00000000

See TMC 'extruder' reports error: GSTAT: 00000001 reset=1(reset - #39 by Sineos

Got EOF when reading from device
Stats 1893.9: gcodein=0  mcu: mcu_awake=0.006 mcu_task_avg=0.000009 mcu_task_stddev=0.000009 bytes_write=794982 bytes_read=505253 bytes_retransmit=0 bytes_invalid=0 send_seq=23692 receive_seq=23692 retransmit_seq=0 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=28 stalled_bytes=613 freq=180001535 heater_bed: target=50 temp=49.9 pwm=0.168 sd_pos=295262 sysload=0.46 cputime=42.807 memavail=1592728 print_time=83592.365 buffer_time=2.023 print_stall=0 extruder: target=240 temp=239.9 pwm=0.542
Stats 1894.9: gcodein=0  mcu: mcu_awake=0.006 mcu_task_avg=0.000009 mcu_task_stddev=0.000009 bytes_write=794982 bytes_read=505253 bytes_retransmit=0 bytes_invalid=0 send_seq=23692 receive_seq=23692 retransmit_seq=0 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=28 stalled_bytes=4223 freq=180001535 heater_bed: target=50 temp=49.9 pwm=0.168 sd_pos=302002 sysload=0.59 cputime=42.883 memavail=1592232 print_time=83593.470 buffer_time=2.127 print_stall=0 extruder: target=240 temp=239.9 pwm=0.542
Stats 1895.9: gcodein=0  mcu: mcu_awake=0.006 mcu_task_avg=0.000009 mcu_task_stddev=0.000009 bytes_write=794982 bytes_read=505253 bytes_retransmit=0 bytes_invalid=0 send_seq=23692 receive_seq=23692 retransmit_seq=0 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=28 stalled_bytes=9208 freq=180001535 heater_bed: target=50 temp=49.9 pwm=0.168 sd_pos=308853 sysload=0.59 cputime=42.959 memavail=1591460 print_time=83594.908 buffer_time=2.565 print_stall=0 extruder: target=240 temp=239.9 pwm=0.542
Stats 1896.9: gcodein=0  mcu: mcu_awake=0.006 mcu_task_avg=0.000009 mcu_task_stddev=0.000009 bytes_write=794982 bytes_read=505253 bytes_retransmit=0 bytes_invalid=0 send_seq=23692 receive_seq=23692 retransmit_seq=0 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=28 stalled_bytes=10729 freq=180001535 heater_bed: target=50 temp=49.9 pwm=0.168 sd_pos=311810 sysload=0.59 cputime=42.989 memavail=1591444 print_time=83595.466 buffer_time=2.122 print_stall=0 extruder: target=240 temp=239.9 pwm=0.542
Stats 1897.9: gcodein=0  mcu: mcu_awake=0.006 mcu_task_avg=0.000009 mcu_task_stddev=0.000009 bytes_write=794982 bytes_read=505253 bytes_retransmit=0 bytes_invalid=0 send_seq=23692 receive_seq=23692 retransmit_seq=0 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=28 stalled_bytes=14456 freq=180001535 heater_bed: target=50 temp=49.9 pwm=0.168 sd_pos=319072 sysload=0.59 cputime=43.076 memavail=1591744 print_time=83596.546 buffer_time=2.201 print_stall=0 extruder: target=240 temp=239.9 pwm=0.542
Timeout with MCU 'mcu' (eventtime=1898.871847)

Got EOF when reading from device leading then to Timeout with MCU 'mcu' means that the underlying Linux OS has lost contact to your Octopus board. Potential reasons are:

  • Issues on OS level
  • Issues with USB hardware, e.g. connectors, cable etc
  • Issues the board’s hardware
3

what is strange is if it takes 2 minutes or 10 minutes to do 2 layers it is always “klipper shutdown” at the start of the 3rd layer.
I did change out the cable.
image

4

FYI, a log showing a reset immediately followed by the reset being cleared does not indicate a problem. This happens if a user powers up the board before powering up motor power, or if the user disables and then reenables motor power while the board is idle. In these cases, when Klipper enables the stepper, it will see that there was a reset of the driver, clear the reset flag, verify that the reset was cleared, and then proceed normally.

The alternative case, where the log shows a tmc driver reset that is immediately followed by a Klipper error, does indicate a hard to debug tmc driver error. That would indicate that an “unexpected tmc reset” occurred. That seems to occur with unstable voltages and/or faulty driver chips.

-Kevin

1 Like