My impression is, there are still some unexplained phenomenons concerning CAN and Klipper.
koconnor just wrote a utility to parse Klipper messages in a candump capture Comparing master...work-parsecandump-20230417 · Klipper3d/klipper · GitHub
First you need a candump.log CANBUS Communication timeout while homing Z - #12 by koconnor
To get the candump utility you need to install can-utils Debian -- Details of package can-utils in sid
Good luck, hcet14
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 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
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.
Well, okay. Like I said, I now get error right after I turn on my printer. I can’t even get to do anything, it fails to boot with an error mcu 'can0': Unable to connect
So, the parsecandump.py output (as much as I could get): first part 0181:000.000000: WARN Ignoring line: (1682253236.788823) can0 109#5C81F45E0C6C7E - Pastebin.com, second part 5710:000.000000: WARN Ignoring line: (1682253308.148274) can0 109#9F9C3101BD7E - Pastebin.com
(Can’t post everything in one paste, pastebin says it’s too long).
As for my Klippy.log and printer.cfg - they haven’t changed since my last post where I uploaded them. I can’t put klippy.log on the pastebin also because it’s too long. And I can’t cut it into pieces because this forum doesn’t allow more than two links per post. So, sorry for that, just scroll up a bit if you want my latest printer.cfg and klippy.log.
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)