Printer Model:BLV cube
MCU / Printerboard: Octopus pro v1.1. H723 version /Eddy (USB)/ EBB42 with E2C
Host / SBC :BTT Pi2
klippy.log
Fill out above information andin all cases attach yourklippy.logfile (use zip to compress it, if too big). Pasting yourprinter.cfgis not needed Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there
Describe your issue:
…Hi Guru’s
I keep getting this error, and don’t know how to fix it. Change cables and still the same issue.
Error message Error during homing probe: Communication timeout during homing
The canbus settings are set per the guides to 1000000 the others are connected to the pi2 USB 2 ports
Either after during homing or performing a z-tilt adjust I get this error. This is a newly built printer and I am trying to get it setup and beyond some wiring clean up I am almost at the point of doing a test print once I level the bed properly as I am getting the following error message after running the bed mesh calibrate
probe_eddy_current sensor not in valid range
Settings shown after running the bed mesh command
before the error message
Sample hit distance +/- 0.9984mm, time window +/- ms 8.3200
I think it is related to the SBC CPU load (look at the cputime ~0.3 ~ 30%). Probably RPI2 is just too weak.
Unfortunately, I do not have one to test anything or do profiling.
You can either:
Do profiling, or at least run the htop, to get an idea of what is loading your system.
You can try to update RPI further. 3.13 Python can work slightly faster. But I did not make Klipper benchmarks for that.
Replace SBC with something newer (it is 10 years old).
HI getting v late here will try that. the 1st bit. My pi isnt a raspberry Pi2 but the new BTT pi2 which should be more aligned with the pi5. So don’t think its a power issue, especially as designed for 3d printing in mind. Or should have been ;D
Well, anyway, the above recommendation does not change; you can still check what is loading your SBC with htop.
There is probably an SBC performance issue, or Klippy is doing something weird.
You can try to do the profiling while the LDC is running:
~/klippy-env/bin/pip install py-spy
# 100 is the sampling frequency. You can try to increase it until it breaks the Klipper process :D
# Larger is better (more precision) 1000 is good enough.
~/klippy-env/bin/py-spy record -r100 -t -f speedscope -p $(systemctl status klipper.service | grep -o "PID:.*" | cut -d' ' -f2)
Should do the trick.
Then I can try to look at the recorded data; maybe it will help.
Thanks.
should be more aligned with the pi5
RPI 5 is a beast and a bad point to compare against
(I do have it).
Lol well that sucks! But you would have thought something which comes from the same company which is aimed at their core business 3d printing would work really well together especially when everything I am using is BTT.
Thanks for the help with this appreciate the time and effort. Once off work I will run what you sent over and post the output after doing soem level checks to generate the issue and I will slow down the homing speeds
Did you want me to send the cfg for eddy and printer?
A Single Board Computer (SBC), or a similar device, isn’t inherently related to 3D printing - its relevance comes solely from running Klipper, the firmware that controls the printer. Essentially, it’s just the hardware executing the code.
BTT or not is pretty much irrelevant. On the contrary, well-known and reputable SBC manufacturers like RPi offer better overall packages. The more important point is, however, the Linux integration, and here BTT is far from brilliant.
Thanks, yeah I get that, HW vs software. The logic was that HW from a company which makes a SBC which lets face it, will 99% of the time will be used for 3d printing would also be optimised to run in this case Klipper well.
I have a pi4 which runs well. My bad got the BTT pi2 thinking it would work better, and be more compatible with my other components. Lesson learned. Thanks guys
Ok here is the result of running the speedscope. broke with 100 samples didnt even get to start a homing the file is a json just had to change the extension. I also edited the printer.cfg as there was a duplicate entry in the bed mesh section between it and the eddy.cfg.
I did increase the x and y homing (my ender uses these settings fine (raspberry pi4)). Initially when i tested this it worked fine Did @6 homings and tilts with no error. then retested and the error is back.
I also levelled the bed with the screw adjust and its pretty damn level ;D. but I still get the probe_eddy_current sensor not in valid range. Added my eddy.cfg file
The speed which eddy runs. if it actually created a mesh it would be great but may just go back to the old klicky
Unfortunately, the profile is almost empty.
I generally expect it to be taken while meshing, so when we see the high CPU load from Klippy.
About other services, there is not enough information, but I can guess that on RPI, they probably can use the HW acceleration which may not be supported on the PI2.
Probably, you can update Klippy with the Moonraker, instead of the custom script, or run the:
$ ~/klippy-env/bin/pip install -r ~/klipper/scripts/klippy-requirements.txt
...
# Already installed, so it is already used
Requirement already satisfied: msgspec==0.19.0 in ./klippy-env/lib/python3.13/site-packages (from -r /home/user/klipper/scripts/klippy-requirements.txt (line 21)) (0.19.0)
...
# Installed in the venv
Collecting msgspec==0.19.0 (from -r /home/user/klipper/scripts/klippy-requirements.txt (line 21))
Using cached msgspec-0.19.0-cp313-cp313-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.metadata (6.9 kB)
...
$ sudo systemctl restart klipper
I would guess that the obico or klipper screen adds load to the klippy process by actively communicating with it. The recent addition of the msgspec was made to make it cheaper (by CPU).
If it is added after those commands, you have to restart the Klipper process to make it utilize the new library.
What I will do tomorrow is do a fresh install and make sure to not install obico. Maybe do a minimal install and do a pure 3d print config. Will update once I do this. I have some spare card so can do this.
I had this problem myself, after switching back to 32-bit the problem went away, I've noticed it again on my other printers as well.
It's a known problem, I think Kevin O'Connor has already advised it somewhere.
I would suggest that if you still have issues after reinstall, it would be helpful if you provide detailed info on the new ones. I expect that, as you fixed the CPU usage, there will be no more timeouts.
@hardy8 I see, you are trying to be helpful, and this is really kind of you. But as far as I can tell, there were no indicators of CAN-related issues.
Even more, Eddy connected via the USB Serial emulation.
About 32bits, this is not directly related. General recommendation:
kernel 6.6+ if there is a lot of “byte_invalid” for usb2can. 6.1+ if there is CAN HAT.
There are similar reordering bugs in both CAN adapter types, which are probably less reproducible on the 32-bit. Not because 32-bit is superior or something, but simply because it is a coincidence. Both are fixed in the kernels 6.6+.
