that fixed my issue, worked like a charm.
I am having the same problem with the “communication timeout while homing”. For 4 months I had no problem then about 1 month ago this problem started. I updated klipper on my Octopus PRO 1.1 (446) and EBB36 though DFU but this did not help (Running in bridge mode). I now cannot print as typically fails during QGL but sometimes at the start of homing before QGL. I have the jumper on the 120 Ohm resistor installed on EBB36. I even made a new extruder and wiring replacing the stealthburner with an XOL2. I am thinking of replacing the EBB36 with a new one but need to go though the flashing process. But before I do, can you look at the Kippy file which shows the problem.
klippy (6).log (655.2 KB)
BTW. I am using a BTT PI PAD5 with PI4 compute model 4Gb memory / 32Gb storage. Shielded canbus cable from IGUS and a pre-crimped 4 pin molex end soldered to the canbus cable. On the toolend the cable is fitted to a flexible M12 cable gland so really good connection and no flex after the gland connection to the EBB36. The sheaving on the IGUS cable is earthed on one end too in the electronics to reduce any electrical noise.
Follow up to above:
I replaced the EBB36 board and the problem is still present. BTW, I used a voron tap for z-probing on the stealthburner for 4 months then had this comm problem. In the XOL2, I have switched to the beacon probe but still have the same problem. Please help?
Solved!!! I made 1 change to the system before it stopped working- adding a webcam (a high resolution Brio). As I was changing other stuff as well, it didn’t occur to me that this may be putting the RPi under stress. After removing the camera, I can now report that the communication timeout has disappeared.
Just thought I would add to this mess of “Communication timeout during homing probe”
I have a number of machines, all running tool boards, all of them suffer from this issue.
I can confirm what it is not (with my machines):
- It is not related to CAN BUS, as I have this issue, when using USB mode or CAN BUS mode
- It is not related to cabling or interference as I always have zero comms errors, I have tested can/usb data wires external to the printer, twisted, non twisted, all will always yield the timeout error.
- Adjusting the Affinity of Klipper will not resolve the issue
- Adjusting the trsync value will not resolve the issue
- Using older or newer Armbian kernels will not resolve the issue
- Changing tool head brands will not resolve the issue
- It is not related to USB power, as I have tested with 24v Industrial powered USB hubs
What I have discovered, is if you have any other USB device, like a touchscreen, USB camera or WIFI dongle, you will start to see this issue, if you have nothing but the tool board connected, you will not see this issue. each device you add, the more likely you are to see the dreaded “Communication timeout during homing probe”, even if you are not actually using these other USB devices, just the fact they a connected, is enough to cause you isseus.
If I unplug all of the USB devices and just run the toll board, I never see the issue, I have also checked, it has nothing to do with CPU usage or memory as these are I rarely see anything near 50% utilisation.
The control board I use is the MKS-SKIPR, if you use CAN you must use a USB loop back cable to use CAN, so this USB issue still affects CAN, I found that using USB to control everything to be simpler and more reliable, but I have not found a way to run anything more than just a tool head reliably.
If I have to use a second host, or a more powerful host to eliminate this issue, then it makes these integrated boards all but useless when using a CAN/USB tool board.
Too much attention is being placed on CAN or CAN related things as the issue, but I can assure you, it is NOT related to just CAN, it’s a gremlin in the system, and is related to some timing issue when USB devices are being used.
My next test to try and eliminate this issue is to use an i5 mini PC to control everything and see if the problem persists, the issue we see may be related to the architecture of the ARM SOC we use and this is why some have the issue and others do not, but until the exact cause has been identified, it makes these setups nothing more than experimental, I have even seen machines form QIDI TECH having this exact issue, I believe even a reviewer on YT mention it, and those machines are using USB to control the tool head.
So at the moment, my advice for others having this issue, try unplugging all USB devices except for the tool board and see if this fixes the issue.
Okay, I have setup Klipper and all of the printer hardware through an Intel dual core i5 mobile chip running Debian Bookworm 64bit, and I have the following hardware connected:
USB-C hub using a USB-C to USB3.0 adaptor
Connected to that hub I have a USB Gigabit connector and another USB 3.0 hub
To that hub I have a MKS-THR36 in USB mode, a MKS-SKIPR direct to the STM MCU, 1 x USB Camera and 1 x USB Touch Screen.
So one janky setup, and no issuses with communications timeout, it looks like its a OS or SOC issue, definately not an issue with Klipper itself, these host controllers are just not good enough to handle additional hardware reliably, if you limit them to a headless setup, they operate perfectly, but each additional device you add, the more unreliable they become.
I think I will switch to x86 platform and stay there untill better host controllers are employed on these AIO boards.
I recently switched my Fly-Sht36 v1 to a v2 of the same board.
Firmware on the new board is v0.11.0-267-g01ed8096, on the old board, it was v0.10.0-544-g49d83bd3. The MCU is the same on both boards (STM32F072).
I swapped over the wires 1:1, same length. All connections on the toolhead remained the same and were just plugged from one to the other.
The V2 has shown the communication timeout while homing Z multiple times, while the V1 hasn’t done that in several months of regular printing. During all of this, there’s never a single byte_invalid. There are always 9 bytes retransmitted, but this appears to come from the printer start only, they never go up.
I’m wondering now if firmware 0.11 introduced some sort of issue.
To verify, I just flashed the v2 with the old firmware… no difference. What seems to have made a difference was to increase the probe offset. It was previously at 0.375, it’s now at 1.45 (by moving the probe physically down) and I’ve not had any issues since… makes no real sense, but it worked as soon as I changed that.
It’s pretty random isn’t it? I’ve been chasing my own tail for many months on this issue when I caved and signed up for this forum so I could join the “party"
I just want to use a select hardware and software configuration that reliably works, as I’m developing several 3D printers and tool heads, but this issue keeps showing up, like a nasty ex-partner, changing the host system to something with more “balls” has fixed the issue, for me…so far.
I have been testing with a default Debian CLI install of Bookworm, which Im not fan off due to the additional work required to get an operational system, but it works perfectly, I’m now installing Armbian x86 Bullseye, and I will test again, as this OS with an RKM chipset (Makerbase PI Hardware) is where I was having issues, if the issue is still resolved, I will move away from using ARM completely, I need reliability and I don’t think any issues are related to Klipper and any of the related software packages itself, I believe it’s an architecture issue related to USB/UART, as in order to use CAN you must first go through USB, so it will effect most using CAN and will affect others like myself that are just using USB with multi MCU.
What has led me to using a more powerful host is the fact I did my initial testing of using 2 x control boards in multi MCU via a laptop running Linux Desktop, and I had no issues, although these boards were different to the current ones, I believe it was not the control boards being different that was causing my issues, but it was the host architecture, maybe the issue is related to certain SOC’s like the RKM, maybe we should start a new thread listing the hardware and the OS we are using when we see this issue, then maybe we can nail it down to a common hardware choice that causes the issue so others can avoid this combination?
Just created a new bed mesh twice and printed twice, no issues whatsoever since increasing the probe distance… really weird.
I run a Raspberry Pi 3B (not +) and a Pi 2 Zero W on my CAN printers. Except for this issue with the probe offset for unknown reasons, I’ve had zero issues since going 32bit (still on Buster), no lost packets, no disconnects or timeouts in lots of highspeed prints in half a year or so. Running 500k speed, ADXL measurements are also perfectly fine.
The 32bit OS seems to have fixed others issues as well, using the Makerbase gear, I dont really have that option myself, but Im good now, I can buy Dell 7040 Optiplex USFF machines for less than a Raspberry PI 4, and they have 128GB SSD’s and 8GB of ram, and can run multiple cameras and if I like, multiple machines, so I’m pivoting away from these underpowered ARM based SBC’s going to stick to Intel x86 running Armbian x86 directly off a USB Flash drive, been testing this setup for day now, and works extremely well.
Also are you running any additional devices, like USB wifi, USB cameras and USB touchscreen?
As this is where my machines fall over, just the control boards are no issues, but as you add each extra device, the likelyhood of the homing timout increases.
Having similar issue “Communication timeout during homing…” running BTT pi board with a screen and camera also connected via USB.
Issue began as soon as I activated the camera in settings. Attempting a reflash of the SD card.
Reflashing worked. Not sure what the issue is here that’s causing USB to fail.
Most likely the performance of the host, my machine has been dynamite since I swapped over to an intel host, no issues with running multiple USB devices, cameras, hubs and USB flash drive for the OS, its 100% now, no sign of a timeout anywhere.
After making this change I then get "EBBCan’ Unable to connect Error…
Thank you so very much for this. I spent 2 days just on this. wasted a bunch of cables and microfit pins. (stuff is expensive). Anyways. I think this should be posted on all forums that talk about Canbus.
Yeah 32 bit os is the fix for this.
Thank you again. I wish this was pinned everywhere.
32 bit is not the solution for me. Fresh setup with ‘old’ printer.conf. same problems as before…
Maybe give this script a go: zippy-klipper_config/scripts/mcu_timing.sh at master · rootiest/zippy-klipper_config · GitHub
This is not the solution. Yesterday, I took a new SDCard and installed 32-bit Bookworm set up my entire printer in the new environment to run my stress test and it still failed with Communication timeout.
I have 64-bit Bullseye and 32-bit Bookworm failing with Communication timeout errors.
I’m running a CANbus enabled ERCF which uses MoggieUk’s HappyHare software. His software performs a bunch of homing operations during filament changes, so every swap is a possibility to trigger this issue. His error message looks like this:
error: Did not complete homing move: Communication timeout during homing toolhead
I have a test print that stress tests swaps and so far, I haven’t found a solution. He’s considering a “retry” but that’s really just a band-aid without knowing what is really going on. 
Are you saw you didn’t make a mistake and installed the 64bit version again ?
not being sarcastic.
If not, then you probably have a different problem i.e your canbus cable might be faulty or you got a board thats faulty, or your board’s firmware is faulty, and you might need to update or change the firmware.