Issues with CANable - General Discussion - Klipper
anchored to [[410.00_anchor|410.00_anchor]] source: klipper.discourse.group read - estimated by firefox: 59–74 minutes
Hi,
I can’t post all the links as new user, so I put them all here: Kit: https://www.3dptronics.com/electronics/56-621-voron-24-complete-ptfe-wiring - Pastebin.com 18. I will refer to them in the body of this post. Sorry for the inconvenience.
I have Voron V2.4 350x350 with recent Canbus (EBB36) upgrade, using CANable adapter (1st link). Raspberry Pi 3B+ (32 bit kernel) and Octopus board. Upon install and setup, I had issues of random error “Lost communication with MCU ‘can0’” while printing. Following this post (2nd link), I found out that it is not hardware/wiring issue, but firmware issue, because ip -details -statistics link show can0 reports no dropped bytes, but mcu can0 interface statistics on Mainsail reported lots of bytes_invalid and bytes_retransmit.
I followed the advice in that post, and flashed updated firmware(3rd link) to CANable via dfu-utils. This got rid of the bytes_invalid and bytes_retransmit (both stayed at 0 even when testing).
However, my printer still randomly shuts down during bed mesh sometimes with the same “Lost communication with MCU ‘can0’” error. Klippy.log ends with Got error -1 in can write: (11)Resource temporarily unavailable'. If I run sudo dmesg, I get several Under-voltage detected! (0x00050005) errors. However, if I run vcgencmd measure_volts core (as well as sdram_c, sdram_i, sdram_p), I get completely nominal voltages.
Here are a few screenshots: (4th link)
My klippy.log: (5th link)
I am pretty sure there should be no actual undervolt, because everything was working fine before I added CANBUS to my printer setup. Can anyone help me figure this out?
How are you powering the rpi?
Undervoltage is to be taken seriously.
I am powering it via the 5V PSU on the Voron
That PSU is supplying 5.1V. Rpi is receiving 5.1V as well (I measured at both ends).
P.S. I added an extra 5V and GND wires from the PSU to the other pins on the Rpi, just to add some redundancy in case something is shaking loose, although connections look really strong and crimping is good.
It’s probably not your problem but you should never have multiple power/ground wires in parallel as you can get induced voltages with the ground/Vcc loops that you have added to the system.
A better place to look is how you made up your CAN bus wiring. How was that implemented?
Thank you for your reply. I had this whole issue even before I added these additional wires to Rpi. I can remove one pair and leave only one pair of really thick wires. However, when I added these additional wires yesterday, I stopped getting undervoltage warnings. Bed meshes seemed to work, so I thought maybe the issue is fixed, and tried another long print - and got a new error message some 4 hours into the print:
(Also attaching my Klippy.log, I trimmed the middle. But it really doesn’t show anything relevant that I can see).
Sudo dmesg shows this:
Some kind of “power save enabled” that I have never seen before. Not sure if this is relevant or not. This might have happened some time after the print failed, because I left it overnight and found it dead in the morning.
To answer your question about wiring, I am using the pre-crimped wires supplied with that kit I linked to. 4 wires in total. They are crimped onto a 4 pin connector, and connected to the EBB36. I am using several zip ties and strain relief gland to make absolutely sure the connector cannot move in any way when the toolhead moves. That part is rock solid. The wires then go through the umbilical sleeve into the electronics bay. CAN_LOW and CAN_HIGH are connected to the terminals of CANable and screwed down tight. 12V wire goes to the 12V PSU output, and GND goes to 12V PSU ground. Another wire goes from the third CANable to terminal also to the 12V PSU ground. CANable is connected to Rpi using a high quality 30cm USB cable. Let me know if this is what you wanted to know.
Thank you for your reply. I had this whole issue even before I added these additional wires to Rpi. I can remove one pair and leave only one pair of really thick wires. However, when I added these additional wires yesterday, I stopped getting undervoltage warnings. Bed meshes seemed to work, so I thought maybe the issue is fixed, and tried another long print - and got a new error message some 4 hours into the print:
I can’t attach my Klippy.log because of the damn forum restrictions, I will post it in separate reply.
Sudo dmesg shows this:
Some kind of “power save enabled” that I have never seen before. Not sure if this is relevant or not. This might have happened some time after the print failed, because I left it overnight and found it dead in the morning.
To answer your question about wiring, I am using the pre-crimped wires supplied with that kit I linked to. 4 wires in total. They are crimped onto a 4 pin connector, and connected to the EBB36. I am using several zip ties and strain relief gland to make absolutely sure the connector cannot move in any way when the toolhead moves. That part is rock solid. The wires then go through the umbilical sleeve into the electronics bay. CAN_LOW and CAN_HIGH are connected to the terminals of CANable and screwed down tight. 12V wire goes to the 12V PSU output, and GND goes to 12V PSU ground. Another wire goes from the third CANable to terminal also to the 12V PSU ground. CANable is connected to Rpi using a high quality 30cm USB cable. Let me know if this is what you wanted to know.
P.S. Before this new error happened last night, I also added a jumper on the “120R” pin on the EBB36, because I found some info that it helped some people. Apparently it didn’t help in this case.
On one of my printers I got the “Power Save Enabled” warning when I was powering my Raspberry Pi from a Mac that was nearby (I didn’t have a 5V AC/DC hooked up at the time). I replaced the PC/Mac connection with a Raspberry Pi wall wart and the issue went away.
When you say “one pair of really thick wires”, what do you mean? For my current connection, I’m using 16 AWG connected to a 5A AC/DC bulk supply soldered into a USB C prototyping connector for powering the rPi:
For a straight Raspberry Pi that isn’t powering anything, this would be overkill but in this printer the rPi is mounted to a BTT PITFT5.0 touch panel. When I measure the current on my bench supply in this configuration, it’s about 3.2A and 16 AWG is appropriate.
If you have a Raspberry Pi with no display mounted to it, the maximum current draw I’ve observed (with the rPi not powering any external devices) is 1.4A so you’ll want to use something like 20 AWG or 22 AWG to make sure your power cable losses are minimal.
I’m going through this level of detail because when I look at the schematics for the various CANable versions (1.0, 2.0 and Pro) it’s MCU is being powered by the Raspberry Pi. I’m guessing (based on the datasheet) that the CANable is drawing 200mA or so.
Now, you say that you are using an Octopus board, did you pull the USB Power jumper? If you don’t, the rPi will be providing 5V power for the entire board even when there is a bulk supply - expect the Octopus to draw at least an Amp with the stepper driver modules installed.
So, my big question is; what do you have attached to your Raspberry Pi’s USB and what is the current rating for the bulk 5V AC/DC that you are using? If you are powering the Octopus, CANable then the total 5V current draw is going to approach 3A. If you’re also powering a display like the BTT PITFT5.0 that I’m using then total rPi current draw will be north of 5A and, depending on your bulk supply and wire AWG size, you’ll see some voltage dips and the “Power Save Enabled” warning.
If you do have the Octopus’ USB power jumper in, pull it and see if this fixes the problem.
If all you have is the CANable and the EBB36 then you should have the jumpers enabling the 120 Ohm terminating resistors installed in both boards.
Good luck!
Thank you for your extensive reply. To answer your questions:
- I am using 18 AWG wires to power RPi (during yesterday’s experiment I even had two pairs of 18 AWG wires).
- The RPi is connected via USB only to the Octopus board (but the jumper you showed is not installed, so the Octopus board must be getting it’s power from the larger 24V PSU (Mean Well LRS-200-24)), and the CANable adapter - I’m pretty sure RPi is powering that one, because CANable doesn’t have any power lines coming to it, only ground. So it must be getting it’s power via USB.
- My LCD is connected and powered from the Octopus board (so, also not related to the 5V PSU).
- The PSU I am using for RPi is Mean Well RS25-5 (rated at 5A). It is powering nothing else, just RPi.
- I had installed the 120 Ohm jumpers on both the CANable and the EBB36 when the last print failure happened. Sorry I forgot to mention it.
So, to sum up - 5V PSU is only powering RPi, and RPi is only powering CANable. RPi and PSU connected with 18 AWG wires, and the total load should be well below 5A. Octopus, EBB36, LCD and the rest are all powered from the 24V PSU.
So basically my current setup during the last print failure already matches what you suggested 
What do I do now?
Have you put a voltmeter on the output of the Mean Well 5V supply? It has an adjustment, maybe it’s a bit low from the factory.
The only other thing that I can think of is that there is a problem with your rPi’s 5V wiring - could you share a picture of the wires and how they go into the Raspberry Pi? If things got better when you added a second set of wires, that sounds like there may be an issue with the basic wiring.
Other than those two things, I can’t think of anything else. The “under-voltage” detected warning is pretty specific to the power supply going into the Raspberry Pi.
I measured the voltage out of 5V PSU - it is actually 5.1V. I also measured voltage at RPi - it is the same, meaning there is no drop due to wiring. If I knew when the issue is going to occur, I could measure at that time… But I don’t know how to cause it to happen on purpose, and chances are, if there is any voltage drop, it is very sudden and difficult to notice.
Here are the pictures you asked for: Imgur: The magic of the Internet 6
Sorry for bad cable management - I am trying to work out the issue so I’m rearranging things a lot. As you can see I still have two 5V wires going from the PSU to RPi (the two adjacent 5V pins). As for ground, I tried one to 5V PSU, one to 24V PSU (since the ground is shared, it shouldn’t matter, but I still wanted to try).
Thing is, if you remember, after adding the second pair of wires, I don’t get low voltage error anymore - just that “power save enabled”. Maybe it’s the same thing, I don’t know.
In any case, are you absolutely sure that this power supply issue is what’s causing CANable to lose connection? I really don’t know what else to do here as far as power supply goes.
You have a ground connection from each of the 5V and the 24V power supplies going to the Raspberry Pi? There’s a good chance that’s your problem - at the very least you have a big ground loop and, most likely, you have ground shift between the two power supplies that’s effectively lowering the 5V applied to the rPi.
Disconnect the Raspberry Pi ground lines from both the 5V and 24V supplies and run a new one, the same size as your 5V power line, from the 5V supply’s “-V” pin to the rPi’s Gnd.
It also looks like the CANable has a ground line connected to the 24V supply - you might want to disconnect that as well (I’m not impressed by the quality of the CANable circuitry).
Let’s see if this fixes your problem.
My apologies - I wasn’t aware that there is such a thing as ground loop. I thought it’s always best to connect all the grounds. I will try what you suggested, but then I have a question: should I connect the grounds of 5V and 24V PSU together or keep them separate? Also, what about the ground of the EBB36 and CANable - should I connect their grounds to RPi or instead to the 5V PSU “-V”?
No, keep the 24V and 5V grounds separate to the different devices. They’ll actually be connected through the USB connection between the rPi and the Octopus.
Honestly, I wonder if your problem is due to the thin ground wires on the rPi - the one going back to the 5V supply can’t carry all the current being provided so some of it is being shunted to the 24V supply with problems ensuing.
I’m not sure about the CANable with the third screw terminal that connects to “Ground”. I think you might have to leave that unconnected.
Let me know how things work.
Perhaps, I won’t pretend I understand how this all works 
But in any case, I have rigged up the wiring as you suggested: 5V PSU connected only to the RPi, CANable connected only to RPi (via USB) and to EBB via CAN_HIGH and CAN_LOW, EBB only to 24V PSU. No ground shared between 5V and 24V PSUs, except through the USB cable between RPi and Octopus. Printer boots up so far, I will attempt a previously failed print (without filament) overnight. If anything I listed here is wrong, let me know. Otherwise, I will report the results tomorrow.
Okay, apparently we won’t have to wait. My printer halted during QGL, with the same error “Lost communication with MCU ‘can0’”. Klippy log shows nothing of interest at the end. “Sudo dmesg” shows “power save enabled” again. So basically everything the same as before, so I’m skipping screenshots.
I am at a complete loss. Like I wrote, RPi 5V and GND are connected to +5V and -5V on the PSU. No ground loops this time. Nothing else connected to these lines. The only other connections are via USB to CANable and Octopus.
EDIT: It seems that whatever we did, made things worse. I now get printer shutdown every time I try to QGL. Can’t even make a single one succeed. Klipper log now ends with b'Got error -1 in can write: (11)Resource temporarily unavailable'. Firmware restart doesn’t work, I am forced to use on/off switch to restart the printer.
I know it’s of little consolation but a consistent error like this is generally easier to find than an intermittent one.
Can you:
- Share your klippy.log
- Draw out your wiring? I feel like we’re missing something here.
Thanx.
Yeah, you are right. It’s always better when the issue is reproducible. Attaching my klippy.log after the last shutdown during QGL.
klippy(9).log (1.2 MB)
I have drawn out the wiring. Very crudely so, sorry for that. But it is accurate:
P.S. If you check my Klippy.log, something really interesting is happening at around line 8152 and onwards.
Power schematic looks good -that’s what I would expect. Based on what I’m seeing in the klippy(9).log and it not having any Under-voltage detected errors, I would say that the cleaned up wiring has fixed that problem.
Now, when I go through your klippy.log your Quad Gantry Level execution looks messed up. You have a metric shit tonne of macros in your printer.cfg and I can’t begin to follow them but it looks like you’ve set some really aggressive movements when you start the QGL (at line 8001). I guess you’re running with Klicky (based on the Probe “Dock” operation) and doing four probes for each point (based on what I’m seeing). I’m really not an expert at decoding klippy.log but I think you’re problem is being flagged at line 8127 with a Lost communication with MCU 'can0'.
Did you write all these macros or did you pick them up somewhere? Have they ever worked (with the CAN Bus) before?
Yes, I would expect the undervoltage issue is gone too, but like I said, I still get the “power save enabled” message when running “sudo dmesg” after printer has halted.
I have the UnKlicky probe on the toolhead. Yes, there are a lot of macros, I picked them up from various places. For example, QGL macro came with default Klipper install I think. Klicky related macros came from Klicky guides. Nozzle cleaning macro came from the wire brush guide. There are some macros for controlling LEDs and for sounds. I wrote a few maintenance macros myself, like bringing toolhead to various positions, etc.
Basically when I start new print, this is the sequence:
- Set bed temperature to target, heat soak for 5 minutes (I print PLA, so it is enough most of the time)
- Home all
- QGL
- Home Z
- Bed mesh
- Heat nozzle to 180°C
- Clean nozzle on the brush
- Auto-calibrate Z offset
- Heat nozzle to target temp
- Clean nozzle on the brush
- Move tool head to the center of the bed
To answer your question, yes, this setup worked really well for me. It worked without any issues before I installed CANBUS, and after installing it, sequence still works without issues on the occasions when I don’t get lost connection with mcu can0. So I don’t think this sequence is what triggers the lost connection, especially because like I said, if printer does get through this sequence, I still get print terminations several hours into the print.
Attaching my whole config directory if you want to take a look. I admit I could tidy it up a bit, so sorry for the mess!
2023 04 23.zip (34.2 KB)
Thank you, I will attempt this. For clarity, am I supposed to run the dump utility right after the printer loses connection with can0? I tested this tool out with candump -t z -Ddex can0,#FFFFFFFF, and it just slowly prints memory contents to the terminal. Is it going to eventually write them to a file?
No, just start logging to the candump.log file. You will need this file to use parsecandump.py.
Here is an informative video https://www.youtube.com/watch?v=ef4akXEDKOQ 5 about candump. You may also find a lot here in the forum. Many people have some problems with CAN bus.
Okay, I got the dump, attaching it. How do I use that parsecandump.py? It requires more arguments than just the dump file, I can’t find any documentation on this tool.
candump-2023-04-23_153346.log (449.2 KB)
EDIT: It says it requires can ID and something called mcu.dict, but I have no idea where to get that.
You have a LOT of macros and if you “picked them up from various places” then I would be very surprised if you have any idea what’s going on with them and how they interact. When I tried reading your klippy.log, there are things that don’t make sense, like setting max_velocity to 500 (along with your acceleration/deceleration/square corner velocity/etc.) repeatedly before starting your QGL.
Could I suggest that you eliminate essentially all of them and start working through the operation of the printer to eliminate the chance there is a macro problem before assuming you have a CAN problem or any other problem?
I think I have a decent understanding of how they work, and I included them for a reason. But sure, I can do what you suggested. Can you tell me specifically what I should do? Because right now, I just boot up the printer, press Home All in the Mainsail interface, then run QGL - and bam, I get shutdown due to loss of connection with can. So basically I’m just running two commands, and none of these macros should be called. They are listed in the klippy.log, but they aren’t called I think. So let me know what I need to change for the testing and I’ll do it.
Based on your previous posts and what I see in the klippy.log and what you’ve shared you’re doing an awful lot more than just basically “just running two commands”. When I look at your klippy.log, there’s a lot of commands executing I don’t understand the purpose of and you’re not paying me enough to figure them out.
You want to know what I think you need to change for testing? In looking at the printer.cfg, I would say start by taking out/commenting out the following lines:
[include stealthburner_leds.cfg]
[include purge_macro.cfg]
[include tones.cfg]
[include movement_macros.cfg]
[include calibration_macros.cfg]
[include toolhead_btt_ebbcan_G0B1_v1.2.cfg]
Which is basically literally everything but the basic mainsail.cfg macros (virtual_sdcard, PAUSE, RESUME, etc.).
Next, in printer.cfg, remove/comment out everything after “# Macros” including [include klicky-probe.cfg] When I look at klicky-probe.cfg I see:
#Simple way to include all the various klicky macros and configurations
# the current home for this configuration is https://github.com/jlas1/Klicky-Probe, please check it
#[include ./klicky-specific.cfg] #place to put other configurations specific to your printer
[include ./klicky-variables.cfg] #Required
[include ./klicky-macros.cfg] #Required
[include ./klicky-bed-mesh-calibrate.cfg] #bed mesh, requires klipper configuration
#[include ./klicky-screws-tilt-calculate.cfg] #help adjust bed screws automatically
[include ./klicky-quad-gantry-level.cfg] #level 4 Z motors
#[include ./klicky-z-tilt-adjust.cfg] #level 2 or 3 Z motors
Which moves us into several more levels of macros. I should point out that several of these macros aren’t included in the .zip file you provided.
Then, when you’ve done that, put in the basic Klicky dock and undock functionality and start testing.
Sorry for being so brutal, but I want to throw up my hands when I see header comments like:
# This macro was provided by discord user Garrettwp to whom i give my thanks for sharing it with me.
# I have tweaked it a lot.
# They are based on the great Annex magprobe dockable probe macros "#Originally developed by Mental,
# modified for better use on K-series printers by RyanG and Trails", kudos to them.
# That macro as since evolved into a klipper plugin that currently is pending inclusion in klipper,
# more information here, https://github.com/Annex-Engineering/Quickdraw_Probe/tree/main/Klipper_Macros
# User richardjm revised the macro variables and added some functions
# User sporkus added led status notifications
It’s like the power set up; go back to being as basic as possible, draw out the process and start working from there.
I apologize for my lack of knowledge. I am very new at this, and I’m trying to learn as fast as I can. I appreciate your patience.
Okay, so I did what you told me - for now, I removed all includes except for mainsail.cfg and toolhead_btt_ebbcan_G0B1_v1.2.cfg. I commented out all macros from the printer.cfg. Didn’t even include Klicky macros yet. Left the bare minimum. After doing this, I cannot even make a full restart - Klipper gets stuck in Klipper reports: STARTUP blue screen for a while, and then throws mcu 'can0': Unable to connect again. Klippy.log keeps growing and is not resetting - meaning, at the beginning I still see logs from old tests, and the new log is just appended at the end of the file. Attaching for you to see.
klippy(14).log (2.2 MB) Not even turning printer power off and on back again fixes this. I am really confused.
I cleaned up printer.cfg as much as I could - removed all unnecessary comments, organized everything, moved in everything needed to boot up the printer except for mainsail.cfg (which is still included):
printer.cfg (9.0 KB)
And I still get the same issue, printer is not booting due to can0:
klippy(16).log (2.3 MB)
The log has one line that I didn’t notice before, or maybe it is new:
mcu 'can0': Unable to open CAN port: Failed to transmit: [Errno 105] No buffer space available
Researching this now, but just letting you know.
Okay, what I would recommend is going through the CAN set up procedure again following something like:
or this video which is highly rated/go to for Vorons:
Hopefully things will come together from doing that and you can start moving forwards again.
Okay, I went through the whole procedure again like you suggested, step by step, not missing anything. Still the same. Printer is not booting with the same error.
klippy(17).log (2.3 MB)
I guess there is no docu. I never used parsecandump.py. koconner stated “It works similarly to the existing klippy/parsedump.py tool”. I would look here in the documantation Debugging - Klipper documentation
Line 109 in parsecandump.py says: (sorry I can’t quote the original source, discourse shows not what I write). Just have a look at the original file https://github.com/Klipper3d/klipper/compare/work-parsecandump-20230417 1
usage = “%prog <candump.log> >canid> <mcu.dict>”
I would take can0 for >canid>, but for <mcu.dict> I have no clue. I guess it has something to do with debugging Klipper in batch mode.
What do you get when you do an ifconfig command in ssh?
You should be seeing something like this at the start of the response:
can0: flags=193<UP,RUNNING,NOARP> mtu 16
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 256 (UNSPEC)
RX packets 1031046 bytes 7522103 (7.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 85056 bytes 566641 (553.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Let’s first make sure can0 exists in your system.
Thanks, I figured it out, the python script referred to klipper.dict in the out directory. So I ran python parsecandump.py candump-2023-04-23_153346.log afac3c9694c2 ../out/klipper.dict and got this:
Sorry - the script doesn’t output it into a file, I don’t know how to do it, hence the screenshot.
It seems to exist. Here is what I get:
pi@V24RP:~/klipper/klippy $ ifconfig
can0: flags=193<UP,RUNNING,NOARP> mtu 16
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC)
RX packets 55460831 bytes 443686648 (423.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 24 (24.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether b8:27:eb:12:1e:4d txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 79067 bytes 29945480 (28.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 79067 bytes 29945480 (28.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.170 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fda3:85e6:18dd:0:11e4:10f0:29b4:5e2e prefixlen 64 scopeid 0x0<global>
inet6 fe80::9241:5f6b:371:8a94 prefixlen 64 scopeid 0x20<link>
inet6 fda3:85e6:18dd::2de prefixlen 128 scopeid 0x0<global>
ether b8:27:eb:47:4b:18 txqueuelen 1000 (Ethernet)
RX packets 57670 bytes 4416704 (4.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 70942 bytes 66710953 (63.6 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
cool, do us a favor and post all files you got zipped @https://pastebin.com/
yes, that was also my feeling, klipper.dict! I never heard about mcu.dict.
Can you clarify what files you meant? This python script produces none, it only outputs everything to the console, but the console can’t handle that many lines, so I only get the last part of the parse. What do you want me to upload?
Please do the hole procedure again. Do what you what to do until you get your failure.
And than post every file you generated after using parsecandump.py. Just post everything.
Please post the contents of /etc/network/interfaces.d/can0.
It’s also not clear to me if the firmware you flashed on the CANable is meant for the MKS clone. I built candlelight firmware from source specifically for the MKS clone if you want to try it. I’ve been using the non-pro version of the MKS CANable for quite some time on my 2.4 with no issues. I run Huvuds on my A and B motors, and an SB2040 on the toolhead all running through the CANable at 1M.
CANable_MKS_fw.bin.zip (12.7 KB)
Contents of /etc/network/interfaces.d/can0 are:
auto can0
iface can0 can static
bitrate 5000000
up ifconfig $IFACE txqueuelen 1000
Previously I also tried:
allow-hotplug can0
ifface cam0 can static
bitrate 10000000
up ip link set can0 txqueuelen 1024
There seems to be no difference - I get the error with either one of them.
I now will try to flash that firmware you provided, than you.
Both of these have problems and won’t work. You’ve specified a bitrate in the top one of 5M which is not valid. You need to change it to 500000, and I would also suggest using a txqueuelen of 128 as recommended in the Klipper docs. Try using this:
auto can0
iface can0 can static
bitrate 500000
up ifconfig $IFACE txqueuelen 128
You also need to reboot after editing this file.
I should mention, I’m assuming you’ve flashed your EBB36 with firmware for 500k baud. If you flashed it for a different speed, you need to match that speed in your interfaces file. You can’t mix and match.
Thank you very much. I guess this was what I messed up. I flashed with 1M baud. So now I set my /etc/network/interfaces.d/can0 to:
auto can0
iface can0 can static
bitrate 1000000
up ifconfig $IFACE txqueuelen 128
And the printer finally boots. I will now attempt to bring in a minimum amount of macros to perform homing and QGL to see if the issue persists.
Okay, so after this change, printer boots, but it still crashes during QGL with Lost communication with MCU 'can0'
For clarity:
My /etc/network/interfaces.d/can0 is:
auto can0
iface can0 can static
bitrate 1000000
up ifconfig $IFACE txqueuelen 128
My printer.cfg is:
printer.cfg (9.1 KB)
(I included the minimum amount of Klicky configs/macro files to make it possible to perform QGL)
sudo dmesg reports:
pi@V24RP:~ $ sudo dmesg
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.10.103-v7+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1529 SMP Tue Mar 8 12:21:37 GMT 2022
[ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
[ 0.000000] random: fast init done
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] Reserved memory: created CMA memory pool at 0x34000000, size 64 MiB
[ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x0000000037ffffff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x0000000037ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000037ffffff]
[ 0.000000] On node 0 totalpages: 229376
[ 0.000000] DMA zone: 2016 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 229376 pages, LIFO batch:63
[ 0.000000] percpu: Embedded 20 pages/cpu s50828 r8192 d22900 u81920
[ 0.000000] pcpu-alloc: s50828 r8192 d22900 u81920 alloc=20*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 227360
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=tty1 root=PARTUUID=b1d487b5-02 rootfstype=ext4 fsck.repair=yes rootwait
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 826024K/917504K available (10240K kernel code, 1312K rwdata, 2952K rodata, 1024K init, 862K bss, 25944K reserved, 65536K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] ftrace: allocating 32081 entries in 95 pages
[ 0.000000] ftrace: allocated 94 pages with 5 groups
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] Rude variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] random: get_random_bytes called from start_kernel+0x3ac/0x580 with crng_init=1
[ 0.000000] arch_timer: cp15 timer(s) running at 19.20MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[ 0.000007] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[ 0.000024] Switching to timer-based delay loop, resolution 52ns
[ 0.000310] Console: colour dummy device 80x30
[ 0.001131] printk: console [tty1] enabled
[ 0.001204] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)
[ 0.001263] pid_max: default: 32768 minimum: 301
[ 0.001489] LSM: Security Framework initializing
[ 0.001753] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.001802] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.003274] cgroup: Disabling memory control group subsystem
[ 0.003559] CPU: Testing write buffer coherency: ok
[ 0.004076] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.005334] Setting up static identity map for 0x100000 - 0x10003c
[ 0.005543] rcu: Hierarchical SRCU implementation.
[ 0.006481] smp: Bringing up secondary CPUs ...
[ 0.007653] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.008929] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.010244] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.010402] smp: Brought up 1 node, 4 CPUs
[ 0.010456] SMP: Total of 4 processors activated (153.60 BogoMIPS).
[ 0.010488] CPU: All CPU(s) started in HYP mode.
[ 0.010515] CPU: Virtualization extensions available.
[ 0.011520] devtmpfs: initialized
[ 0.029036] VFP support v0.3: implementor 41 architecture 3 part 40 variant 3 rev 4
[ 0.029332] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.029394] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[ 0.032438] pinctrl core: initialized pinctrl subsystem
[ 0.033640] NET: Registered protocol family 16
[ 0.037856] DMA: preallocated 1024 KiB pool for atomic coherent allocations
[ 0.043600] audit: initializing netlink subsys (disabled)
[ 0.044514] thermal_sys: Registered thermal governor 'step_wise'
[ 0.045310] audit: type=2000 audit(0.040:1): state=initialized audit_enabled=0 res=1
[ 0.045537] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[ 0.045579] hw-breakpoint: maximum watchpoint size is 8 bytes.
[ 0.045901] Serial: AMBA PL011 UART driver
[ 0.065276] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
[ 0.080151] raspberrypi-firmware soc:firmware: Attached to firmware from 2021-12-01T15:08:00, variant start_x
[ 0.090163] raspberrypi-firmware soc:firmware: Firmware hash is 71bd3109023a0c8575585ba87cbb374d2eeb038f
[ 0.134405] Kprobes globally optimized
[ 0.139425] bcm2835-dma 3f007000.dma: DMA legacy API manager, dmachans=0x1
[ 0.141802] SCSI subsystem initialized
[ 0.142088] usbcore: registered new interface driver usbfs
[ 0.142174] usbcore: registered new interface driver hub
[ 0.142267] usbcore: registered new device driver usb
[ 0.144203] clocksource: Switched to clocksource arch_sys_counter
[ 1.863374] VFS: Disk quotas dquot_6.6.0
[ 1.863527] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 1.863751] FS-Cache: Loaded
[ 1.864006] CacheFiles: Loaded
[ 1.873968] NET: Registered protocol family 2
[ 1.874317] IP idents hash table entries: 16384 (order: 5, 131072 bytes, linear)
[ 1.876414] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
[ 1.876509] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 1.876654] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 1.876867] TCP: Hash tables configured (established 8192 bind 8192)
[ 1.877072] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 1.877151] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 1.877456] NET: Registered protocol family 1
[ 1.878306] RPC: Registered named UNIX socket transport module.
[ 1.878341] RPC: Registered udp transport module.
[ 1.878370] RPC: Registered tcp transport module.
[ 1.878399] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 1.880069] hw perfevents: enabled with armv7_cortex_a7 PMU driver, 7 counters available
[ 1.883792] Initialise system trusted keyrings
[ 1.884080] workingset: timestamp_bits=14 max_order=18 bucket_order=4
[ 1.893697] zbud: loaded
[ 1.895846] FS-Cache: Netfs 'nfs' registered for caching
[ 1.896765] NFS: Registering the id_resolver key type
[ 1.896827] Key type id_resolver registered
[ 1.896857] Key type id_legacy registered
[ 1.897028] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 1.897065] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[ 1.898297] Key type asymmetric registered
[ 1.898331] Asymmetric key parser 'x509' registered
[ 1.898403] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[ 1.898443] io scheduler mq-deadline registered
[ 1.898473] io scheduler kyber registered
[ 1.902011] bcm2708_fb soc:fb: FB found 1 display(s)
[ 1.914701] Console: switching to colour frame buffer device 82x26
[ 1.922021] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 656x416
[ 1.931116] Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled
[ 1.936046] bcm2835-rng 3f104000.rng: hwrng registered
[ 1.939042] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
[ 1.945056] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[ 1.962602] brd: module loaded
[ 1.977575] loop: module loaded
[ 1.982145] Loading iSCSI transport class v2.0-870.
[ 1.986802] usbcore: registered new interface driver lan78xx
[ 1.989525] usbcore: registered new interface driver smsc95xx
[ 1.992124] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[ 2.723189] Core Release: 2.80a
[ 2.725758] Setting default values for core params
[ 2.728272] Finished setting default values for core params
[ 2.931149] Using Buffer DMA mode
[ 2.933673] Periodic Transfer Interrupt Enhancement - disabled
[ 2.936287] Multiprocessor Interrupt Enhancement - disabled
[ 2.938874] OTG VER PARAM: 0, OTG VER FLAG: 0
[ 2.941416] Dedicated Tx FIFOs mode
[ 2.944431] WARN::dwc_otg_hcd_init:1074: FIQ DMA bounce buffers: virt = b4114000 dma = 0xf4114000 len=9024
[ 2.951524] FIQ FSM acceleration enabled for :
Non-periodic Split Transactions
Periodic Split Transactions
High-Speed Isochronous Endpoints
Interrupt/Control Split Transaction hack enabled
[ 2.962491] dwc_otg: Microframe scheduler enabled
[ 2.962572] WARN::hcd_init_fiq:457: FIQ on core 1
[ 2.966892] WARN::hcd_init_fiq:458: FIQ ASM at 807cb8b8 length 36
[ 2.971322] WARN::hcd_init_fiq:497: MPHI regs_base at b8810000
[ 2.975773] dwc_otg 3f980000.usb: DWC OTG Controller
[ 2.978085] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[ 2.980453] dwc_otg 3f980000.usb: irq 89, io mem 0x00000000
[ 2.982774] Init: Port Power? op_state=1
[ 2.985020] Init: Power Port (0)
[ 2.987542] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.10
[ 2.992130] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.994611] usb usb1: Product: DWC OTG Controller
[ 2.996969] usb usb1: Manufacturer: Linux 5.10.103-v7+ dwc_otg_hcd
[ 2.999364] usb usb1: SerialNumber: 3f980000.usb
[ 3.002543] hub 1-0:1.0: USB hub found
[ 3.005026] hub 1-0:1.0: 1 port detected
[ 3.008849] dwc_otg: FIQ enabled
[ 3.008862] dwc_otg: NAK holdoff enabled
[ 3.008874] dwc_otg: FIQ split-transaction FSM enabled
[ 3.008892] Module dwc_common_port init
[ 3.009183] usbcore: registered new interface driver usb-storage
[ 3.011851] mousedev: PS/2 mouse device common for all mice
[ 3.015549] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[ 3.020736] sdhci: Secure Digital Host Controller Interface driver
[ 3.023275] sdhci: Copyright(c) Pierre Ossman
[ 3.026573] mmc-bcm2835 3f300000.mmcnr: could not get clk, deferring probe
[ 3.029819] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
[ 3.032639] sdhci-pltfm: SDHCI platform and OF driver helper
[ 3.037180] ledtrig-cpu: registered to indicate activity on CPUs
[ 3.040203] hid: raw HID events driver (C) Jiri Kosina
[ 3.042958] usbcore: registered new interface driver usbhid
[ 3.045600] usbhid: USB HID core driver
[ 3.053493] Initializing XFRM netlink socket
[ 3.056149] NET: Registered protocol family 17
[ 3.058767] Key type dns_resolver registered
[ 3.061732] Registering SWP/SWPB emulation handler
[ 3.064266] registered taskstats version 1
[ 3.066613] Loading compiled-in X.509 certificates
[ 3.069822] Key type ._fscrypt registered
[ 3.072147] Key type .fscrypt registered
[ 3.074505] Key type fscrypt-provisioning registered
[ 3.088018] uart-pl011 3f201000.serial: there is not valid maps for state default
[ 3.092879] uart-pl011 3f201000.serial: cts_event_workaround enabled
[ 3.095420] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 114, base_baud = 0) is a PL011 rev2
[ 3.102649] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[ 3.106958] mmc-bcm2835 3f300000.mmcnr: mmc_debug:0 mmc_debug2:0
[ 3.109484] mmc-bcm2835 3f300000.mmcnr: DMA channel allocated
[ 3.134353] Indeed it is in host mode hprt0 = 00021501
[ 3.198677] sdhost: log_buf @ (ptrval) (f4113000)
[ 3.239557] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 3.243678] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 3.247762] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 3.251130] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
[ 3.256441] of_cfs_init
[ 3.259010] of_cfs_init: OK
[ 3.262501] Waiting for root device PARTUUID=b1d487b5-02...
[ 3.275535] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 3.342603] mmc0: host does not support reading read-only switch, assuming write-enable
[ 3.347499] usb 1-1: new high-speed USB device number 2 using dwc_otg
[ 3.350239] Indeed it is in host mode hprt0 = 00001101
[ 3.414448] mmc0: new high speed SDHC card at address aaaa
[ 3.417931] mmcblk0: mmc0:aaaa SD32G 29.7 GiB
[ 3.423519] mmc1: new high speed SDIO card at address 0001
[ 3.428482] mmcblk0: p1 p2
[ 3.454310] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[ 3.456659] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
[ 3.584653] usb 1-1: New USB device found, idVendor=0424, idProduct=2514, bcdDevice= b.b3
[ 3.589370] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 3.592729] hub 1-1:1.0: USB hub found
[ 3.595432] hub 1-1:1.0: 4 ports detected
[ 3.648351] EXT4-fs (mmcblk0p2): recovery complete
[ 3.653103] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 3.658477] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 3.669267] devtmpfs: mounted
[ 3.679548] Freeing unused kernel memory: 1024K
[ 3.682763] Run /sbin/init as init process
[ 3.685421] with arguments:
[ 3.685432] /sbin/init
[ 3.685443] with environment:
[ 3.685454] HOME=/
[ 3.685465] TERM=linux
[ 3.914269] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[ 4.044637] usb 1-1.1: New USB device found, idVendor=0424, idProduct=2514, bcdDevice= b.b3
[ 4.049986] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 4.053725] hub 1-1.1:1.0: USB hub found
[ 4.056689] hub 1-1.1:1.0: 3 ports detected
[ 4.154271] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[ 4.261393] systemd[1]: System time before build time, advancing clock.
[ 4.301277] usb 1-1.2: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[ 4.306772] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4.309591] usb 1-1.2: Product: stm32f446xx
[ 4.312323] usb 1-1.2: Manufacturer: Klipper
[ 4.315084] usb 1-1.2: SerialNumber: 400043000451303431333234
[ 4.420807] NET: Registered protocol family 10
[ 4.425104] Segment Routing with IPv6
[ 4.505866] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[ 4.515448] systemd[1]: Detected architecture arm.
[ 4.593923] systemd[1]: Set hostname to <V24RP>.
[ 4.624330] usb 1-1.3: new full-speed USB device number 5 using dwc_otg
[ 4.758316] usb 1-1.3: New USB device found, idVendor=1d50, idProduct=606f, bcdDevice= 0.00
[ 4.764271] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4.767263] usb 1-1.3: Product: CANable-MKS gs_usb
[ 4.770436] usb 1-1.3: Manufacturer: makerbase
[ 4.773154] usb 1-1.3: SerialNumber: 001C00355741570D20393033
[ 5.054284] usb 1-1.1.1: new high-speed USB device number 6 using dwc_otg
[ 5.184863] usb 1-1.1.1: New USB device found, idVendor=0424, idProduct=7800, bcdDevice= 3.00
[ 5.190352] usb 1-1.1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 5.470818] lan78xx 1-1.1.1:1.0 (unnamed net_device) (uninitialized): No External EEPROM. Setting MAC Speed
[ 5.499824] lan78xx 1-1.1.1:1.0 (unnamed net_device) (uninitialized): int urb period 64
[ 5.552735] random: systemd: uninitialized urandom read (16 bytes read)
[ 5.569920] random: systemd: uninitialized urandom read (16 bytes read)
[ 5.574405] systemd[1]: Listening on Journal Socket.
[ 5.581156] random: systemd: uninitialized urandom read (16 bytes read)
[ 5.592343] systemd[1]: Starting Restore / save the current clock...
[ 5.600212] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[ 5.611215] systemd[1]: Listening on Syslog Socket.
[ 5.618867] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[ 5.630231] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[ 5.641080] systemd[1]: Listening on udev Kernel Socket.
[ 5.864043] mc: Linux media interface: v0.10
[ 5.907659] videodev: Linux video capture interface: v2.00
[ 5.959066] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[ 5.966234] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
[ 5.968743] [vc_sm_connected_init]: start
[ 5.972080] [vc_sm_connected_init]: installed successfully
[ 6.000203] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 6.047573] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[ 6.367928] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 6.521192] systemd-journald[120]: Received request to flush runtime journal from PID 1
[ 7.173891] bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.181790] bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video13
[ 7.182279] bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video14
[ 7.182679] bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video15
[ 7.183138] bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video16
[ 7.183167] bcm2835-isp bcm2835-isp: Register output node 0 with media controller
[ 7.183209] bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
[ 7.183231] bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
[ 7.183252] bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
[ 7.183470] bcm2835-isp bcm2835-isp: Loaded V4L2 bcm2835-isp
[ 7.203627] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.241543] bcm2835-codec bcm2835-codec: Device registered as /dev/video10
[ 7.241628] bcm2835-codec bcm2835-codec: Loaded V4L2 decode
[ 7.247905] bcm2835-codec bcm2835-codec: Device registered as /dev/video11
[ 7.247964] bcm2835-codec bcm2835-codec: Loaded V4L2 encode
[ 7.256263] bcm2835-codec bcm2835-codec: Device registered as /dev/video12
[ 7.256320] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
[ 7.259702] bcm2835-codec bcm2835-codec: Device registered as /dev/video18
[ 7.259757] bcm2835-codec bcm2835-codec: Loaded V4L2 image_fx
[ 7.261831] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.270875] bcm2835_audio bcm2835_audio: card created with 8 channels
[ 7.631116] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 7.636921] CAN device driver interface
[ 7.642777] gs_usb 1-1.3:1.0: Configuring for 1 interfaces
[ 7.644460] usbcore: registered new interface driver gs_usb
[ 7.743364] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[ 7.745029] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 7.745797] usbcore: registered new interface driver cdc_acm
[ 7.745816] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 7.784772] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
[ 7.849990] brcmfmac: F1 signature read @0x18000000=0x15264345
[ 7.877801] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 7.884787] usbcore: registered new interface driver brcmfmac
[ 8.173404] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 8.210731] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Nov 1 2021 00:37:25 version 7.45.241 (1a2f2fa CY) FWID 01-703fd60
[ 8.775615] random: crng init done
[ 8.775642] random: 7 urandom warning(s) missed due to ratelimiting
[ 9.468919] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
[ 10.148728] 8021q: 802.1Q VLAN Support v1.8
[ 10.314241] Adding 262140k swap on /var/swap. Priority:-2 extents:2 across:286716k SSFS
[ 10.332944] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 10.521145] 8021q: adding VLAN 0 to HW filter on device eth0
[ 15.875783] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 17.760770] ICMPv6: process `dhcpcd' is using deprecated sysctl (syscall) net.ipv6.neigh.wlan0.retrans_time - use net.ipv6.neigh.wlan0.retrans_time_ms instead
[ 30.031546] can: controller area network core
[ 30.031627] NET: Registered protocol family 29
[ 30.043749] can: raw protocol
[ 111.595151] usb 1-1.2: USB disconnect, device number 4
[ 113.165586] usb 1-1.2: new full-speed USB device number 7 using dwc_otg
[ 113.312610] usb 1-1.2: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[ 113.312623] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 113.312630] usb 1-1.2: Product: stm32f446xx
[ 113.312637] usb 1-1.2: Manufacturer: Klipper
[ 113.312643] usb 1-1.2: SerialNumber: 400043000451303431333234
[ 113.314773] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
ifconfig reports:
pi@V24RP:~ $ ifconfig
can0: flags=193<UP,RUNNING,NOARP> mtu 16
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 128 (UNSPEC)
RX packets 1282863 bytes 10257756 (9.7 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1749 bytes 10162 (9.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Klippy.log right after crash:
klippy(20).log (457.6 KB)
In my experience this is usually a wiring issue. With the printer powered off, make sure you have 60 ohms between H and L on the CAN bus wires. If your CAN wires aren’t twisted, I would suggest doing that as well.
Shouldn’t it be 120 Ohms? Everywhere I read it says 120. My EBB36 and CANable have jumper pins labeled “120 Ohm”, and I put the jumpers on both of them as I was instructed by several people. I measured the resistance between the lines, and it is 119.6 Ohms. Please clarify. I will attempt to twist the wires now.
Two 120 ohm resistors connected in parallel is 60 ohms. If you’re reading 120ohm, then one resistor is not connected.
Both jumpers are definitely in place, I double checked. Am I measuring it wrong maybe? I am placing my tester leads on the CAN_LOW and CAN_HIGH terminals on the CANable adapter.
Try disconnecting the wiring and measure the resistance on both boards. You should have 120 ohms on each board, and 60 ohms when the wiring is connected between them. And yes, you are measuring in the correct place. The resistance is measured between H and L.
It should be ~60Ohms. If it’s 120, then something isn’t in place.
Which version of CANable do you have? If it’s Version 1.0 or Pro, then you need to put in J4, If it’s 2.0, then the jumper needs to be on pins 1 & 2 of J2.
For your EBB36, if it’s Version 1.0, then you need to put a jumper on J3. If it’s Version 1.1, then you have to make sure the jumper is on JP1.
@jakep_82 has a good suggestion to disconnect your CAN bus cable and measure the pins on the CANable and the EBB36.
I wouldn’t recommend running the data rate at 1Mbps, I’m running multiple printers at 500kbps without issues. Remember that you have to rebuild the Klipper firmware for the EBB36 when you change the data rate.
Okay, clearly something was wrong there. The EBB36 was showing 0 Ohms when everything was disconnected. I replaced the jumper with a new one, and now it reports 120 Ohm as well. 60 Ohms between lines with everything connected. I guess my jumper was simply worn out.
I have also twisted the low/high cables, and after all these changes, I finally managed to get QGL from start to finish. I am going to attempt a long dry print overnight now, and if it fails, I will reflash EBB36 firmware with 500k baud and retry. Will keep you posted. And thank you for sticking out with me, guys. Really appreciate your patience.
For reference, I have CAN running at 1M on both of my Vorons. My Switchwire has an EBB42 on the toolhead (still running an old CW1 extruder), and before that it had a Huvud on it. I ran it at 500k for the first year with a Huvud 0.5, but when I upgraded to the 0.61 a year ago I found that 500k was insufficient to handle the bandwidth required for input shaper tuning with the new built in ADXL345. YMMV, but for me I’ve never completed shaper tuning at 500k and I’ve not had any real problems at 1M over the past year.
Good to know - I’ve never done shaper tuning.
Are you using the controller (I’m using CanBoot with the Octopus) or an USB to CAN adapter?
I’m using the MKS CANable (non-pro) on my V2.4, and a UCCB 2 on my Switchwire. I was using an Octopus in bridge mode on the 2.4 for a while, but decided to standardize on the Manta M4P board and CB1 so I could sell all my Pis while the prices are absurd.
Manta M4P on a Voron 2.4? Aren’t you short by two stepper drivers for X/Y movement (I presume the four with the M4P are for the Z axis).
Why wouldn’t you go with an M8P?
If you read my earlier posts in this thread, you’ll see that I have Huvuds on my A and B motors. I have only 4 wires in my Z chain, and they connect to a CAN distribution PCB which distributes CAN and power to the 3 different CAN boards inside my chamber (SB2040 on the toolhead).
Okay, guys, after the last changes (fixing the 120 ohm jumper and twisting the wires), I still had one more shutdown. I was also asking about this issue on Voron discord, and guys there suggested that it’s actually a mistake not to connect the grounds of the PSUs. Apparently USB connection might not ground some devices enough. So on top of the changes and fixes we did, I restored the ground connections between PSUs and also grounded the CANable through the terminal next to the com lines. And it appears we finally solved the issue. I just ran three dry 5h prints, and then one actual print - not a single failure so far.
I am still not entirely sure what was the cause, but it feels like it was a combination of things, and everything had to be set up just right for the CAN to finally work reliably. I guess CAN is just a very sensitive device at this stage of it’s development, and any little thing can cause it to crash.
I can’t begin to thank you guys enough for the time and effort you spent to help me with this. You saved my printer.
To whoever reads this post later, this is the final setup that worked for me:
Wiring:
-Jumpers on 120 Ohm pins both on EBB36 and on CANable (check if you actually get 60 Ohm between CAN_LOW and CAN_HIGH lines)
-Twisted CAN_LOW and CAN_HIGH wires all the way from CANable to EBB36;
-18 AWG or thicker wires from +5V and -5V PSU to RPi 5V and GND pins. Ensure you are not getting undervoltage messages by entering SSH into the Pi, and running sudo dmesg.
/etc/network/interfaces.d/can0:
auto can0
iface can0 can static
bitrate 1000000
up ifconfig $IFACE txqueuelen 128
CANable firmware, if you are using a MKS clone like I did - the one @jakep_82 provided: https://klipper.discourse.group/t/issues-with-canable/7970/40?u=laukejas
That’s about it. Again, thanks to everyone who helped me figure this whole thing out. You guys are amazing.
Sorry, but something isn’t right here. The additional ground wires should not be required as you establish a common ground between devices with the USB connections. I just checked on one of my printers with an Octopus, BTT USBtoCAN board and separate rPi and verified that this true.
Could you do me a favour and disconnect the additional ground cables (ie restore the circuit to the one you drew two days ago) and check the resistance between -24V on the 24V PSU, -5V on the 5V PSU, GND on the CANable? With the USB cables in place, the resistance should (actually, must) be zero. If you disconnect the USB connectors, the resistances should go up to very high values.
CAN is actually a very mature and very robust communications medium when wired correctly. It’s been a standard in the automotive industry for about 30 years.
I’ve never used CANable, I’ve only worked with the USB2CAN boards as well as the CAN controllers built into the Octopus and Manta m8P boards, so I can’t comment on its operation but I’ve never had any issues like the ones you have been describing with my set ups.
I’d be interested in seeing images of your cable and how you’ve wired it as I wonder if there is a problem them (although CAN is very robust in different situations).
I tested what you requested. With current wiring, all resistances between grounds show as 0 Ohms, as expected. When I restore the original wiring, I get this:
Between -24V on the 24V PSU and -5V on the 5V PSU: 0.2Ω
Between -24V on the 24V PSU and GND on the RPi: 0 Ω
Between -5V on the 5V PSU and GND on the RPi: 0 Ω
Between -24V on the 24V PSU and GND on the CANable: 0 Ω
Between -5V on the 5V PSU and GND on the CANable: 0 Ω
Between -24V on the 24V PSU and GND on the CANable: 0 Ω
So everything should be as expected. And yet, I just tried to run the printer again with this wiring - it crashed again during QGL. Tried 5 times, all crashed. Restored the additional grounds - working without issues (so far). It is really puzzling.
Just to clarify: Either you have GND or a negative voltage.
-24V and 24V makes 48V
Don’t mix up GND with this negative voltage stuff.
There are actually PSUs with -24V, GND and 24V clamps.
Thanx. Did you check with the two USB cables removed? In that case, you should have open circuits between the 24V PSU and the 5V PSU negative voltages as well as between the CANable and both of the supplies.
Now, just some follow up questions on the wiring (and follow up with the comment from @EddyMI3D):
- How are you wiring the line in power into the 24V PSU and the 5V PSU? Do you have LINE going into “L” on the two power supplies and NEUTRAL going into “N” on the two power supplies?
- What about the EARTH from the line in power? Where is it connected? I would expect that it goes to the printer’s frame as well as the GND Symbol (upside down TV Antenna) on the 24V PSU and 5V PSU.
- How are the 24V PSU and the 5V PSU mounted to the frame?
@EddyMI3D is right, there may be a few 3D printer power supplies that are marked with something like as being 24V with a “+24V” and a “-24V” along with a GND and being marked as being a “24V Power Supply”. You typically see that on PC power supplies that are labeled as being “12V”. But I don’t think that’s the case here as you have a Voron 2.4, I expect that you’re working with the standard Mean Well LRS-200-24 or LRS-350-24 that many people (me included) use along with the RS-25-5 (or IRM-605ST which I use) so I don’t think anything will have a “Gnd” pin that is different from the negative voltage.
I’m picking up on the post from @EddyMI3D as I wonder if you have something that is causing a ground shift and when you put in the explicit wires, you’re getting a consistent ground (which is a good thing) but there is current flowing through it (which ranges from quite bad to extremely bad).
Again, with the wiring diagram you put a few days ago, you shouldn’t need to put in these extra ground wires.
Could you please confirm how you wired your AC line in with regards to the two power supplies?
What wire gauge do you use for the 24V rails from PSU to the Octopus board and the EBB36?
And what gauge for the 5V rails?
Hey guys, apologies for late reply, I was down with the flu. @mykepredko, to answer your questions, with USB cables removed, I had no continuity between grounds.
About power line wiring: it is wired exactly as per the Voron 2.4 assembly manual. I double-checked it. To save time on drawing new diagram, I’m just attaching one from the manual. My wiring matches this.
And yes, I do have earth connected to the frame. I used a dremel to expose bare metal on one of the frame members, drilled and tapped an M3 hole, clamped the earth wire with a bolt, and checked for continuity. Both PSUs are mounted to the frame using 3D printed brackets that attach to the DIN rails. Also as per the manual.
@EddyMI3D , thank you for clarification on the markings. My PSUs have “V+” and “V-” marked on them. I must have mistaken that for “+24V” and “-24V” by looking at some examples on the internet or something. My apologies. In any case, multimeter shows 24V between them, so it’s a regular PSU. Same with the 5V one. To answer your last question, I was using 18 gauge from PSU to Octopus. For the EBB36 I am not sure - the wires from the kit I linked to previously, it doesn’t state what gauge it is. For the 5V rails, also 18 gauge.