Basic Information:
[x] Printer Model Custom
[x] MCU / Printerboard: Manta M8P V2.0 as MCU and EBB42 Gen2 for toolboards
[x] Host / SBC: CM4
[x] klippy.log
klippy (21).zip (8.5 MB)
Hi!
I’m having real problems making my printer work.
I have the following setup: EBB_Can0 in T0, EBB_Can1 in T1, the main MCU (Manta M8P), and EBB_Can2 in the filament bay. All of them are connected in a real CAN bus topology. The 120 Ω termination jumpers are installed only on EBB_Can0 and EBB_Can2, which are the physical ends of the bus.
My machine uses a functional grounding scheme. All chassis and structural metal parts are connected to 0V at a single point by bonding the power supply’s FG pin and ground terminals. All motors, boards, sensors, and peripherals reference this same 0V network through their respective GND connections.
The Manta M8P is intentionally kept electrically isolated from the chassis. It is mounted on a metallic plate connected to a dedicated floating ground plane, which is referenced to 0V through a single wire which belongs to this board. I do this just to connect one of the side of the shields of my temperature sensors. Manta mounting holes appear to have a low-resistance connection to the board’s GND plane so mounting it directly to the grounded chassis could therefore create an additional 0V-to-chassis connection point and potentially introduce unwanted ground currents.
In the other hand, EBB42 Gen2 boards are different. According to BTT’s documentation, their mounting holes are connected to GND through high-value resistors (in the megaohm range) intended for ESD dissipation. Therefore, these boards are mounted on a metal plate that is connected to the machine chassis and referenced to 0V. This provides an ESD reference while avoiding a direct low-impedance connection between the board GND and the chassis.
For this reason, I currently do not suspect ESD-related issues to be the root cause of the problem.
Before the failure, the CAN bus appears to be healthy. Error counters remain very low and stable, which correspond to the start of the machine, with no continuous increase over time. Typical values a few seconds before the shutdown were:
-
MCU:
rx_error=5,tx_error=0,bytes_retransmit=0,bytes_invalid=0 -
EBBCan_0:
rx_error=4,tx_error=1,bytes_retransmit=0,bytes_invalid=0 -
EBBCan_1:
rx_error=5,tx_error=0,bytes_retransmit=0,bytes_invalid=0 -
EBBCan_2:
rx_error=5,tx_error=0,bytes_retransmit=0,bytes_invalid=0
All CAN devices were in bus_state=active, send_seq matched receive_seq, retransmissions were zero, and there were no communication warnings. Nothing suggests a gradually degrading bus, excessive noise, or a wiring issue.
Then, almost instantaneously, the following message appears:
USB CANBUS bridge 'mcu' is discarding!
Immediately afterwards, the main MCU CAN interface changes from:
bus_state=active
to:
bus_state=off
At that point retransmissions start appearing on all CAN nodes simultaneously. A few seconds later Klipper reports:
Timeout with MCU 'EBBCan_1'
and enters shutdown.
From the log, it looks like the first component entering a fault state is actually the CAN bridge associated with the main MCU, not EBBCan_1 itself. EBBCan_1 is simply the first MCU that Klipper eventually declares lost.
Another interesting detail is that this particular failure occurred while printing only with T0. T1 was parked and idle, with no extrusion, no toolchanges, and no active heater load. Despite that, the shutdown still ends with a timeout reported on EBBCan_1.
My Klipper version is based on official Klipper commit f52a6f9491e6bbb6c04f3634012ae23f41e8b857 (December 2025), with a few small custom modifications related to toolhead and heaters.py.
I’m planning to update to the latest Klipper version and reflash all boards after merging my modifications. However, before doing that, I’d like to know if anyone has seen similar behavior with EBB42 Gen2 boards, the Manta M8P CAN bridge, or if there are any known issues that could explain this type of failure.
Any ideas would be greatly appreciated.