#Timer to close debugging

42 messages · Page 1 of 1 (latest)

lean solar
#

so I recently installed a camera using crows nest, and on the first print I did with it, I got a 'timer to close' MCU error just after starting the first layer. This has persisted even after uninstalling the camera and stoping crowsnest at a systemd level. (So, to be clear, htop shows no crowsnest running, and the camera is physically not plugged in). Attached are graphs of a good print that took several hours and had the cpu utilization stay under 50 the entire time, and the most recent print that errored out in the first layer, where the cpu usage spikes. (in that graph it shows 70%, but htop was showing 100 on a single core).

This is running on a raspi 3b+. Where do I troubleshoot from here?

loadgraph_before.png loadgraph_after.png
strange meadow
#

Three quick questions:

  1. Did you reboot the pi after removing crowsnest?
  2. Did you change anything else on your setup?
  3. What exactly is your setup?
lean solar
#
  1. yes
  2. I dont think so, but getting the camera working was an ordeal, so I may have missed reverting something
  3. ship of theseus ender 3 running on an skr mini and pi3b+ (direct drive, belted z, autoleveling, klipper)
strange meadow
#

For 2. you should have run sudo systemctl disable crowsnest, if you didn't uninstall crowsnest. That way it won't startup with the pi

lean solar
#

klipper and such is just installed by kiauh on a stock raspbian lite distro. (So, no GNOME or anything like that hogging resources)

lean solar
#

both stop and disable.

strange meadow
#

I recommend to send the klippy.log, for completion, and maybe someone else of the team can help you.

lean solar
#

klippy.log of the bad run. (im also posting this to the main klipper discord)

📎 klippy.log
jade temple
# lean solar so I recently installed a camera using crows nest, and on the first print I did ...

What kind of camera? I had really poor luck with an ELP cam similar to this. It just didn't "play well" with Klipper. Switching to a more standard Logitech cam, and the problems went away. https://www.amazon.com/ELP-IMX322-Sensor-Illumination-Embedded/dp/B06Y3YN19J/ref=sr_1_21?crid=1I9WBKXVHC8QU&keywords=elp+cam&qid=1700328456&sprefix=elp+cam%2Caps%2C110&sr=8-21&ufe=app_do%3Aamzn1.fos.17d9e15d-4e43-4581-b373-0e5c1a776d5d

ELP USB Camera Low Light 2MP 1080P Sony IMX323 Sensor USB Camera Mo...

ELP-USBFHD06H-L21 adopt Sony IMX322/IMX323 low illumincation image sensor, 1080P HD high resolution good for dark image vision It comes with sharp clear image in dark place. Specification: 2.0Megapixel 1080P Resolution Sensor SONY IMX322/IMX323 1920(H)x1080(V)pixels/Max. Resolution 1920X1080 Pict...

lean solar
jade temple
lean solar
strange meadow
#

printer_data/config is basically the only thing that you really need
Other things would be moonraker db for the history and mainsail settings

lean solar
dry summit
#

MainsailOS is a raspiOS with the common stuff pre installed. So it is really up to you, MainsailOS probably saves you 15-30 min as stuff like numpy is precompiled and already installed.

lean solar
dry summit
#

MainsailOS is based on the raspberian Light so yes no desktop, no X11 ...

foggy spoke
#

Well, just for my personal curiosity, where did you read/see/hear that MainsailOS is something different than Raspberry Pi OS lite? Basicly our buildchain does nothing other than running various install scripts of components of 'klipper stack'. Therefore nothing other than using KIAUH...

#

Except some prep work to use UART mcu comminication and enabled SPI for a adxl plus a timewasting 'Numpy' install...

lean solar
#

(some of the engineers at work are very windows centric and want RDP availible, dont like just using the terminal, I think)

lean solar
#

well that was a waste of an afternoon. @foggy spoke any other ideas?

loadgraph.png 📎 klippy.log
foggy spoke
#

I am sorry, I am not that much into klipper to debug this, I think alexz will react to it during the day. Timer to close errors are hard to come by, because it depends on so many factors, Which pi, how is it wired, quality of used SDCard, which usb ports, how many mcus and how they are wired and so forth...

#

In terms of OS, no, I am linux user on daily base, there will be nothing that isnt used, trying to keep things minimal as possible.

lean solar
#

Well, in the interest of giving alexz as much info as possible, Im running a pi 3b+ attached to an btt skr mini mainboard, have tried both USB and UART comms, I did swap out the SD card, and I did try without crows nest running and the camera unplugged. The pi is a secondary MCU, but it is only used for adxl input shaper callibrations. The camera is a picam v1 connected over a ribbon cable.

proven venture
#

you have microsteps = 64 it is mostly to high and can cause the timer to close test it with 32 and 16.

dry summit
#

Good morning, I will look into the logs in the evening. One question does you always try to print the same gcode? I ask as I see pronblems in the past where the slicer adds several M204 with no moves in between that can end in a timer to close.

#

@proven venture as I understand it the printer was running in that setup for several month, so yes microsteps can be an issue but giving it was a working setup with no changes there are more likly stuff to check first.

#

To make it clear if no cam is connected crowsnest will stop and therefor should not eat up any bandwidth

dry summit
#

Here is something that is very likly to cause issues [gcode_arcs] resolution = .01

#

We did arc tests 2 yesrs ago and .01 get even a PI4 to a high load.

#

To make it clear it might work for 100 prints and then there is the one modell that has the nozzle path in the wrong way and fails

lean solar
#

OMG, and I recently upgraded prusaslicer to the 7.0 beta, which enables the emitting of g2/g3... whats a sensible resolution for that?

dry summit
#

jepp that could be the explaination for all of it

lean solar
#

Ill do a test when I get back from work...

dry summit
#

I found that 0.1 was a good choice and if you think about it that is already a very small move

#

you can simple change your [gcode_arcs] resolution: 0.1 and try to print the same gcode again

#

from the klipper docs ```ini
[gcode_arcs]
#resolution: 1.0

An arc will be split into segments. Each segment's length will

equal the resolution in mm set above. Lower values will produce a

finer arc, but also more work for your machine. Arcs smaller than

the configured value will become straight lines. The default is

1mm.```

lean solar
#

Ah, I must have misunderstood. I thought it was the maximum deviation from the path. Yah, anything under a nozzle width shouldnt be noticable.

lean solar