Legacy Timeout During Homing/Probing Options

These are older potential things to try to help with a “Timeout during homing/probing” error. The current “Niceness” method is a much cleaner way of doing it, but I’ll keep the older options here in case they need to be referenced.

CPU Affinity

Something I’ve had success with lately is assigning CPU cores to processes. The following steps will force everything except klipper to run on the first 3 cores (cores 0, 1, 2) of a quad-core CPU (any Pi newer than a Pi2) and then force Klipper to run by itself on the fourth core. This may help with timing issues or scheduling conflicts or whatever could be interrupting Klipper from hitting the proper timing windows.

Create the system.conf.d folder with:

sudo mkdir -p /etc/systemd/system.conf.d/

then edit (or create) the cpuaffinity.conf file by running:

sudo nano /etc/systemd/system.conf.d/cpuaffinity.conf

and putting in:

[Manager]
CPUAffinity=0-2

then press ctrl+X to save and quit. This will force everything to run on the first three cpu cores only.

To make Klipper run on the now-unused fourth core, create the klipper.service.d folder with:

sudo mkdir -p /etc/systemd/system/klipper.service.d

then edit (or create) the override.conf file by running:

sudo nano /etc/systemd/system/klipper.service.d/override.conf

and putting in:

[Service]
CPUAffinity=3

then press ctrl+X to save and quit, and run sudo reboot now to reboot the Pi.

Once it starts again it should have the Klipper service running by itself on the fourth core of the CPU and hopefully let it not get interrupted by other non-Klipper processes.

Config Tweaks

If the CPU Affinity doesn’t work (or your computer board doesn’t have multiple cores),then we can try minimising CAN traffic by lowering stepper motor microsteps and the homing speed.

  • Set all microstep settings in your printer.cfg to 16. This value is found in the [stepper_ ] sections for X/Y/Z (probably multiple Z motors, you need to change each one) and also your [extruder] section.

    image

  • Set the homing speeds to fairly low. 20mm/s for X/Y, 10mm/s for Z. Yes this may be painful but it’s just testing at the moment. Once you’ve “fixed” the problem feel free to adjust these back up.
  • Make sure your CAN speed is set to 1M and txqueuelen is set to 128 (see the Getting_Started page on how to set this)
  • Unplug any extra USB devices from your pi. Maybe LEDs, maybe cameras. Anything USB can be drawing power and using processing time so lets remove it all for testing

  • If using crowsnest for your camera, stop the crowsnest service completely. Easy to do in mainsail, just press the button:

    image

    or you can run sudo service crowsnest stop on the Pi and this will also stop the crowsnest service

    image

Now do some more homing and probing. If it’s rock solid now, great! Go through the steps in reverse order (re-enable crowsnest, plug in USB one at a time, change microsteps, etc) until you start seeing it time out again. This way you should be able to either track down the single culprit or at least find the limits of what your Pi can handle.

TRSYNC_TIMEOUT

If the above still doesn’t fix it (and by “fix it” I mean “never happens” not just making it happen less) then the next thing I would do is to actually change the klipper homing timeing threshold. This is a bit “hacky”, but I’ve found it necessary on certain boards (I had to do it on my pi3b, nothing else would solve the problem).

By default, Klipper uses a 25ms window for homing actions. This is set by the TRSYNC_TIMEOUT entry in the klipper mcu.py file. To check if yours is still the default run:

cat klipper/klippy/mcu.py | grep "TRSYNC_TIMEOUT ="

if it shows TRSYNC_TIMEOUT=0.025 then it is still the default setting.

image

To change this to 50ms run the command:

sed -i 's\TRSYNC_TIMEOUT = 0.025\TRSYNC_TIMEOUT = 0.05\g' ~/klipper/klippy/mcu.py

Then confirm it by running cat klipper/klippy/mcu.py | grep "TRSYNC_TIMEOUT =" again. If the change has been set reboot the Pi with sudo reboot.

I’ve found a 50ms timeout window got rid of all my “timeout during homing probe” errors with seemingly no loss in probing or homing accuracy.

Note as I said this is still a bit of a hacky workaround. Doing this will mark your klipper install as “dirty” in your mainsail update manager (all it means is there is a file that is different to what is in github, which is true because we just changed it) and whenever you update klipper it will overwrite this to default. So if you update klipper and find the timeouts returning just run sed -i 's\TRSYNC_TIMEOUT = 0.025\TRSYNC_TIMEOUT = 0.05\g' ~/klipper/klippy/mcu.py and reboot.

Return to Troubleshooting