[Older topic addendum - Solved:] "CANBUS Communication timeout while homing Z"

[paul_damian]

Basic Information:

Printer Model: Ender 3 heavily modified
MCU / Printerboard: STM32G0B1RE / BTT Manta E3EZ
Host: / SBC BTT CB1
klippy.log
klippy.zip (1.9 MB)

In previous topics (like https://klipper.discourse.group/t/canbus-communication-timeout-while-homing-z/3741 users complained of CAN communications errors during homing. A lot of workarounds showed up, none of them solved the problem 100%.

I just want to share the solution for my particular setup: BTT CB1 → (USB CAN Bridge) → BTT Manta E3EZ → (Canbus) → BTT EBB42 toolhead. I’ve tested also with another set that I have on hold for the next setup: Manta M8P, CB1, EBB36 toolhead, from the same BigTreeTech.

I’ve run also in this problem, first on the first setup, then tested on the second, and none of those solutions provided in those topics fitted me. I didn’t wanted to tackle with mcu.py, I had no errors on the CANBus, etc. But what catched my eye was what Kevin discovered here.

BTT provides for the CB1 their latest V2.3.4 image of Debian Bullseye with kernel 5.1.6, but no other kernel, no Bookworm. After a little digging I found out that there is an Armbian 24.2.3 Bookworm with kernel 6.1.79. So why not giving it a try?

So I have installed the CLI version of it. And, well, that was the right solution. I’ve tested it first on the reserve setup, then on the actual printer. I’ve did several prints, no more homing errors!

So yes, the problem resides in the Bullseye kernel, like Kevin said.

On a side note, totally off-topic, I want to share some other information, perhaps somebody needs it and finds it: The BTT TFT35 SPI display is natively intergrated in BTT’s Bullseye (of course). But it is also supported by Armbian’s Bookworm. The “driver” DBT overlay files are provided in the image files, but there are a couple of more steps needed:

In armbianEnv.txt

• provide the usual overlays=tft35_spi, like for BTT’s Bullseye

Then, in

sudo nano /etc/modules-load.d/98-fbtft.conf:

add:

fbtft
fbtft_device

In

sudo nano /etc/modprobe.d/fbtft.conf

add:

options fbtft_device name=tft35spi fps=25

And in

sudo nano /usr/share/X11/xorg.conf.d/99-fbdev.conf

add:

Section "Device"
  Identifier "tft35spi"
  Driver "fbdev"
  Option "fbdev" "/dev/fb0"
EndSection

Do NOT make these changes unless the display is connected to your CB1! For reasons unknown to me (I really am a Linux noob) the kernel will use all processor, making it hard even to connect to the board!

[TheFuzzyGiggler]

@paul_damian

BTT CB1 → (USB CAN Bridge) → BTT Manta E3EZ → (Canbus) → BTT EBB42

Out of curiosity, When you say CAN bridge, is this that wonky BTT connection where they use USB to connect to the board from the U2C adapter?

[paul_damian]

No U2C adapter. No need for it. U2C just exposes CAN if your board doesn’t support it. It’s just a processor that takes USB and translates it to the CAN protocol on processor pins.

The “Can bridge” makes the same. The SOC host talks usually to the MCU board over USB. But they also can talk Canbus, because why not. So the processors talk over the same pins another protocol. So in the case of Manta boards the host (Raspberry CM4 or BTT CB1) sits on top the board and the physical connection is a slot connector, not a cable. But the talk goes from processor pin to processor pin, like in the U2C.

[mykepredko]

You don’t have an accurate understanding how a CM4/CB1 is connected into a Manta board.

Electrically, the CM4/CB1 communicates with the Manta’s MCU using USB. All Manta boards have a USB hub chip built into them that provides a communications path between the CM4/CB1, the Manta’s MCU as well as the Manta’s external USB ports.

If you look at the second page of the Manta M5P’s schematic, the block disgram shows the USB Connection from the CM4/CB1 to the Manta’s MCU:

There is no “processors talk over the same pins another protocol”.

The CM4/CB1 connection to the Manta’s MCU is a USB connection in exactly the same way as if you were connecting a Raspberry Pi to a main controller board using USB.

The flow diagram provided by @TheFuzzyGiggler is the same if you are using a Manta with a CM4/CB1 to connect to a CAN toolhead as if you were using something like a Raspberry Pi 4B to connect to an Octopus (which also has a built in CAN driver) which then connects to a CAN toolhead.

[paul_damian]

Thank for you clarifications. I was over-simplifying it. I am unfortunately well aware of the USB multiplexer and the hub.

[paul_damian]

In the meantime I’ve thrown all what I could at the printer. Including webcam and Neopixels. Had some communication lost with the EBB42, but I cannot vouch for the cable. Will research and come back.

[TheFuzzyGiggler]

@paul_damian

The SOC host talks usually to the MCU board over USB. But they also can talk Canbus, because why not.

As Mike alluded to, and has been discussed before, the issue is this isn’t “CAN Bus”. It’s BTT trying to cut corners and connect the pin output of two mcus together but that in no way, shape or form conforms to the CAN Bus protocol.

It CAN be used, mostly in testing setups, but the distances have to be VERY short as in… trace length on the same board between MCUs, as there is no noise tolerance at all. That’s what the CAN transceiver is for as described in the CAN bus protocol.

It gets even worse when you try to run CAN over a USB cable which isn’t designed for it. The characteristic impedance of USB and CAN bus are different, and USB (and CAN bus if done right) are differential signaling while the output from the MCU pins is essentially UART.

People argue that it’s feasible. Can you get away with it? Sure. Is it reliable? No.

[paul_damian]

So would be the use of an IO2CAN device which connects/transforms the (SPI)IO from the (Pi)host to a CANBus more standards compliant / reliable?

[TheFuzzyGiggler]

Yes, Because it uses a CAN transceiver which handles the dominant/recessive bit needs and makes things differential. The board you linked also has the 120ohm termination resistor in place per the CAN bus standanderd.

They use a weird connector (looks like JST) but I guess that comes with the territory with BTT.

Then just make sure you use twisted pair wiring and that all your CAN connected devices are like this

Aka all connected to the bus in parallel and that you have a 120 ohm termination resistor at both ends of the bus for a 60 ohm characteristic impedance.

Then you’re good to go.

The pic says max of .5 meters (1.6 ft) but for the stub connection but that’s not true. The CAN Bus spec is per TOTAL length

Those are conservative estimates below to be honest.

If you want all the nitty gritty details, here you go:

slla270.pdf

[paul_damian]

Thank you very much for your effort and for the info.
Having an IO2CAN laying around I will put it to work in the upcoming days, when I’ll have a little time.
Yes, BTT has those JST connectors also on their boards, at least which I have seen. On the EBB36/42 toolheads they have Molex Microfit.

[TheFuzzyGiggler]

@paul_damian

Molex Microfit

Slight nit-pick, They are Molex MINI fit, or at least a knock off version of it.

Which is annoying cause my original CAN boards had micro-fits and I had crimps and connectors for those and the Mellow Fly and BTT used Mini-Fits which I have far less of. That and it’s slightly aesthetically aggravating since the Micro-Fits on the Huvud boards are legit black oness and the Chinese Mini fits are ugly giant white monstrosities.

Hard to tell from the pics besides the size difference but Micro-Fit has chamfered corners on one side only. Mini Fit is chamfered on both sides.

In general though, Micro fit is smaller and nicer looking IMO. But more expensive so BTT cut corners, AGAIN. Couldn’t even use the legit black Mini-Fits, they had to use cheaper flimisier knock off ones.

[paul_damian]

Well, this time I was partially wrong and you almost right

I have both EBB36 and EBB42 (both version 1.2). When I ordered them I thought I should also order some spare connectors and pins because at my age crimping is not my strong point. So I’ve looked up and on a Reddit thread (probably the same where you got the red background Molex picture) a user said that they are Molex Microfit 3.0, so I’ve ordered some from TME. It didn’t crossed my mind that the two boards have different connectors, didn’t even noticed that they are one black and one white. The boards arrived, the connectors also, but I didn’t care to open the package. Until today, intrigued by your reply.

So yes, EBB36 has the Microfit 3.0.

Left is the connector provided by BTT in the box, right is the connector bought by me. They fit perfectly.

On the other hand, EBB42 has the other white ones.

These are bigger, seems like a 4.2 pitch to me, and they are not Molex*), as you say. They have a “JMCONN” written and a number - 6. Google doesn’t return anything about this search term.

*) or is it a Molex knockoff? I try to look trough the Molex catalog, but for now I’m lost trough the product families (Sigma, Jr, Max, etc)

[mykepredko]

For the EBB42, I order the Molex Mini-Fit Jr 5557 with the appropriate pins. This is the genuine article.

If you’re familiar with Digi-Key, here are the connectors and pins:

0039039042 | DigiKey Electronics

0457501211 | DigiKey Electronics

[paul_damian]

Thank you. You saved me a lot of work finding the right part. Yes, Digikey is also present in my country.

[TheFuzzyGiggler]

You’re correct on the EBB36, I should have clarified. I only have the SHT42s/EBB42s with the white monstrosities.