Something is changing my can0 speed afterboot, it isn’t the rc.local file

Basic Information:

Voron Trident
Octopus pro v 1.01 running usb can bridge Ebb36
RPI 3B+
klippy.log

klippy (2).log.zip (1.9 MB)

Describe your issue:

…Our power went out yesterday, Thankfully almost immediately after I finished a large print. When the power came back on I got MCU unable to connect.

I started by checking all cords tried a power cycle and finally started going down the checklist software side. Long story short,

when I do a can query I get this

~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0

Traceback (most recent call last):

File “/home/pi/klippy-env/lib/python3.11/site-packages/can/interfaces/socketcan/socketcan.py”, line 679, in _send_once

sent = self.socket.send(data)

       ^^^^^^^^^^^^^^^^^^^^^^

OSError: [Errno 100] Network is down

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

File “/home/pi/klipper/scripts/canbus_query.py”, line 64, in

main()

File “/home/pi/klipper/scripts/canbus_query.py”, line 61, in main

query_unassigned(canbus_iface)

File “/home/pi/klipper/scripts/canbus_query.py”, line 25, in query_unassigned

bus.send(msg)

File “/home/pi/klippy-env/lib/python3.11/site-packages/can/interfaces/socketcan/socketcan.py”, line 658, in send

sent = self.\_send_once(data, msg.channel)

       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File “/home/pi/klippy-env/lib/python3.11/site-packages/can/interfaces/socketcan/socketcan.py”, line 681, in _send_once

raise can.CanError("Failed to transmit: %s" % exc)

can.CanError: Failed to transmit: [Errno 100] Network is down

I manually shut down can and reset the bitrate and the query shows everything is fine, I sudo reboot and same problem, I query can and same as before I checked the rc.local file and its blank and this is the extent of my knowledge in all things klipper.

Has anyone experienced this? And can anyone give me some ideas of what to check or try next?

Thank you in advance for taking the time to help me.

Edit

Additionally if someone could let me know a more elegant method of including the response I get from my RPI when I post here to ask a question I will be sure to do so.

Just reading through this and your klippy.log (thank you for that).

From what I can see, it looks like it can connect to the MCU, the problem is with the CAN Bus or the CAN Bus device (ie the EBB36).

How did you set up your system software (ie what are the instructions you followed to set things with the CAN Bus up)?

In the klippy.log, it looks like you reflashed the Octopus’ MCU.

Did you check that the EBB36 is still working? If you loaded Katapult onto it, can you get back into Katapult (ie double clicking reset) and is it recognized using:

python3 ~/katapult/scripts/flashtool.py -i can0 -q

The other thing I’m wondering about is if the various files/apps on the rPi got trashed when you had your unscheduled power outage. You may have to reimage an SD Card and try again.

I used Esoteric can bus guide when I initially set up can, and used the official Klipper documentation when I set up klipper before that. I was able to connect to ebb36 no problem at all (using katapult), which is weird because My RPI is connected through usb can bridge Via the octopus, but when I tried using the UUID to connect to the octopus through katapult it wouldnt work. until I manually reset can and the bitrate which is how I was able to reflash the octopus, however after resetting I get the same problem. I guess I will re-image the RPI, but I will do some more digging first because the seems like an excellent opportunity to learn, and get to know Linux/bash/ python/klipper etc some more.

My thoughts were the same about the files on the RPI, and my thought process almost matches what it appears yours is when diagnosing, which is nice because it tells me that I am thinking the right way, so thank you.

Edit: after some digging i think the problem is that after an update that I did yesterday in addition to, and right before the power outage, my CAN network stopped working, I didnt reset my system after the update, and went right back to printing so the power outage may not have been the issue, it was just the major event that stuck out in my head, distracting me from thinking it was the update issue

I’ve learned that Bookworm switched from dhcpcd to NetworkManager, and the old configuration files in /etc/network/interfaces.d/ are no longer used. This means the scripts and configuration from Esoterical’s guide for the older OS are now ignored. The new networking is managed by NetworkManager.

I’m now looking to reconfigure my CAN bus to work with NetworkManager. I believe this is the core issue and that the solution lies in setting up a new network connection profile.

does this sound plausible or am I overthinking the issue?

Their are differences in setup for canbus from Bullseye to Bookworm. I’m not sure what page you are looking at for Esotericals guide but I added the link below, you will see the systemd commands needed on a fresh install. Following that fixed up my Idex printer when I changed to Bookworm.

Wait, wasn’t this section different before?

Yes, originally the “default” method of configuring the CAN network was using a can0 file and the ifupdown network service. However, ifupdown is being phased out by newer linux distributions. The more universal option seems to be using the systemd-networkd service instead. The good news is that this seems to be installed (if not enabled) on most linux distros we’d see on 3d printers. So streamlining the process down should make it better for everyone.

Also I added the below setting, link is to my post on Esoterical’s issues page, you may or may not need it. It was related to a long pause on boot if i recall.

Hope that helps.

YESS thank you, I did go through this and it fixed it, even before seeing you response, I neglected to post that I had figured it out just in case I was mistaken. This was a frustrating yet really educational error to have experienced. Big thank you to you and others that were patient and helpful with me along the way.