Basic Information:
Printer Model: voron 2.4
MCU / Printerboard: BTT octopus, SB 2209 RP 2040
Host / SBC raspberry pi 3b+
klippy.log I have a stack of them at my github. Please refer to klippy 6 and moonraker 6.
Describe your issue:
Just installed an SB2209 for canbus. I have been chasing issues with this setup since. I started in usb can bridge mode with my mainboard. This produced a rousing round of random and intermittent errors tnat I finally tracked down to the lousy. RJ11 port on the octopus. So i reflashed the octopus to bormal klipper (i think) and got a btt U2C, and followed Esoterical’s guide to set it up and even reflashed my sb2209.
During this I have replaced my SD card with a new samsung card, changed the usb cable twice, and even reterminated and moved my canbus cable twice. It is now direct psu linked, and running entirely outside the printer
It works, for a while. The errors of missed last digital out event keep happening however. This is entirely random when it will occur. However it never takes more than 6 hours. The printer halts, and I cannot get it back online with a firmware restart. I have to restart my raspberry pi, then my firmware still takes 2-3 restarts to come back online.
Im out of ideas other than replacing the brand new cable, or replacing the pi entirely. Id love some advice on anything I may have missed or overlooked.
…
Args: ['/home/Oghma/klipper/klippy/klippy.py', '/home/Oghma/printer_data/config/printer.cfg', '-I', '/home/Oghma/printer_data/comms/klippy.serial', '-l', '/home/Oghma/printer_data/logs/klippy.log', '-a', '/home/Oghma/printer_data/comms/klippy.sock']
Git version: 'v0.12.0-143-g01c7befa-dirty'
Untracked files: klippy/extras/gcode_shell_command.py
Modified files: klippy/mcu.py
The first issue is you’re using a modified mcu.py.
No one will be able to help you because we have no idea what you modified.
Well color me surprised, because I have no idea what got modified in there either. I cannot recall ever opening this file to modify it. Just in case I did, and forgot, I’ll see if this is in my printers files, and add it to the git repo. I might have to wait until tonight since as I type this I’m getting ready for work.
Yours should show something like this…
(Mines a little extreme because I’ve been messing around testing out a lot of different things).
You can click on the “dirty” drop down and do a hard recovery to get all your files back to Klipper standard.
Ill take a look. I just started a print. I changed the usb cable, and the usb port on the pi last night, and got my first successful print of a file that has failed 5-6 times.
I dont trust its fixed, and the only way to test is long prints. Ill check if there is a “dirty” drop down, because I know for a fact I have never opened anything in the extras section in the file editor, putty, or winscp. Will still pull said file however.
well thats strange…
ill poke it tonight.
I forgot to add, Welcome to the Discourse!
I have a habit of jumping right in to solve issues (which is what most people want anyways).
1 Like
Thanks for the welcome.
So ran another print, and as expected, it failed. I have attached the log to my github, labeled as klippy9, and after repairing the MCU.py I got errors from shell command. So I removed the include in my config, and killed shell command entirely. I haven’t been using it anyway. I have not run another print since the repair, but I can.
Someone on the Voron forum mentioned there might be an issue with 64 Raspberry pi os installs and CANbus. Any information on this being a possibility?
I’m going to flash a fresh SD card, so nothing else on the rest of the system will change. I’ll be importing my current config files (Saved right after that repair you mentioned) and stuff that in my Pi after the print I just started fails. So likely in the morning.
Can you describe how you have this all connected?
As in, What’s your physical wiring setup?
I sure can.
Pi3b+ usb>Octopus
Pi3b+ usb>BTT u2c v2.1 Canbus>SB2209
The Octopus is on it’s own USB, with a power cutoff module between the pi and the octopus. Ran fine and still works fine.
The Pi is then running USB to the u2c, which has the SB2209’s provided cable attached for CAN H and CAN L. Power for the SB2209 is directly attached to the PSU to avoid low voltage issues, as the u2c couldn’t provide enough power. (edit) sorry, forgot to mention, the CANbus cable is currently run outside my printer. There is about 6in inside the electronics housing to accomodate the Can connection to the u2c, and power. The Can wires are twisted, and nowhere near any motor wires, or power leads.
Also, being a Voron 2.4, it has a dedicated meanwell PSU 24v to 5v for the RPi.
Just to make sure, you have the jumper in place for the 120 ohm resistor?
Edit: You’ll need it in place on the U2C also. CAN Bus requires 120 ohms at both ends of the bus.
Yes sir, triple checked both to make sure I hadn’t knocked one loose. Both are present at this time. Any chance you can highlight where to attach my multimeter probes to verify with a continuity check?
edit: So that diagram isn’t quite the same as mine. I’m on the RP2040 version, so the 120ohm resistor is right next to the thermistor plug.
Checked again, yup. Still there. I can’t remove the jumper without removing the entire board from my hotend. I managed to very gently finangle it into my CW2, without printing the new shroud and motor plate.
If you probe the CAN H and CAN L while measuring resistance with your multimeter (with the power off, obviously) you should read 60 ohms (2 x 120 in parallel)
And you’re right, I just scrolled back up and saw you write RP2040 version.
(Sorry if this is a dumb question, but I’m tired)
So correct me if I’m wrong, cause I’m no electrician or electrical engineer, but probing the wire itself should reveal no resistance (or close to none?) I’d need to have the probe on one side of the resistor on the toolhead board, and one on the resistor on the u2c to get the right reading? Or maybe on a jumper pin?
My understanding must be missing something here, so please, relieve my ignorance, I’m honestly confused. Willing to learn, but confused.
(do apologize, I need to sleep. It’s 10pm here, and I have to be up for work at 5am. I’ll post when I can)
I’ll poke it in the morning. It’s running ATM, and I’m going to flip a coin on it actually finishing. Maybe I’ll get lucky. (Not a chance.) I’ll let you know what the multimeter shows, based on probing can H and can L.
No dumb questions, never a bad thing to ask for clarification.
If one end of the wire were twisted together (or connected somehow) then yes, you’d see very small resistance, close to none.
But with the CAN cable connected to your boards, it completes the circuit for the CAN Bus and since you have two 120 ohms resistors at each end (the termination resistors Rt in the picture above), it’s them in parallel, or 60 ohms.
Short hand EE trick, If the resistors are the same value in parallel you can just divide by the number of resistors. E.g. in this case if there were 3 in parallel it would be 40 ohms (120 / 3)
For different valued resistors in parallel it’s the “reciprocal of the sum of reciprocals”
1 Like
Okay, so that makes sense now. I thought the resistor was only on one wire, not making the entire loop into a circuit. That clears it up for me nicely actually, despite my tiredness this early in the morning, I get it.
Updated my logs. I now have an MCU disconnect error from the last print, and the logs, so now I have a log after the repair of the MCU.py that you mentioned, don’t know if that hleps. (This time I got some usable parts at least.)
You’ve got signal degradation, which usually means a bad CAN Bus cable or loose wiring/bad crimps.
You might undo the CAN bus cable and use your multimeter and check the resistance at both ends for each pair (CAN H on both sides, CAN L on both sides) and while testing it move the cable and connectors around a bit and see if the resistance starts bouncing around or drops out altogether.
It flattens out after your disconnect
RTO spiking means your SB2209 isn’t responding with acknowledgements to commands.
SRTT (Smoothed Round Trip Time) and RTTVar (Round trip time variance) are rising.
bytes_invalid is the real red flag though.
If you haven’t already you might try the troubleshooting described here:
https://www.klipper3d.org/CANBUS_Troubleshooting.html
1 Like
Alright. Once I get home im going to redoo the termination of the U2C side of the can cable. The other side is factory, and rubber jacketed. Ill repon the can wires into a new plug on the u2c as well.
Hey again, so just relocated my can pins on my u2c, and chedked resistance. Got 60, to about 62. It tended to move a bit ad my hands shifyed or moved the probe leads. Managed to hold real still, and it sat pretty happily at 60. So yeah, seems the resistors are working (maybe temp is makifg a jumper misbehave? I can work on that angle later)
So, on that note, I removed a little pigtail i made from the wires before this, so its only factory crimps. So I’m willing to bet good money on that little pigtail i used to avoid recrimping the stock cable being the source of my frustrations.
As I type this, i have my tools and materials, im recrimping, and printing again.
By the way, I cannot thank you enough for the information on why you (and I) believe its the cable. Nobody I asked in the voron discord or forum would even go near the logs.
If youd told me to change the cable, or recrimp it, even without the graphs and other info, I would have. I just wanted to know where to go next, and you have given me that direction.
Thank You.
Well, I have a new log for you, and pretty much all the alerts are now appearing when I try to print anything. Undervolt and throttled are it’s new things, and I can’t even get it to start a print. This is just lovely.
I’m deeply regretting ever even thinking about using canbus for this worthless pile of scrap I call a printer. I get more consistent usage out of my ender 3 at this point.
Serious question apart from the cable issues. (I’ll replace the cable tomorrow night, I’m exhausted and am going to bed). I loaded this as a 64bit OS. Someone else that was having issues replied to my voron help request (It was before I came here, nobody replied except this other guy with the same issues). He just reinstalled his OS to 32bit, and informed me he got his system working, and the errors he was seeing at start are gone. This anything concrete, or just cause it was an OS re-image?
So first off, Let me put this into perspective… and this isn’t actually supported by klipper right now (hence why my repo is dirty, among other things)
I also have a Voron 2.4, and I have… Count em’… 7 CAN bus toolboards
1 for each of my Z-Drives, 1 for each of my A/B Drives and the one on my toolhead.
It works rock solid. So definitely don’t think CAN Bus is “experimental” or something. It can be frustrating sometimes but, at least in my experience, it’s usually always down to wiring or settings.
Second, Did you do the troubleshooting here?
https://www.klipper3d.org/CANBUS_Troubleshooting.html
It could very well be your txlen settings and nothing to do with the cable. I just wanted you to test if you had an intermittent connection.
Third - I’ll have to look at your Klippy logs here in a sec.
