The problem is completely transient. I’ve worked with moggieuk on discord to enable an “ERCF homing retry” work around for it because you can retry and 99% of the time it’ll succeed the second time. We implemented it and after a few days of forcing tons of swaps I got several one-off instances that were covered by the retry and there was a single instance of “two-in-a-row”.
When I told him about it, he pushed an update to retry twice and I’ve been printing for a week so far without problems. He is logging the error as a warning behind the scenes so I can see how often it happens. On most setups, you home XYZ once and you’re good so people only see it occasionally during homing. It happens much more for me compared to most users because the ERCF performs homing moves several times for each filament swap. Some prints have hundreds of swaps so do potentially thousands of homing moves during the print:
spikeygg@voron:~/printer_data/logs $ grep Communi mmu.log*
mmu.log.2024-01-16:21:04:04 Did not complete homing move: Communication timeout during homing toolhead
mmu.log.2024-01-16:21:24:17 Did not complete homing move: Communication timeout during homing toolhead
mmu.log.2024-01-17:11:21:08 Did not complete homing move: Communication timeout during homing toolhead
mmu.log.2024-01-17:12:51:10 Did not complete homing move: Communication timeout during homing toolhead
mmu.log.2024-01-17:13:26:26 Did not complete homing move: Communication timeout during homing toolhead
mmu.log.2024-01-17:13:39:46 Did not complete homing move: Communication timeout during homing toolhead
mmu.log.2024-01-17:13:43:01 Did not complete homing move: Communication timeout during homing toolhead
mmu.log.2024-01-17:13:44:31 Did not complete homing move: Communication timeout during homing toolhead
mmu.log.2024-01-17:13:54:05 Did not complete homing move: Communication timeout during homing toolhead
mmu.log.2024-01-17:13:54:30 Did not complete homing move: Communication timeout during homing toolhead
mmu.log.2024-01-19:18:14:56 Did not complete homing move: Communication timeout during homing toolhead
mmu.log.2024-01-19:20:53:49 Did not complete homing move: Communication timeout during homing toolhead
spikeygg@voron:~/printer_data/logs $
This is all on the 32-bit OS and klipper v0.12.0-58-g25bc649c. Clearly the OS being 32-bit doesn’t solve the problem, for me. I’ve updated all my MCUs to the latest version of released klipper (currently: v0.12.0-85-gd785b396) and I check for updates every time I fire up the printer to make sure it’s up-to-date.
You’re right, it could be my MCU is faulty, could also be my CANbus cable is bad but I don’t think those are it since immediate retries clear it up and this thread with all the people in it aren’t all due to bad cabling and faulty MCUs.
Well Im sorry, this sucks. moggieuk is an awesome dude. He too is helping me with an issue.
Well Im glad you were able to get past this. This issue is very frustrating .
I still say though, that something is still wrong. Without knowing more details( not as if im a genius and will have the answer) I still believe something is still off with your setup.
I had this problem for ages… And couldn’t figure out why. I’m using a BTT Octopus, with SB2209 toolhead board and the onboard CAN adaptor. I had lots of timeouts, but no errors or interference showing in logs or diagnostics.
I tried:
switching Pi to 32 bit
increasing the TRSYNC_TIMEOUT
updating canboot/klipper
unplugging all devices other than the BTT Octopus from the Pi
Then last night I shortened the CAN cable (I’m using the one that came with the SB2209) to only what I need (removing the JST connector in the process) and twisted then soldered the wires to the RJ11 cable that goes into the Octopus. Then I carefully routed the data cables from where the power cables connect to the power supply to the mainboard, avoiding traversing any AC power cables.
This morning I don’t seem to have any issues any more, and not only that my TAP readings are a great deal more accurate… I haven’t had one measurement retry, whereas previously a gantry level or bed mesh would retry every second or third measurement because the results would be outside of tolerance.
It seems there are a number of things that can cause this issue, and unfortunately the available troubleshooting tools aren’t a surefire way of diagnosing the issue. I think if I had any advice for anyone else encountering this it would be try everything… And don’t rule anything out just because it doesn’t seem to make sense, or the data you’re seeing doesn’t point to it, because I did that for a long time and it prevented me finding the actual fix.
#EDIT: I should add that while increasing TRSYNC_TIMEOUT got rid of the timeout while homing error, the next print I put on failed because the hotend temp sensor stopped updating… That had never happened previously but it obviously plugs into the CAN board, so I have a feeling it was related, and anyway that’s what drove me to finally re-do the cabling.
I believe I’ve solved my CANbus communication timeout errors. In my case it turned out to be a bad MCU. The SB2040 I was using was slowly dying. A few weeks ago the logo LED on the stealthburner started acting up. The LED (just the center one) went green after firmware restart/klipper restart and would flicker randomly with other lighting animations. Also, I noticed in Mainsail you can click on the MCU and it brings up a bunch of registers for tracking details about the MCU. My SB2040 would commonly have lots of bytes_retransmit and bytes_invalid, this wouldn’t lead to a print failure but I only saw zero values on all my other MCUs. This made me quite suspicious of the SB2040.
Yesterday, I got a new EBB SB2209 and installed it and I’ve been printing and testing all day. The logo LED works again, there are no more bytes_retransmit and bytes_invalid counts and best of all I have run the ERCF/MMU swap stress test and the communication errors are gone!
Yet another example that Klipper’s underlying system is pretty stable but highly demanding when it comes to hardware quality.
Given the fact that 90% of Klipper is about timing quality, i.e. having the right information at the right spot at exactly the right time, this is hardly surprising but often underestimated.
While I don’t disagree with the statement, it’s very unusual for an MCU to degrade the way that @SpikeyGG is describing.
From what he’s observed, if I were to analyze the board, I would start with the 3.3V Buck power supply on the EBB SB2209, not the MCU.
@SpikeyGG - just out of curiosity (and I apologize for not reading through the 100+ messages on this thread) did you ever try to reflash the EBB SB2209? If you could then that would tend to rule it out as the reason for your problems.
I don’t understand what you mean by these statements… the EBB SB2209 is the new board that works without generating any errors. The Mellow Fly SB2040 was the original board that was taking on a slow death. I used the Mellow Fly SB2040 board continuously between February 2023 until three days ago – basically a full year. I flashed a new version of klipper firmware to it, regularly.
As I mentioned in the thread above, I had rebuilt the wiring harness and CANbus cabling between the SB2040 and my Octopus completely, because I assumed it was the cable. I even tried swapping the Raspberry Pi OS to 32-bit because someone suggested it on here. I really wanted to solve this problem and, apparently, I was cursed and had bad hardware from the start.
Apologies, I should have asked if you had reflashed the Mellow Fly SB2040. Thanx for indicating that you have.
That’s strange that the board is showing a “slow death”. I’m not convinced that the problem is with the MCU - I’d still be interested in see what the 3.3V power supply was producing.
Hi there. I’m having the same problem but I don’t use candlelight, I have a IO2CAN plugged on my Manta m4p. Only fix I found is to wire my 3dtouch on the manta directly. Everytime I plugged it on the ebb 36, errors during timeout… Anyone having an idea please?
