U2C + EBB36 on Manta M8P

Basic Information:

Printer Model: Custom “Frankenstein” mix of HevORT & HyperCube.
MCU / Printerboard: Manta M8p with CB1 & BTT U2C 2.1 + EBB36 1.2
klippy-9.log (3.6 MB)

Describe your issue:

Hi,
So as the above info mentions I have a Manta M8P with CB1 connected via USB to U2C 2.1 module that is communicating with EBB36 1.2 via CAN. My issue is I’m having random EBB disconnection where it’s not able to communicate with the main board. at first I was having a lot of communication timeout & the only way I was able to get past that was to modify the mcu.py script & change the tsync to 0.050 instead od 0.025. That got me to be able to home the axes & do a z-tilt which I wasn’t able to do before.

I was fine with it while it was disconnecting while the printer is just idle, but today midprint the whole CB1 decided to kernel panic mid-print, I know CB1 is not that all great especially with the current images provided by BTT. this might be out of the scope of Klipper, but what I would liek to be helped with is the EBB disconnection; here’s what I did to setup that:

  1. Flashed the EBB36 with CANBoot then CAN flashed it with latest Klipper (v0.10.0-584-g7527e57e) using 500000 bitrate.
  2. Flashed the U2C with CanBoot, then Klipper with CAN Bridge USB & CAN; that didn’t work, I wasn;t able to get the EBB to connect.
  3. Flashed the U2C with the provided firmware by BTT< which I beleive is a custom build of CandleLight for the STM32G0b1. This got me connected to the EBB (I was able to query the can0 interface & got the UUID)
  4. As mentioned above, at first it kept saying communications timeout whenever I try to do simple moves like homing or z-tilt adjustment, so modified the mcu.py as advised somewhere here by someone was having the same issue.
  5. I made sure that I’m seeing 60 ohms on the CAN bus (ie 120R jumpers on both the EBB36 & U2C)
  6. I even went further & tried to eliminate the U2C all together by configuring the Manta as a USB CAN bridge on pins PB0 & PB1 as they were available & I’m not using either, but that didn’t work at all & I was never able to see the EBB.
  7. I made sure that there’s no bytes_invalid at all, you can see from the log it’s always saying 0.

I really don’t know what else I might be missing or I might be having bad hardware?
Thanks in advance.

Molafa.

I have/had the same issues using an USB CANable adapter and the EBB36. It randomly disconnects from Klipper, no lost bytes either, not even resends. Even a benchy won’t manage to get past the deck.
I did finish a single benchy successfully last night after setting the speed to 250k on both the EBB36 and the can0 interface settings, but didn’t try anything more yet since.
Edit: Just tried to print, during homing, it lost communication. So yeah, at this point I blame the EBB36 itself.

Considering the raw amount of reports from people losing connection with the EBB36 over CAN, I am thinking there may be an issue with the board itself. My Mellow SHT36 has never once lost connection at 500k (minus the time I had a bad crimp, which was my own fault).

Thanks Arakon, I’ll try to lower the bitrate to 250K. But I remember Kevin recommending against it since it’s not enough bandwidth for resonance testing for example.
If you don’t mind me asking, what is your controlling board? RPi?

Pi Zero 2 W. It’s never even getting close to being fully loaded. 250k was sadly not the solution

I have twisted the CAN wires now (just loosely around each other instead of a really tight twist) and that seems to have helped greatly… they basically just cross over each other only every 8cm or so.

The odd thing is, the SHT36 is fine with untwisted wires of even greater length, which makes me think that BTT may have messed up with the interference filtering somewhere.

Is swapping between the two boards (FLY vs EBB) the only variable? Your results are surprising since at least glancing at the schematics the EBB boards have better EMI protection (they use common mode choke for example). Of course there are other variables such as power quality, PCB routing etc.

Is your ground reasonably well referenced?

GND is connected directly to the power supply.
Oddly enough, I switched to 500k again and my entire system crashes about 35% into the print every time now. Not just lost connection or anything… the whole Pi crashes and requires a power down.
No errors in the log or anything, just kills the entire system. Twice, nearly at the same spot. syslog, klippy log, none indicate an issue.

Edit: Just went back to 250k to test and I can run a resonance test just fine.

Surprisingly my issue went away after upgrading to the latest CB1 image 2.2! I’m not seeing the communication timeout anymore & was able to do a 10x10 bed mesh calibration with no issues several times. Of course minus the WiFi issue as I wait for a CB1 replacement.

That smells to me like either a power supply, grounding or a Pi hardware issue.

Neither of those would be affected by reducing the speed… I did two several hour long prints at 250k now and they were flawless. The printer had also been running perfectly fine before the EBB board for several months.
It’s just possible that the USB CAN module sends some broken response or something at too high speeds and it crashes either the CAN driver or Klipper itself.

My point was that the type of malfunction that you were describing is likely associated with an EMI issue. In other words excessive electrical noise in the wiring. This can be a consequence of power supply quality and/or configuration and also of the ground reference topology. 3D printers are a rather unpleasant electrical environment where sensitive low current analogue signals are mixed with high current PWM and switching signals that can induce a lot of noise via coupling. Many people are not even aware of the EMI aspects, except perhaps the “ground loop” aspect that at least Duet3D references in their documentation.

When you add the EBB to your printer, you need to pull ground and power to it. Depending on how your MCU & Pi are powered and grounded this additional load can create excessive noise on the Pi, causing it to do strange things…

The Pi has a seperate PSU of its own, and the EBB is powered from the printer’s PSU. GND is shared, of course. I run this exact same setup on my vzbot, as well, and at 500k with ease.

I am trying to get the combination of BTT U2C and BTT EB42 to run at 500K speed. I can build the firmware for the EBB42, but not for the U2C. Can anyone provide good directions on how to do this? The Candlelight GitHub requires some knowledge I don’t possess :wink:

This combination of hardware has been running flawlessly on 250K on a newly build Voron 2.4 using slightly twisted wires for CANbus.

I used this here to update the U2C: https://canable.io/updater/canable1.html
Works fine with 500k.

Has anyone gotten this to work? I have a BTT Manta M8P with CB1 and I have been trying to get the U2C and EBB42 working for a couple of weeks with no luck. I have tried multiple U2C’s and EBB42’s, and each time I do anything more complicated than a flow rate cube, I get a Timer Too Close error.

I don’t have this exact setup, but something similar. On my Voron Switchwire I have a Manta M4P with a CB1. I’m using a UCCB USB to CAN device connected to an EBB42. I run the CAN bus at 1M and it’s been extremely reliable for me.

Just looked up the UCCB. I love the form factor, and if you say it works, I’m down to give it a shot. Unfortunately they have been out of stock since October 20, so it might take a while… Would like to find a solution in the interim… Might just go with a full umbilical cord until then…

If you think the U2C is the problem, you should get a CANable clone from MKS. Last I checked they were in stock on Ali for around $20. I have one and it also works well on another printer. No promises it solves your issue though.

You are the best. After a solid month of building this printer, I FINALLY got my first successful print. I flashed candlelight on the U2C, then CanBoot followed by Klipper onto the EBB42. I chose 1M this time. That is literally the only thing that is different about this time than the others.