I’ve just set up CAN bus, checked the 120R jumper. Do a couple of HOME ALL AXIS and still got bytes_invalid increase. I use a pair of wires from CAT5 as Can-L and Can-H. Tried to troubleshoot with some instructions but it’s hard to figure out what happen in this case.
Sometime, the machine does nothing but bytes_invalid also increase a bit.
… klippy (5).log (326.1 KB)
I flashed the latest version from BTT to my U2C, it’s built 11 months ago, it’s hard to tell if it’'s old or not as there is no time reference from the url you mentioned
I was searching the www for a command which gives any “FW version information” of the FW on an USB2CAN adapter. I was not successful. Does anyone knows a command achieving this?
I know about re-ordering problem before starting this thread but there is no way to tell if re-ordering is my problem or not
I dont know how to get the version of the firmware from U2C, I use the firmware from here U2C/firmware at master · bigtreetech/U2C · GitHub
as the last commit date of the file is 11 months ago, I expect that it should not be that old. Docs from Klipper page said old version but dont have any other reference so I don’t know if my version is considered as ‘old’ or not.
Make sure that both CAN endpoints have the same baud-rate set during make menuconfig and that this baud-rate is also reflected in the CAN interface settings
If you are running a 64bit kernel on your host, try switching to a 32bit one
I’m 100% sure baud-rate are matched, as otherwise I cannot connect to MCU.
I’m also pretty sure that I’m using 32bit as I’m using RPi 3B+ which has ~ 1GB RAM. Btw, how OS kernel version affect CAN bus?
I tried a couple of print and get mcu timeout. I cannot RESTART or FIRMWARE_RESTART.
I ssh into the RPI and try ~/klipper/scripts/canbus_query.py can0 and got error as attached screenshot. I suspect that the U2C may have problem so I unplug and replug the U2C and klipper can connect again.
Any idea?
There are two known causes of incrementing bytes_invalid on CANbus:
Old firmware on the “usb to canbus” adapter that is buggy. This could be the results of the firmware reordering CAN bus packets (known to occur on some old versions of candlelight_fw) or it could be lost packets on the USB interface (known to occur on old version of Klipper running in usb2can mode).
Buggy Linux kernel versions that are reordering CAN bus packets.
Unfortunately, it can be difficult to track down a solution for one of the above two issues, as it can be hard to determine which Linux versions are impacted, and it can be hard to update the firmware of the USB adapter.
It is important to note that “bytes_invalid” is not the result of:
not related to canbus wiring
not related to terminating resistors
not related to configured canbus speed
not related to txqueuelen
Those issues will typically result in a bus that does not function at all, or functions erratically with intermittent “Timer too close” errors.