Basic Information:
Printer Model: Ender 3 Pro (Modified)
MCU / Printerboard: Manta M4P
klippy.log
klippy.log (5.5 MB)
Describe your issue:
Hey all! This one’s been on my plate for awhile now, and I’m about at my wit’s end toying with CanBus. Ever since deciding to make the switch using the U2C and the EBB36, I’ve been experiencing a rather frustrating issue when attempting to print. Upon booting the system, everything’s fine. I’m able to perform all actions pre-printing, including homing, probe calibration, bed mesh, etc. etc. with this configuration. When firing up a print, everything runs as anticipated as well, with both the nozzle and the bed heating up to the intended temperature, and the printer moving into its head into position to perform the filament extrude on the leftmost side of the bed.
However, upon a minute or two passing into printing, I hear the printer come to a halt, the toolhead stops moving, and within Klipper, I most commonly receive the following message:
MCU ‘mcu’ shutdown: Missed scheduling of next digital out event
This is generally indicative of an intermittent
communication failure between micro-controller and host.
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
Here’s the steps I’ve already taken so far to try to either troubleshoot, or better understand what’s going on here:
-
Tried multiple USB C Cables from the Manta M4P to the U2C
-
Inspecting dmesg
Here’s dmesg’s output, these are reported live during a print:
[ 6603.535376] gs_usb 1-1.2:1.0 can0: usb xmit fail 1
[ 6789.714634] gs_usb 1-1.2:1.0 can0: usb xmit fail 3
[ 6790.108197] gs_usb 1-1.2:1.0 can0: usb xmit fail 5
[ 6798.437375] gs_usb 1-1.2:1.0 can0: usb xmit fail 9
[ 6801.063411] gs_usb 1-1.2:1.0 can0: usb xmit fail 8
[ 6807.275245] gs_usb 1-1.2:1.0 can0: usb xmit fail 7 -
Viewing the events from lastlog
Interestingly enough, when attempting to perform a “Firmware Restart” after a failure, I notice FluiddPi kick off the following, and never actually fully restart (it hangs):
Feb 27 02:56:55 fluiddpi python[1784]: [klippy_connection.py:_do_connect()] - Klippy Connection Established
Feb 27 02:58:26 fluiddpi python[1784]: [klippy_connection.py:_request_initial_subscriptions()] - Webhooks Subscribed
Feb 27 02:58:26 fluiddpi python[1784]: [klippy_connection.py:_request_initial_subscriptions()] - GCode Output Subscribed
Feb 27 02:58:26 fluiddpi python[1784]: [klippy_connection.py:_check_ready()] -
Feb 27 02:58:26 fluiddpi python[1784]: mcu ‘EBBCan’: Unable to connect
Feb 27 02:58:26 fluiddpi python[1784]: Once the underlying issue is corrected, use the
Feb 27 02:58:26 fluiddpi python[1784]: “FIRMWARE_RESTART” command to reset the firmware, reload the
Feb 27 02:58:26 fluiddpi python[1784]: config, and restart the host software.
Feb 27 02:58:26 fluiddpi python[1784]: Error configuring printer
Feb 27 02:59:02 fluiddpi dhcpcd[828]: eth0: adding address 2600:2b00:8a38:e92b:12ca:6a99:91d6:b830/56
Feb 27 02:59:02 fluiddpi dhcpcd[828]: ipv6_addaddr1: Invalid argument
- Adjusting the CANBus interface configuration, bumping the baud rate from 250k to 500k and allowing hot-plug
- Adjusting the TRSYNC_TIMEOUT in mcu.py from 0.025 to 0.050
- Testing continuity with the DIY CanBus Cable (it rang fine across all 4 lines)
No matter what the change is, I’ve unfortunately been experiencing the same issue consistently occurring around the time of the first layer, every time. I’m fairly proficient with Linux and Unix systems and believe I’ve covered a majority of the potential logs that I thought might had some critical information I’ve been missing, however nothing in any of these is standing out. I do notice in the klippy logs the variation in ready_bytes, often fluctuating from 0-55 at times, however outside of that there’s not much else I’m coming across in my system’s logs that points to one particular thing being an issue.
The cable I used for CANBus communication is simply made of 22AWG Stranded Hookup Wire and runs maybe 2-3ft from the U2C, up the 2020 extrusion, out a cable guide, and down to the EBB36.
Is there anything else I could be missing when checking for issues on my system/printer?
I’ll keep the thread open for the remainder of today while I run through a few more prints and confirm that it’s no longer an issue, and if nothing comes up I think I’ll be safe to close this one out.
