I have seen that during the probing (seldom but I have seen it multiple times) the toolhead stops at the lower position (probe triggered) for a second, before moving up and continuing the probing. I have the inductive Omron probe, though I have seen it on the klicky probe setup as well ( I had klicky, removed it after testing as not seeing any benefit).
I am suspecting that the Raspberry Pi is some sort of busy and does not react to the trigger, on the other side if this would be the case the toolhead would have crashed into the bed.
Both of my printers exhibit similar behaviour, where at seemingly random times the motion stops briefly either when reaching an axis stop (X, Y, Z endstop), or when triggering the bed probe (inductive on my Voron and a BL Touch on my Creality). I first really noticed it on the Voron, mostly due to the insane number of homing and probing I experimented with, but once I became aware of it I also noticed it on my Creality as well.
I asked a few other people running Klipper and they confirmed similar behaviour on their printers. Coincidentally, these pauses do not have any impact on the end-stop or probing accuracy. A while ago I came across an old post from @koconnor explaining that homing and probing can be subject to some delays due to the implementation, but I am not sure if these can be on the order of a second. Perhaps Kevin can comment if he is not drowning in other stuff…
I also do not have the feeling that it has an influence on the probing accuracy or on the security against physical crashes.
I initially has a PI3 and switched to a PI4/4GB, thinking it might be the load that produces this behavior.
On the PI I also have docker running the Duplicati container. Although Debian is not a real-time OS, such a noticeable pause is not explainable. Looking at the videos running beacon bed mesh probing at 2000 mm/s there must be some room before hitting the processing limits.
What might be the case is that the end stop and probe triggering (triggered → stop the motors) is managed by the controller board part of Klipper and not the PI part.
I know, I had opened earlier another thread about it. this is also the reason why I temporarily switched from inductive to klicky and back to inductive when I’ve seen that the klicky had also the same issues with exceeding the tolerances. Meanwhile, I ordered the GE5C mod parts, as the problem seems not to be the probe, but the gantry (maybe?), including having too many QGL rounds.
Definitely, I will right now set your recommended 0.0125 value. Thanks
Every kind of probe comes with a certain accuracy and repeatability.
More on this here:
and here:
Also the hardware is underlaying some inaccuracies, mainly in the moving parts: a tiny bit sloppiness in the threaded rod and the nut and the stepper motors.
You can eliminate them but only with high end stuff for a high end price.
I made these tests in a cold environment.
I now started a print job and I see again the issue of “Probe samples exceed tolerance. Retrying…”
The QGL is done after the bed is heated up to 110°C.
I’ve also observed this with more recent versions of Klipper. It’s very occasional. Bed meshes, with having the most probe points, often has one pause in the “activated” down position or sometimes two. Very rarely I’ve seen this during Z_TILT_ADJUST too.
Trident 300 with TAP
I can’t provide a log until I have time to sort out a different problem that appeared most recently but once I have that solved I can run some bed meshes until I spot the issue happen and capture a copy of klippy.log.
My Voron2 also occasionally (likely once every 50 probe attempts) has a brief pause after a probe. I have not tracked down why. I have not seen anything adverse from the pause.
