I upgraded my printer with a BTT EBB 36 Can toolhead board. As I did not have a USB to CAN board (bus converter U2C) I wanted to use the board as a normal USB mcu.
To do so, I followed these instructions: Lab4450.com - Upgrade CAN EBB36 to a USB Toolhead
How I created my cable
dismantled a USB-C to USB-A cable
used a flexible, good quality cable with 11 individual conductors (LAPP Ă–lflex Servo FD 798 CP; obviously I only used 4 out of the 11 conductors)
connected one end to the CAN-Molex connector and the other one to 24V, ground and the data lines of the USB-A connector
USB-C data lines to Dupont Connectors as per instructions
so there is no 5V connection between my RPi and the EBB 36 board
Firmware
I flashed the board with the current klipper firmware via this self-created cable successfully
Added it to the klipper config and set everything up as per BTT instructions
Mainsail also recognizes the board (next to my original SKR 1.3)
My issue
When starting a print, the machine sometimes suddenly stops and Mainsail reports a connection loss to the EBB mcu. (see klippy.log: Lost communication with mcu) But this happens randomly. For example, I was able to finish a pressure advance tuning pattern and one stringing test, but since then every print already failed during the purge line.
When I first tried the board after installation, I also got those dropouts when only testing the part fans without even having started a print. But I cannot reproduce this at all now. Wiggling the connections on the print head does not lead to a dropout.
What I tried so far
Increased TRSYNC_TIMEOUT; I suspected that my cable might cause some additional delay. This did nothing
Checked cabling, but found no obvious bad connection
update klipper to the newest version (the log is from a previous patch version)
Things ruled out
I would rule out a software/firmware configuration issue, as I already got some finished prints out of it.
The G-Code is probably also not the issue, as I once had it stop during the skirt and the same file a few minutes later already stopped during the purge line.
There could be an issue with the ebb 36 itself, but I do not really know how I would eliminate this as an issue. So exchanging the board will be my last step.
Next steps
I would like to debug the issue further, by understanding the information from the klippy.log. Ideally, I would like to find out if there is some latency issue with my cable or a bad connection. From reading the logs I did not figure out where the timeout occurred and what the specific timeout was. I expected to find something in the terms of: EBB mcu did not respond in time. Last connection: Current Time: or something like that.
Can anybody assist?
Or do you think that it is probably the cable and the simplest step would be creating a new one? How would you go about that to not create a similar issue with the new cable again?
Do you have any recommendations for a good USB-C cable? And how would you go about severing the 5V and GND connections without breaking the cable? Are there maybe some adapters?
You don’t have to tear apart a USB C to A cable. If you’re running 24V to the Molex connector then all you have to do is pull the “VSUB” jumper (JP3 on the schematics) so that there is no +5V power connection between the host and the EBB36:
I also just tried a handwritten gcode file that simply moves the print head in circles without printing anything. That did not cause a dropout. But the printer was cold during that test.
So this might be something connected to real current draw when the orbiter is pushing the filament.
Edit: Regarding your suggestion: so without the 5V Jumper the EBB will not see anything from the 5V of the RPI USB? In that case, I can try with any USB-C cable, correct? That is a simple test case. I will try that tomorrow.
In answer to your question, pulling the 5V jumper will isolate the EBB36’s electronics from the Raspberry PI 3B’s. When I look at the SKR 1.3’s schematic, there is a diode on the VBUS (USB power line) between it and the SKR-1.3’s 5V supply, so you should be okay there.
How are the outputs labeled on the “No Name PSU 5V”? Are they “+V” and “-V” like on the Meanwell?
You need to have a single common ground on the USB Data Lines, which you don’t have now and if you add unmodified USB cables you’ll have a Ground loop (which is never good) from the EBB36 to the rPi to the SKR1.3 and back to the EBB26.
As a first step, why don’t you try replacing the two modified USB cables with stock ones and see how things work for you. There’s a good chance you’ll be fine.
If not then we’ll look at eliminating the Ground loop.
None of this is convincing me that this is the right thing to do - I guess what I thought was a jumper you’re connecting to in the first image is “P6” as per the EBB 36 schematic:
This approach may work but I would not recommend it without reviewing an analysis of the wiring used along with the impedances all along the USB lines.
I just got around to check this. The No-Name supply labels the output GND and +5. I also checked continuity between the ground on my SKR 1.3 and the No-Name PSU. And they are indeed connected, meaning that neither the Meanwell nor the No-Name PSU isolate the output from the input.
I also replaced my selfmade cable with a stock USB-c cable and started a print. Right now it is printing and I already got further then I was before. I’m printing the same gcode file.
This image is actually from the guide I used and mentioned in my first post. The USB data lines connect to the CAN L and CAN H pins. These are directly the ones behind the Molex connector. The image shows the dismantled USB-C cable where the data lines are terminated with a Dupont connector to put them onto the to CAN pins. They are doing this to use the same cable as was used for the CAN connection. I only replicated this because I liked that everything was contained in one cable.
I did not put a jumper onto the pins designated for the 120Ohm resistor (CAN Terminator), as I am not using CAN. Using the USB cable from the tower pc probably also would require dissecting.
However, the print is still running - so I’m feeling slightly optimistic. This means I will now permanently replace my modified cable with a stock one. In summary, I will then have one USB-C cable and one power cable as well as a reverse bowden tube to my print head, which is ok too.
I will let you know when everything works out after a few prints. Then I can be quite certain that it was the USB cable. (This is also the first suggestion in the FAQs)
If you have any more issues, I’ll have you check the impedance between the No-Name Power Supply “GND” output and the AC lines. They should be isolated but unless there’s problems let’s let sleeping dogs lie.
Still thinking about the USB/CAN cable modification and maybe it would work for short runs with USB 1.0 “Full-Speed” (12MHz with a 3m maximum cable length) signals. It definitely wouldn’t for USB 2.0 and later. I’m also not sure how the Raspberry Pi recognizes the part as there are no CC pin termination at the connector.
Anyway, I’m glad that you’re working and please be skeptical if somebody tells you to wire your own USB cable.
I’m running the same on my Voron v0 and was using it on another printer.
Works fine if done properly.
Only if the 24 V breaks away it can damage the EBB36 and the SBC…
There is no termination needed in either side of the cable. You connect the data lines with USB on the SBC.
