Klipper reconnecting issue

[Pradit]

I'm using Octoprint, Klipper, Canboot, EBB36 and Octoprint with my work in progress Voron 2.4.

I have so many issue that make the klipper got disconnected or I fired firmware restart often.

Most of the time klipper just doesn't reconnect.

What happen? or are there any log file I can trace or look at the real problem?

[smirk]

That's a large search area

The main klipper related logs (are generally) kept in the ~/klipper_logs/ directory (most often that'll expand out to /home/pi/klipper_logs).

In that directory you'll find klippy.log (main klipper log) and logs for other things like moonraker.log and mainsail.log - exactly what is in the directory depends on the configuraiton (e.g. are you running mainsale or fluidd).

There will also be historic versions of the various log files, e.g. klippy.log.2022-12-06 or klippy.log.2.gz,  if it's got an extension like .gz then the file has been compressed and you'll need to use some like zcat (or even gunzip) to view it. The historic logs are useful for looking at past events.

There is also a utility called "logextract.py"  that will help extract "useful" information from the klipper log files - I say "useful" as the usefulness of any log file is a relative term

For example, if you copy your current klippy.log file to a new directory called pradit, and then run the logextract.py there you'll get two files to inspect:

pi@spiderpi:~ $ mkdir ~/pradit                          # Create the directory
pi@spiderpi:~ $ cd    ~/pradit                          # change into the new directory
pi@spiderpi:~/pradit $ cp ~/klipper_logs/klippy.log .   # Copy the klippy.log into the current directory
pi@spiderpi:~/pradit $ ~/klipper/scripts/logextract.py klippy.log  # Parse the copied log file
pi@spiderpi:~/pradit $ ls
klippy.log  klippy.log.config0001.cfg  klippy.log.shutdown00368

The output from the logextract.py will be those two files "klippy.log.config0001.cfg" (which is basically the klipper configuration) and "klippy.log.shutdown00368" (details about what klipper is up to).

 

Depending on how far down the rabbit hole you want to go there is also logs at the operating system (linux) level stored in /var/log and the dmesg command. dmesg will produce some interesting informaiton about what's going on in terms of devices on your PI (you might catch messages about under-voltage or other hard-ware related errors):

pi@spiderpi:~/pradit $ dmesg
[  611.737522] cdc_acm 1-1.1.2:1.0: ttyACM0: USB ACM device
[42755.791265] usb 1-1.1.2: USB disconnect, device number 10
[42756.101154] usb 1-1.1.2: new full-speed USB device number 11 using dwc_otg
[42756.248087] usb 1-1.1.2: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[42756.248100] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[42756.248107] usb 1-1.1.2: Product: stm32f446xx
[42756.248114] usb 1-1.1.2: Manufacturer: Klipper
[42756.248120] usb 1-1.1.2: SerialNumber: 310012001050563046363120
[42756.250171] cdc_acm 1-1.1.2:1.0: ttyACM0: USB ACM device

A lot of the logs are voluminoius so piping the output of commands through a pager like more or less (guess a pun on the more command) would be helpful.

 

[claudermilk]

3 minutes ago, smirk said:

There is also a utility called "logextract.py"  that will help extract "useful" information from the klipper log files - I say "useful" as the usefulness of any log file is a relative term

ORLY?  < Pops WinSCP open & pokes about > Huh, I didn't know that even existed. Good to know.

[scotchtape]

Check you wiring and try replacing cables. I know it's stupid but I had a bad cable going to my canbus board and it was a pretty new build. This was in the cable chain, I switched to umbilical after that. 

It would lose connection at certain angles, so sometimes it would work, very annoying to track down. I had to move my gantry while checking continuity and that's how I discovered the bad cable.