I’ve been working on improving the diagnostics of canbus setups. I have a PR containing this work available at: GitHub - Klipper3d/klipper at work-canstats-20250114
Details of the work of the new diagnostics are in the PR description found at the link above.
Unfortunately, I don’t have a good test setup for this code (or, rather, it is fortunate for me as my local printer doesn’t report any canbus errors). If others are experiencing issues (or have a good test setup to inject errors) it would be great if you could test the code above and report results.
@mykepredko - this may interest you as I understand you’ve done a bunch of canbus tests.
-Kevin
EDIT: For those testing, it will require updating to the code on the PR and reflashing all micro-controllers using canbus.
5 Likes
Thanx Kevin,
I’m actually about to do some CAN Bus testing so you put this up at the perfect time.
The plan is to not have any CAN errors but if they pop up I’m sure this code will help me debug them.
1 Like
Hey Kevin,
I’m trying to implement it right now and I can find ~/klipper/src/generic/usb_canbus.c
but I can’t find ~/klippy/klippy/extras/canbus_stats.py
As far as I can tell, there is no canbus_stats.py
in the current build.
I’m going ahead and changing usb_canbus.c
with the idea that if the handling code isn’t in the Python libraries, any messages will be ignored until the correct file is updated.
Thanx!
The canbus_stats.py is in the PR - you can see it at: Improved canbus diagnostics by KevinOConnor · Pull Request #6784 · Klipper3d/klipper · GitHub . I’d guess it’s a bad pull. Try cloning the repo again, or you can also try pulling it from GitHub - KevinOConnor/klipper-dev at work-canstats-20250114
Cheers,
-Kevin
I thought that the changed files were part of the main branch - sorry about that.
I’ll remove klipper from the two machines I’m working on and clone the repo and work from there.
I’ll keep you posted as to my progress.
Hey Kevin,
I think I have the updated Klipper diagnostics on two systems with CAN bus devices.
To use the klipper-dev
branch, I decided to modify KIAUH rather than just run a straight git clone (I wasn’t sure how the dependencies would handle the code change and this would give me a clean install).
The changes I made in KIAUH are:
- In
kiauh/default.kiauh.cfg
for “repo_url:” GitHub - KevinOConnor/klipper-dev: Kevin's development repository for Klipper experiments.
- In
kiauh/default.kiauh.cfg
for “branch:” work-canstats-20250114
- In
kiauh/scripts/globals.sh
for "KLIPPER_REPO="GitHub - KevinOConnor/klipper-dev: Kevin's development repository for Klipper experiments.
- In
kiauh/kiauh/components/klipper/__init__.py
for “KLIPPER_REPO_URL =” GitHub - KevinOConnor/klipper-dev: Kevin's development repository for Klipper experiments.
Could you please confirm that these are the correct changes?
Now, everything came up correctly and seems to be working. Here are the klippy.log
files for the two systems:
desk-klippy.log (205.3 KB)
opi-kgp72-klippy.log (152.4 KB)
Now, I will go through and add the printer information and try a print or two.
If I encounter any issues, I’ll let you know.
Your logs indicate you are running the development code. I’m not entirely sure on the “proper” KIAUH steps. Be aware that I don’t keep the klipper-dev repo updated, so after the test you should return to the main repo.
Your logs don’t show any canbus errors, but the new statistics are present.
Cheers,
-Kevin
Hi Kevin
So at this stage this is purely exposing more diagnostic data from the “lower” CAN network level to aid with troubleshooting stuff?
I’m trying to read through the actual code changes but python/c is not my strong suit in the slightest. But I really want to follow along with this (as you can probably imagine).
Unfortunately I also don’t have any “misbehaving” CAN printers to actually test on myself.
edit
Oh, and commit 1d298ce about the usb-can-bridge node issues. Is that what is happening if you have a usb-can-bridge board but no second node connected (or not working) and then after a few queries/connection attempts the canbridge board stops showing a UUID/responding to klipper?
Right, the goal is to improve diagnostics.
Yes - the new code should be a little more resilient in that situation.
Cheers,
-Kevin
FYI, the work-canstats-20250114 code discussed here has been merged into the mainline Klipper repository.
-Kevin
1 Like