Why output stops due to "!SD busy" error?

General Discussion
1

Basic Information:

Printer Model: AM8
MCU / Printerboard: SKR1.4, A8 baord, RPI 4
klippy.log

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

Describe your issue:

These days I am writing macros to use “MMU” and testing them to know the optimal state.
I am checking it by slicing with XYZ cube calibration.

“!!!SD busy” continues to work.
Perhaps the cause is the PAUSE command.
If there is a problem and you modify the macro, then it will stop in a paused state.

maybe in a macro
“{% if printer.pause_resume.is_paused != true %}” I wonder if it’s not possible to check the real-time change when checking this condition.

“printer.query_endstops.last_query” Like this object, I wonder if it needs to be updated with QUERY_ENDSTOPS before to recognize the change.

Prusa Slicer Startup gcode Additions include:

all_eject
mmu_unlock
home_mmu_only
M140 S60 ;set bed temp
M190 S60 ; wait for designated temp
G28 ; home axis
G1 Z20 X-10 y0 F1000
M104 S230 ;set extruder temp
M109 S230 ; wait for designated temp
t0
G21
G90
M82
M107
G92 E0
G1 Z10 F400
G1 X5 Y10 F1200
G1 Z0.3
G1 Y70 E12 F300
G1 Y80
M73 P0 R35
G1 Z10
G92 E0
M117 Printing…
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82; use absolute distances for extrusion
G92 E0
added like this

I translated it with a translator, so please understand if it’s awkward.

I will wait for your reply
klippy (2).log (390.3 KB)

2

Your log shows:

Got EOF when reading from device
Got EOF when reading from device
Timeout with MCU 'mcu' (eventtime=88155.908377)
Transition to shutdown state: Lost communication with MCU 'mcu'
Dumping gcode input 0 blocks

Got EOF when reading from device is and indication that the Linux operating system has lost contact to an USB device (in this case the mcu). This leads some moments later to Timeout with MCU 'mcu' (eventtime=88155.908377).
This points to some hardware issue:

  • Cable
  • Connectors
  • Ports
  • General failure of a hardware component

Check with sudo dmesg if there are any USB related error messages

1 Like
3

I checked with sudo dmesg and there is a log like this.
Among them ch341-uart ttyUSB0: usb_serial_generic_write_bulk_callback - urb stopped: -32
There seems to be an error, is this a problem?

[ 195.241302] usb 1-1.4: USB disconnect, device number 4
[ 196.043001] usb 1-1.4: new full-speed USB device number 5 using xhci_hcd
[ 196.182811] usb 1-1.4: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[ 196.182844] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 196.182860] usb 1-1.4: Product: lpc1768
[ 196.182875] usb 1-1.4: Manufacturer: Klipper
[ 196.182890] usb 1-1.4: SerialNumber: 0C600014618445AF60C2D65CC22000F5
[ 196.189684] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
[ 636.396526] usb 1-1.4: USB disconnect, device number 5
[ 636.692540] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 636.692982] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 636.780181] ch341-uart ttyUSB0: usb_serial_generic_write_bulk_callback - urb stopped: -32
[ 636.806387] ch341-uart ttyUSB0: usb_serial_generic_write_bulk_callback - urb stopped: -32
[ 636.858487] ch341-uart ttyUSB0: usb_serial_generic_write_bulk_callback - urb stopped: -32
[ 636.908513] usb 1-1.1: USB disconnect, device number 3
[ 636.910696] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[ 636.910787] ch341 1-1.1:1.0: device disconnected
[ 642.287671] usb 1-1.1: new full-speed USB device number 6 using xhci_hcd
[ 642.424106] usb 1-1.1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.60
[ 642.424126] usb 1-1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 642.424141] usb 1-1.1: Product: USB2.0-Serial
[ 642.429000] ch341 1-1.1:1.0: ch341-uart converter detected
[ 642.434361] usb 1-1.1: ch341-uart converter now attached to ttyUSB1
[ 644.017725] usb 1-1.4: new full-speed USB device number 7 using xhci_hcd
[ 644.157495] usb 1-1.4: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[ 644.157514] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 644.157530] usb 1-1.4: Product: lpc1768
[ 644.157545] usb 1-1.4: Manufacturer: Klipper
[ 644.157560] usb 1-1.4: SerialNumber: 0C600014618445AF60C2D65CC22000F5
[ 644.162364] cdc_acm 1-1.4:1.0: ttyACM1: USB ACM device
[ 1251.306261] usb 1-1.4: USB disconnect, device number 7
[ 1252.074247] usb 1-1.1: USB disconnect, device number 6
[ 1252.075069] ch341-uart ttyUSB1: ch341-uart converter now disconnected from ttyUSB1
[ 1252.075196] ch341 1-1.1:1.0: device disconnected
[91717.465706] usb 1-1.1: new full-speed USB device number 8 using xhci_hcd
[91717.622022] usb 1-1.1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.60
[91717.622041] usb 1-1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[91717.622057] usb 1-1.1: Product: USB2.0-Serial
[91717.631305] ch341 1-1.1:1.0: ch341-uart converter detected
[91717.637863] usb 1-1.1: ch341-uart converter now attached to ttyUSB0
[91718.185671] usb 1-1.4: new full-speed USB device number 9 using xhci_hcd
[91718.325344] usb 1-1.4: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[91718.325353] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[91718.325359] usb 1-1.4: Product: lpc1768
[91718.325365] usb 1-1.4: Manufacturer: Klipper
[91718.325371] usb 1-1.4: SerialNumber: 0C600014618445AF60C2D65CC22000F5
[91718.332027] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device

4

This is definitively a problem.

  • Try without webcam. Webcam is putting high strain on the USB
  • Alternatively wire the MCU with direct serial connection to the RPi
5

There are skr1.4 board and A8 board for MMU2 that use usb

The camera is currently using the CSI port as a Raspberry Pi cam. Is this a problem, too?

I think the CH341 driver is probably A8 board, but I will buy the cable and change it.

Thank you for your answer. I will post a review after changing the cable.

6

The CH3xx serial to USB chips are known for being problematic and some recent Kernel variants contain buggy drivers.

Not sure. The RPi being a highly integrated device so many resources are shared. How far they influence each other I cannot tell. Worth a try.