"Timer too close", always at the same point in gcode

General Discussion
3

As I have written, I checked the post and it did not help.

Here you go, detailed answer to every point:

  • High system load of the host
    → not the case (see graph)

  • High disk activity of the host
    → not the case (see graph)

  • Swapping due to low free memory
    → not the case (see graph)

  • Disk errors / dying SD card
    → replaced it, no change

  • Unstable voltage
    → not the case (no Under-voltage detected! errors)

  • Other hardware hogging the USB bus or other system resources
    → not the case (no additional HW)

  • Running in a Virtual Machine
    → not the case (it’s not in a vm)

  • USB, UART or CANBUS wiring faults leading to extremely delayed messages
    → no communication issues so far

  • Electro-Magnetic Interference (EMI) affecting proper signal transmission or leading to high resend rates
    → no communication issues so far

  • Wrong Clock Reference used during building the board’s firmware (make menuconfig), confusing the timing between host and board
    → clock reference is correct, triple checked, even physically

  • Check for other resource-intensive processes running in parallel
    → see graph

  • Remove additional hardware, especially web cams and displays
    → nothing attached

  • Generally try to simplify your setup as much as possible
    –>… well nothing there to remove without breaking the print-function

  • Check SD card for errors / replace SD card
    → done

  • Check for Under-voltage detected! errors / make sure to use a good and adequate power supply
    → no errors found

  • Do not run data lines (USB, UART, CANBUS) close to and in parallel to high current lines like heaters or steppers. Use high quality cables (shielded / ferrite core). Keep such cables as short as possible
    → cables are seperated, STP and as short as possible.

  • Ensure sufficient cooling of the host’s SBC to avoid CPU throttling due to overheating
    → all CPU’s have coolers attached, no overheating in logs / graps

  • Also see Advanced Trouble-Shooting / Graphing Klipper
    → done

  • Verify that the correct Clock Reference during building the board’s firmware is used. Mind that certain boards have various revisions / flavors that might require different clock settings
    → done