Printer Model: Ender 3v2 Converter into a Voron Switchwire
MCU / Printerboard: SKR 1.4 + BTT U2C + FLY-SB2040 CAN Toolhead klippy.log (696.9 KB)
Describe your issue:
I’m replacing the toolhead (going from an afterburner to a new stealthburner) on this printer, going from a BTT EBB42 to the Mellow FLY-SB2040 (the former was STM based, the new one is RP2040 based)
Everything was pre-flight checking fine as I was getting the toolhead going, endstops are being triggered correctly, fans work, RGB works, heater and thermometer work …
Next was to test homing … and an that point things started acting weird …
With the EBB42 I’m no stranger to an occasional Communication timeout during homing ?? error … but I’ve normally only gotten them with homing Z … ie the repetitive probe readings during mesh building or some such …
The thing that makes this issue a bit unique is that it seems to trigger IMMEDIATELY upon X movement … so the printer homes Y, then wants to proceed to X … and usually doesn’t move AT ALL on X … or moves a little bit … and then aborts with Communication timeout during homing x error …
Digging through the klipper mcu metrics … it doesn’t seem like there is errors on the can connection … or even srtt (which I’m assuming is the latency on the connection … I may be wrong) … seems very low (~0.001) …
Now I tried editing klippy/mcu.py and setting TRSYNC_TIMEOUT to a different value (restarting klipper each time) … I started with 0.05 (2x the original) … and no apparent change … then wen to 0.5 … still no change … heck on a whim I just set it to 50 … at this very high value it did stop getting this error … although it seemed to not even notice the x limit being triggered and continue to ram the toolhead into the side of the gantry …
QUERY_ENDSTOPS definitely seems to be registering when the endstop is pressed … so something else is going on …
It’s expected that your toolhead will ram into your printer when changing that value. You’ve told the printer to ignore the communication error and just keep going. Strongly recommend not changing that value and instead fixing the underlying problem.
What speed are you running on your CAN bus? These errors are often solved by increasing the speed. I run my bus at 1M and don’t see these issues.
Do you have 120ohm resistors at both ends of the bus? You can verify by check the resistance between CANH and CANL with the power off. It should read 60ohms.
I will double check, but I do have the jumpers in there …
So the SB2040 has a single jumper labelled CANBUS 120ohm … when its enabled … there is ~120 ohms between the H/L on the toolhead (when cable is disconnected, so its just measuring it on that end of the bus)
My BTT U2C … has a number of jumpers … two of them seem to control some of the secondary CAN transceivers on it … I did notice that the “main” can bus didn’t have a jumper on it … so I added that … thinking that hey maybe its this simple … but no …
so … after replacing the jumper on the toolhead (because it seemed like may not be reliably connecting when I was trying to measure the resistance) … and adding the jumper on the usb 2 can board … still no dice … no difference really … its still immediately aborting when it starts X movement …
Also strangely … I must have been missing this jumper on the U2C previously and I was having a STM based toolhead board work fine with it (an occasional timeout during mesh probing, but otherwise worked perfectly)
Occasionally timing out is not perfect. It’s indicative of a problem that’s only bad enough to cause intermittent failures. You need to make sure when the printer is powered off that you see 60 ohms between H and L. If you don’t, you will likely continue to have issues. It’s also unfortunate that Mellow didn’t use a twisted pair for the data lines on these boards as the CAN bus specifies. I personally cut the included wires and attached my own twisted pair, but it’s difficult to know if that will cause an issue on a cable this length
I would also suggest updating Klipper and reflashing the SB2040. Multiple fixes to the can2040 code were merged into Klipper as recently as this morning.
Ok … so I just applied the latest change from master (lib: Update to latest can2040 code · Klipper3d/klipper@1b56a63 · GitHub) … and this may have fixed it … perhaps along side all the other tweaks … I’ll do more testing tomorrow (I still have to fix my probe … but its now homing X properly so I can continue the initial setup)
Alright … so it does seem like the recent fixes in the rp2040 code fixed things … while there may have been some hardware issues … they probably would have added to some of the intermittant issues I had previously … the only change between the last attempts was updating to klipper @1b56a63 … that seems to have made all the difference … before that there was no noticeable difference at all … so it must have been something fixed here …
this changelog:
Clear PIO irq flags in pio_sm_setup()
Set TXPENDING during pio_sm_setup()
does seem somewhat significant … especially the second line … so there may have just been bugs in the rp2040 code up until then making this not work at all …
All I can say is my printer works without issue, and I’ve not yet updated Klipper to that commit. I’m using an SKR Pico running in bridge mode with a Waveshare transceiver running a pair of Huvuds and an SB2040 toolhead.
very strange indeed … must be some setup specific quirk …
I use a U2C board for the CAN connection … running the stock BTT fork of CL firmware … dunno if that matters … (could never get the official CL to work)
dunno, maybe poor wiring or something made this minor change manifest some particular condition or something … I’m running on the stock Mellow can cable … which doesn’t really provide a nice shielded twisted pair on the data lines or anything … so its probably terribly noisy in my setup
