CANbus error only when printing - EBB rp2040 sb2209

Basic Information:

Printer Model: Voron 2.4 r2
MCU / Printerboard: fysetc spider v2.2
toolhead board: EBB SB2209 CAN V1.0(RP2040)
MMU ERCF board: BTT MMB CAN V1.0
USB to CAN board: BTT U2C V2.1
Host / SBC: Raspberry Pi 4 Model B rev 1.5
klippy.log (4.2 MB)
moonraker.log (27.5 KB)

Error screen with Canbus load

Describe your issue:

When i try to print i get the error message "Lost communication with MCU ‘EBBCan’
This error always comes between layer 1 and 9.

Background:

4-8 month ago i had a problem with this error happening once every now and then. My solution was to reprint the model and mostly it would finish without problems. About 2-3 month ago the problem got worse. I could not finish a single part. I tried the same part maybe 10 times and it always got this error within layer 10. I tried re-slicing the part and changing the location on the bed, but no luck. Countless of tries the following month brings me to where i am to day without a single part printed. The error only comes when printing a part, but never during gantry level, auto z and bed mesh or when printer is not printing a part. When clicking “Firmware restart” the printer is up and running again without any further error messages until next print…

What i have tried (probably not in this exact order):

  1. Changing the Can-cable from the u2c v2.1 to the toolhead.
  2. Checked that i had a 120 ohm resistor at each end. (one on the toolhead and one at the MMU) (measuring 59,2 ohm between Can H and L).
  3. Changing the USB cable from RPi to u2c v2.1 and from RPi to fysetc spider.
  4. Removed all unnecessary USB accessories like camera.
  5. Checked canbus txqueuelen. Is 1024, tried with 128 but moved back to 1024.
  6. Removed the sticker on the blower fan. (Solution from another post)
  7. Taping the +5V on usb cables (did not work so removed again)
  8. Disconnected the MMU board and removed config (and moved 120 ohm R to i2c v2.1 board)
  9. Taping the back of the toolhead front cover board. (solution from another post)
  10. Reinstalled linux (this time 32 bit because i read 64 bit could have problems with canbus) and klipper and all the other extensions i use (klipper_z_calibration, KAMP, klipper screen, happyhare, happyhare klipper screen, fluidd, ++)’
  11. re-flashed the EBB rp2040 toolhead board

Other info:

  • I am using an original pi 4 power supply (5.1V, 3A)
  • Pi and u2c v2.1 can adatper is grounded thru USB.

The only thin i can find in the log files is that “bytes_retransmit:” is increasing on “EBBCan” right before the error, but i can not see any load increase int the graphs in fluidd. Maybe there is somthing else in the log files that i cannot se.

I am now out of ideas to try and desperately need help.

edits: Making text and problem clearer.

Try this stable firmware for the G0B1 V2.x U2C
https://www.dropbox.com/scl/fi/z3qsrfktste1emz4v6v4n/G0B1_U2C_V2.zip?rlkey=3lnqgjj7do5yqv996ccp537vl&st=zop3aodq&dl=0

In addition to @NAPCAL’s advice, this kind of error often is the consequence of wonky wiring / connectors. It is quite common that such defects only pop up under certain conditions, e.g. when hot or moving. This would also match your description of the issue frequency increasing over time.

1 Like

I have now flashed the U2C with the latest firmware. This did not help.

I checked all the plugs on the EBB toolhead and the one on the U2C and did not find any obvious bad crimps or connections. However right after this i managed to finish one print (don’t know if this was purely coincidental), but after this print the same problem occurred. I did also remove the plug from the U2C and connected the CAN H/L wires to the screw terminals without any more success.

Next i swapped the cables between the two CAN boards i have. The error is still on the EBBCan toolboard.

I would then think that the U2C and the wire to the toolhead is OK beacuse the error still persisted on the same CAN board. Is it possible that a bad wiring connected to the toolhead itself can give “lost connection”? I would guess this would give “temperature out of range” or some other signal fault error.

I am thinking of buying a new toolhead board to see if mine may be faulty. Do you think that is a good ide or do you think the fault is not on the board but some other place?

Diagram of wiring and swap.

My jumpers are placed like you show in the diagram.

1 Like

Unshielded CAN bus cables (stock cables are not shielded); ensure they are not running next to stepper cables.

If you are using shielded CAN cables, make sure to earth ground (not power supply ground) the shield ONLY at the U2C location, not the other end.

It would help if you redid any connectors you have done, but after; hot gluing the end from which the wires are inserted. Immobilize CAN bus wires just before the connector so they don’t move.

As the above link tries to explain: This error occurs if an MCU no longer responds to the heartbeat requests of the host - be it because the MCU crashed, something is blocking the communication line or because the communication line itself is broken (e.g. physically disconnected due to broken wires).

Regarding a crashed MCU: Today, no indication exists that Klipper has bugs that might be causing it, so the reasons for a crashing / not responding MCU are expected in its power supply, wiring, peripherals etc.

1 Like

I finally redid all the connectors on the toolhead and glued them as @NAPCAL and @Sineos suggested. The error has now gone away. Thank you very much! Glad to be able to print after weeks of troubleshooting.

PS. Yesterday i ordered a replacement board for the toolhead. Guess i have to build a new voron now becaus i have a toolhead to much. The board can’t be wasted :stuck_out_tongue:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.