klipper
klipper copied to clipboard
Klipper3d
Richardjm/probe discard first
Supports the ability to discard the first n probes. Allowing a faster first probe before accurate subsequent measurements.
There are many users implementing this mechanism via manually replacing the probe.py file with a version that supports discarding the first probe.
I also use something like this and feel its needed. First value from a probe cycle seem to always have a large difference from the following.
Thanks. However, there was a long discussion on this at #3828 . My comments from that thread still apply - I don't think it makes sense to change the code without first diagnosing the root cause of inaccurate first probe results.
FWIW, my voron2 printer with klicky probe also shows this phenomenon. So, maybe I'll get a chance to diagnose root cause (but it could be months away before I get to it).
-Kevin
I would love to see this feature of discard_first. Why use a data point in the samples when you know that something in the motion system needs more time to settle and is causing the first sample to be thrown off a bit.
To me discarding the first sample fixes the issue with the motion system not being settled when the fist sample is taken.
I understand the difference between median and average for the samples_result option but to me using a data point that I know will always tend to be an outlier in the data set does not make sense.
I have isolated my signals for the probe (Euclid) by using shielded cabling and I have switched the micro-switch to using a Kailh GM 4.0 Micro Switch (https://www.amazon.com/dp/B08K9FSSLH). These Kailh GM 3.0 switches are used in mice for computers for years.
I did extensive testing with PROBE_ACCURACY which you can look at with this URL: https://github.com/GadgetAngel/Klipperbackup_Voron2.4r2_LDO300kit/tree/master/probe_accuracy_test_suite_Test_Results and https://github.com/GadgetAngel/Klipperbackup_Voron2.4r2_LDO300kit/tree/master/Probe_Accuracy_Test_Results
From my experience it is usually the first sample that is off in a set of samples.
I don't think it makes sense to change the code without first diagnosing the root cause of inaccurate first probe results.
My understanding is that it's a mechanical problem inherent to the belted Z drives. Swapping to a worm gear setup is known to cure the issue, but that brings its own problems
I don't think it makes sense to change the code without first diagnosing the root cause of inaccurate first probe results.
Depend on the setup, there will be faster first probe and slower on the others. Some probe have sampling rate (specially capacitive type have quite low sampling rate), so the homing speed will affect the first probe accuracy.
I have some unique data that may be interesting to the conversation. Everything I have seen points to the mechanics of a printer with this issue needing the z motion impulse from the first probe dive to "settle" the toolhead into a more stable resting position.
Here is a measurement of z resonance on one machine showing 20 um peak to peak from "only" 10mm/s dive speed. Faster speeds will have an even more violent stop.
Using ranging measurements on a corexy (troodon) with particularly sloppy mechanics, 10um (peak to peak) variation in z offset was found from only moving the toolhead out and back in the x and y -- that is, 10um variation in z offset cross coupled from presumably x-y backlash, belt tension asymmetry, poorly constrained rail cart or some related x/y issue. The z never moved so much as a microstep. An aggressive impulse from homing stop would help release asymmetric tension or just vibrate it into a more natural/stable position.
My two personal machines are leadscrew driven, bed-lift z axes and do not have this issue. A z impulse is not strongly coupled to the x-y, only through the frame, so if there were something in the mechanics that needed to settle, it would not receive a strong "bump" from the homing stop.
It may not specifically be something in the x-y settling, a belted z may instead have something that settles directly on the z axis.
My suggestion to get more definitive data would be to have code similar to this pull request just generate a z impulse without ever triggering the probe -- get it up to homing speed and just stop. This will isolate mechanical settling from anything that may be present in the probe or signaling. Samples subsequent to the impulse should not have the bad first sample if this theory is correct.
I would have already tested this out of curiosity but neither of my machines exhibit this issue.
Everything I have seen points to the mechanics of a printer with this issue needing the z motion impulse from the first probe dive to "settle" the toolhead into a more stable resting position.
Interesting. Though, if this was the case, I'd expect to see it only on the first probe in a QUAD_GANTRY_LEVEL (or BED_MESH_CALIBRATE or Z_TILT_ADJUST) sequence. However, I've seen the issue reported on each probe descent, even when previous probe descents occurred recently.
I agree that tests like you described would help track down root cause.
Cheers, -Kevin
Interesting. Though, if this was the case, I'd expect to see it only on the first probe in a QUAD_GANTRY_LEVEL (or BED_MESH_CALIBRATE or Z_TILT_ADJUST) sequence. However, I've seen the issue reported on each probe descent, even when previous probe descents occurred recently.
The mentioned data from the troodon suggests that any movement in the x-y could "unsettle" the toolhead and require the impulse again. Though again it may not always be due to x-y depending on the machine.
Fortunately this can also be tested relatively easily by probing, waiting awhile without moving in the x-y, and then probing again to check for bad first value. Maybe someone on this thread can test and report their findings, as it doesn't require any new code.
Interesting. Though, if this was the case, I'd expect to see it only on the first probe in a QUAD_GANTRY_LEVEL (or BED_MESH_CALIBRATE or Z_TILT_ADJUST) sequence. However, I've seen the issue reported on each probe descent, even when previous probe descents occurred recently.
The mentioned data from the troodon suggests that any movement in the x-y could "unsettle" the toolhead and require the impulse again. Though again it may not always be due to x-y depending on the machine.
Fortunately this can also be tested relatively easily by probing, waiting awhile without moving in the x-y, and then probing again to check for bad first value. Maybe someone on this thread can test and report their findings, as it doesn't require any new code.
If you want to do further testing, I have a version of this in an extension to Klipper called z_v2settling_probe that @voidtrance and I worked on. My GitHub repo is at https://github.com/GadgetAngel/voron2_settling_probe
@voidtrance has his version called settling_probe at https://github.com/voidtrance/voron-klipper-extensions
The difference between settling_probe and z_v2settling_probe is that z_v2settling_probe is a tool to help test out this issue.
z_v2settling_probe allows a command line parameter to be added to the following commands:
PROBE
PROBE_ACCURACY
PROBE_CALIBRATE
QUAD_GANTRY_LEVEL
BED_MESH_CALIBRATE
PROBE_Z_ACCURACY
CALIBRATE_Z
The command line parameter the user can add to the above command enables the user to discard the first settling sample on the fly instead of having to RESTART or FIRMWARE_RESTART their 3D printer (which changes the state of the machine).
The command line parameter is called SETTLING_PROBE so the commands would look as follows with z_v2settling_probe Klipper extension:
PROBE
PROBE SETTLING_SAMPLE=0
PROBE SETTLING_SAMPLE=1
PROBE_ACCURACY
PROBE_ACCURACY SETTLING_SAMPLE=0
PROBE_ACCURACY SETTLING_SAMPLE=1
PROBE_CALIBRATE
PROBE_CALIBRATE SETTLING_SAMPLE=0
PROBE_CALIBRATE SETTLING_SAMPLE=1
QUAD_GANTRY_LEVEL
QUAD_GANTRY_LEVEL SETTLING_SAMPLE=0
QUAD_GANTRY_LEVEL SETTLING_SAMPLE=1
BED_MESH_CALIBRATE
BED_MESH_CALIBRATE SETTLING_SAMPLE=0
BED_MESH_CALIBRATE SETTLING_SAMPLE=1
PROBE_Z_ACCURACY
PROBE_Z_ACCURACY SETTLING_SAMPLE=0
PROBE_Z_ACCURACY SETTLING_SAMPLE=1
CALIBRATE_Z
CALIBRATE_Z SETTLING_SAMPLE=0
CALIBRATE_Z SETTLING_SAMPLE=1
A SETTLING_SAMPLE=0 means you do not want to discard the first settling sample, while SETTLING_SAMPLE=1 means that you do want to discard the first settling sample.
My Ender3 Pro with a BLTouch definitely has an issue but my Ender3 is down at the moment. When I do have it back up I will be adding the Klipper extension z_v2settling_probe to that machine.
If someone else here wants to try out this extension and provide data I would like to see the test data.
The z_v2settling_probe Klipper extension does not require you to change any of the Klipper files. The Klipper z_v2settling_probe extension and the Klipper settling_probe extension just extends the probe object to so that you can choose to discard the first settling probe point from each sample group.
My hope is that tool can help settle this issue! No pun intended.
I saw in the past some sensors for other purposes (gas, temperature, ...) and discarding the first value or warning about potential unreliable results is not uncommon. I don't see much reason for negating this option here as well.
I would like to see this PR integrated into the mainline release as well.
Not wanting Klipper to normalize (in the societal sense) sloppy construction seems like a reasonable goal. Klipper shouldn't be ushering users toward the wrong fixes for problems. And providing support for for work-arounds is pretty much equivalent to tacitly endorsing the use of those work-arounds.
However, I don't think first-probe error on mechanical probes generally falls into the category of things that are easily or straightforwardly fixable. My experience is the same as the OP's in #3828: every probe on every machine I've ever personally owned has exhibited this same issue. I worked long and hard in every case to minimize the first-probe deviation, but it never went away completely.
I would analogize this problem to that of "vertical fine artifacts" from belt noise. You can replace all your belts and all your pulleys, retension your belts, tighten your screws, input-shape your printer within an inch of its life, and you'll still never completely get rid of those artifacts. The best you can hope for is to get them so subtle that they can be detected only under the harshest lighting. There's a limit to what a given printer can achieve.
By not supporting a straightforward "ignore the first probe" option, Klipper is more or less pushing users toward other suboptimal hacks. For example, using median sampling or setting the probe tolerance so that a second round of probing is usually assured.
I'd rather have an honest configuration that drops probes but reflects the tolerance I expect the probe to achieve in practice. Then if I see retries start to creep in, I know something's up and can investigate.
If I may suggest a couple of modifications to the current PR:
-
This setting should really apply to Z homing as well as PROBE. I looked at the code briefly, but homing seems to have a rather different implementation.
-
A minor nit: the current "Probe sample discarded" message creates misleading visual groupings:
probe at 30.000,270.000 is z=-0.659781
Probe sample discarded
probe at 30.000,270.000 is z=-0.655406
probe at 30.000,270.000 is z=-0.656031
probe at 30.000,270.000 is z=-0.656031
probe at 270.000,270.000 is z=-0.664781
Probe sample discarded
probe at 270.000,270.000 is z=-0.659156
probe at 270.000,270.000 is z=-0.659156
probe at 270.000,270.000 is z=-0.658531
probe at 270.000,30.000 is z=-0.670406
Probe sample discarded
probe at 270.000,30.000 is z=-0.664781
probe at 270.000,30.000 is z=-0.661656
probe at 270.000,30.000 is z=-0.659781
probe at 270.000,30.000 is z=-0.659781
The message follows the discarded samples, so the four probes in each "group" are actually from two different probing sets. Better, I think, to just mark the discards inline:
probe at 30.000,270.000 is z=-0.659781 (discarded)
probe at 30.000,270.000 is z=-0.655406
probe at 30.000,270.000 is z=-0.656031
probe at 30.000,270.000 is z=-0.656031
probe at 270.000,270.000 is z=-0.664781 (discarded)
probe at 270.000,270.000 is z=-0.659156
probe at 270.000,270.000 is z=-0.659156
probe at 270.000,270.000 is z=-0.658531
probe at 270.000,30.000 is z=-0.670406 (discarded)
probe at 270.000,30.000 is z=-0.664781
probe at 270.000,30.000 is z=-0.661656
probe at 270.000,30.000 is z=-0.659781
probe at 270.000,30.000 is z=-0.659781
There's a fork of @richardjm's code that fixes this here.
If I may suggest a couple of modifications to the current PR:
- This setting should really apply to Z homing as well as PROBE. I looked at the code briefly, but homing seems to have a rather different implementation.
- A minor nit: the current "Probe sample discarded" message creates misleading visual groupings:
probe at 30.000,270.000 is z=-0.659781 Probe sample discarded probe at 30.000,270.000 is z=-0.655406 probe at 30.000,270.000 is z=-0.656031 probe at 30.000,270.000 is z=-0.656031 probe at 270.000,270.000 is z=-0.664781 Probe sample discarded probe at 270.000,270.000 is z=-0.659156 probe at 270.000,270.000 is z=-0.659156 probe at 270.000,270.000 is z=-0.658531 probe at 270.000,30.000 is z=-0.670406 Probe sample discarded probe at 270.000,30.000 is z=-0.664781 probe at 270.000,30.000 is z=-0.661656 probe at 270.000,30.000 is z=-0.659781 probe at 270.000,30.000 is z=-0.659781The message follows the discarded samples, so the four probes in each "group" are actually from two different probing sets. Better, I think, to just mark the discards inline:
probe at 30.000,270.000 is z=-0.659781 (discarded) probe at 30.000,270.000 is z=-0.655406 probe at 30.000,270.000 is z=-0.656031 probe at 30.000,270.000 is z=-0.656031 probe at 270.000,270.000 is z=-0.664781 (discarded) probe at 270.000,270.000 is z=-0.659156 probe at 270.000,270.000 is z=-0.659156 probe at 270.000,270.000 is z=-0.658531 probe at 270.000,30.000 is z=-0.670406 (discarded) probe at 270.000,30.000 is z=-0.664781 probe at 270.000,30.000 is z=-0.661656 probe at 270.000,30.000 is z=-0.659781 probe at 270.000,30.000 is z=-0.659781There's a fork of @richardjm's code that fixes this here.
Want me to integrate your changes into my PR? Happy to cherry pick across if you want.
Interesting. Though, if this was the case, I'd expect to see it only on the first probe in a QUAD_GANTRY_LEVEL (or BED_MESH_CALIBRATE or Z_TILT_ADJUST) sequence. However, I've seen the issue reported on each probe descent, even when previous probe descents occurred recently.
The mentioned data from the troodon suggests that any movement in the x-y could "unsettle" the toolhead and require the impulse again. Though again it may not always be due to x-y depending on the machine. Fortunately this can also be tested relatively easily by probing, waiting awhile without moving in the x-y, and then probing again to check for bad first value. Maybe someone on this thread can test and report their findings, as it doesn't require any new code.
If you want to do further testing, I have a version of this in an extension to Klipper called
z_v2settling_probethat @voidtrance and I worked on. My GitHub repo is at https://github.com/GadgetAngel/voron2_settling_probe@voidtrance has his version called
settling_probeat https://github.com/voidtrance/voron-klipper-extensionsThe difference between
settling_probeandz_v2settling_probeis thatz_v2settling_probeis a tool to help test out this issue.
z_v2settling_probeallows a command line parameter to be added to the following commands:PROBE PROBE_ACCURACY PROBE_CALIBRATE QUAD_GANTRY_LEVEL BED_MESH_CALIBRATE PROBE_Z_ACCURACY CALIBRATE_ZThe command line parameter the user can add to the above command enables the user to discard the first settling sample on the fly instead of having to
RESTARTorFIRMWARE_RESTARTtheir 3D printer (which changes the state of the machine).The command line parameter is called
SETTLING_PROBEso the commands would look as follows withz_v2settling_probeKlipper extension:PROBE PROBE SETTLING_SAMPLE=0 PROBE SETTLING_SAMPLE=1 PROBE_ACCURACY PROBE_ACCURACY SETTLING_SAMPLE=0 PROBE_ACCURACY SETTLING_SAMPLE=1 PROBE_CALIBRATE PROBE_CALIBRATE SETTLING_SAMPLE=0 PROBE_CALIBRATE SETTLING_SAMPLE=1 QUAD_GANTRY_LEVEL QUAD_GANTRY_LEVEL SETTLING_SAMPLE=0 QUAD_GANTRY_LEVEL SETTLING_SAMPLE=1 BED_MESH_CALIBRATE BED_MESH_CALIBRATE SETTLING_SAMPLE=0 BED_MESH_CALIBRATE SETTLING_SAMPLE=1 PROBE_Z_ACCURACY PROBE_Z_ACCURACY SETTLING_SAMPLE=0 PROBE_Z_ACCURACY SETTLING_SAMPLE=1 CALIBRATE_Z CALIBRATE_Z SETTLING_SAMPLE=0 CALIBRATE_Z SETTLING_SAMPLE=1A
SETTLING_SAMPLE=0means you do not want to discard the first settling sample, whileSETTLING_SAMPLE=1means that you do want to discard the first settling sample.My Ender3 Pro with a BLTouch definitely has an issue but my Ender3 is down at the moment. When I do have it back up I will be adding the Klipper extension
z_v2settling_probeto that machine.If someone else here wants to try out this extension and provide data I would like to see the test data.
The
z_v2settling_probeKlipper extension does not require you to change any of the Klipper files. The Klipperz_v2settling_probeextension and the Klippersettling_probeextension just extends theprobe objectto so that you can choose to discard the first settling probe point from each sample group.My hope is that tool can help settle this issue! No pun intended.
Just had a look at this but it relies on z_calibration which since moving to TAP I have removed so I can't make use of it
Ran a few tests today. Something possibly odd is going on. The result of a GET_POSITION doesn't seem to be matching the probe position during a PROBE_ACCURACY.
Am I missing something fundamental?
The minor code change to get this output was
# Probe position
pos = self._probe(speed)
self.gcode_move.cmd_GET_POSITION(gcmd)
# Discard the first readings (probably at most one)
if samples_discard_first > discards:
gcmd.respond_info("Probe sample discarded")
discards += 1
else:
positions.append(pos)
# Retract
liftpos = [None, None, pos[2] + sample_retract_dist]
self._move(liftpos, sample_lift_speed)
self.gcode_move.cmd_GET_POSITION(gcmd)
More tests. As can clearly be seen the first probe after moving back to CENTER is off in comparison.
~~From the results here it certainly doesn't appear to be a mechanical issue so I'm agreeing with Kevin that discarding the first seems to be hiding something subtle in Klipper.~~
Test commands
GO_EOD # moves to max x,y
CENTER Z=2 # moves to center at height of Z 2
PROBE_ACCURACY PROBE_SPEED=5 SAMPLE_RETRACT_DIST=2 LIFT_SPEED=5
PROBE_ACCURACY PROBE_SPEED=5 SAMPLE_RETRACT_DIST=2 LIFT_SPEED=5
10:14 CENTER z=2
10:14 PROBE_ACCURACY PROBE_SPEED=5 SAMPLE_RETRACT_DIST=2 LIFT_SPEED=5
10:14 PROBE_ACCURACY at X:125.000 Y:125.000 Z:2.012 (samples=10 retract=2.000 speed=5.0 lift_speed=5.0)
10:14 probe at 125.000,125.000 is z=-0.711875
10:14 probe at 125.000,125.000 is z=-0.708750
10:14 probe at 125.000,125.000 is z=-0.708750
10:14 probe at 125.000,125.000 is z=-0.708125
10:14 probe at 125.000,125.000 is z=-0.708125
10:14 probe at 125.000,125.000 is z=-0.708125
10:14 probe at 125.000,125.000 is z=-0.708750
10:15 probe at 125.000,125.000 is z=-0.708750
10:15 probe at 125.000,125.000 is z=-0.708750
10:15 probe at 125.000,125.000 is z=-0.708750
10:15 probe accuracy results: maximum -0.708125, minimum -0.711875, range 0.003750, average -0.708875, median -0.708750, standard deviation 0.001038
10:15 PROBE_ACCURACY PROBE_SPEED=5 SAMPLE_RETRACT_DIST=2 LIFT_SPEED=5
10:15 PROBE_ACCURACY at X:125.000 Y:125.000 Z:1.291 (samples=10 retract=2.000 speed=5.0 lift_speed=5.0)
10:15 probe at 125.000,125.000 is z=-0.708750
10:15 probe at 125.000,125.000 is z=-0.709375
10:15 probe at 125.000,125.000 is z=-0.708750
10:15 probe at 125.000,125.000 is z=-0.708750
10:15 probe at 125.000,125.000 is z=-0.708750
10:15 probe at 125.000,125.000 is z=-0.708750
10:15 probe at 125.000,125.000 is z=-0.708750
10:15 probe at 125.000,125.000 is z=-0.709375
10:15 probe at 125.000,125.000 is z=-0.709375
10:15 probe at 125.000,125.000 is z=-0.709375
10:15 probe accuracy results: maximum -0.708750, minimum -0.709375, range 0.000625, average -0.709000, median -0.708750, standard deviation 0.000306
10:15 go_eod
10:15 center z=2
10:15 PROBE_ACCURACY PROBE_SPEED=5 SAMPLE_RETRACT_DIST=2 LIFT_SPEED=5
10:15 PROBE_ACCURACY at X:125.000 Y:125.000 Z:2.012 (samples=10 retract=2.000 speed=5.0 lift_speed=5.0)
10:15 probe at 125.000,125.000 is z=-0.713125
10:15 probe at 125.000,125.000 is z=-0.709375
10:15 probe at 125.000,125.000 is z=-0.709375
10:15 probe at 125.000,125.000 is z=-0.708750
10:15 probe at 125.000,125.000 is z=-0.708750
10:15 probe at 125.000,125.000 is z=-0.708750
10:15 probe at 125.000,125.000 is z=-0.709375
10:16 probe at 125.000,125.000 is z=-0.708750
10:16 probe at 125.000,125.000 is z=-0.708750
10:16 probe at 125.000,125.000 is z=-0.709375
10:16 probe accuracy results: maximum -0.708750, minimum -0.713125, range 0.004375, average -0.709437, median -0.709062, standard deviation 0.001264
10:16 PROBE_ACCURACY PROBE_SPEED=5 SAMPLE_RETRACT_DIST=2 LIFT_SPEED=5
10:16 PROBE_ACCURACY at X:125.000 Y:125.000 Z:1.291 (samples=10 retract=2.000 speed=5.0 lift_speed=5.0)
10:16 probe at 125.000,125.000 is z=-0.708750
10:16 probe at 125.000,125.000 is z=-0.708750
10:16 probe at 125.000,125.000 is z=-0.708750
10:16 probe at 125.000,125.000 is z=-0.709375
10:16 probe at 125.000,125.000 is z=-0.709375
10:16 probe at 125.000,125.000 is z=-0.709375
10:16 probe at 125.000,125.000 is z=-0.709375
10:16 probe at 125.000,125.000 is z=-0.709375
10:16 probe at 125.000,125.000 is z=-0.710000
10:16 probe at 125.000,125.000 is z=-0.709375
10:16 probe accuracy results: maximum -0.708750, minimum -0.710000, range 0.001250, average -0.709250, median -0.709375, standard deviation 0.000375
Over the last 2 years i have seen this phenomenon on 3-5 Printers each starting roughly a print a day
- Inductive Probes (Omron and knock offs)
- Klicky/KlickyNG
- Tap with Untap
- Tap with Optical Sensor 5V (- IR Sensor was not tested)
Altough this is a not so scientific answer as those are not recorded observations: those mashines went through all kind of states from old/unmaintained with bad mechanics/stiffness to freshly (re-)built: it occured always.
Everyone is fighting it by using some sort of "hacks" like higher sample number and using median. If someone finds the root cause that would be nice, but knowing this is not a severe problem with a simple solution would make a lot of people happy. I strongly vote for a "skip first probe" option.
Something that i was always wondering: has anyone checked currents/voltages inbetween those tests? because ultimately i might thank that some induced currents in the boards/wires could be a problem.
Want me to integrate your changes into my PR? Happy to cherry pick across if you want.
Sure, pick away! 🙂
From the results here it certainly doesn't appear to be a mechanical issue so I'm agreeing with Kevin that discarding the first seems to be hiding something subtle in Klipper.
Could you elaborate on this conclusion a bit? Your samples match my experience: it's not "the first sample" that's off so much as "the first sample after moving the toolhead in X and/or Y." But this seems to me entirely compatible with a mechanical issue of some kind. (Of course, it's also consistent with several other theories...)
More tests. As can clearly be seen the first probe after moving back to CENTER is off in comparison.
From the results here it certainly doesn't appear to be a mechanical issue so I'm agreeing with Kevin that discarding the first seems to be hiding something subtle in Klipper.
Moving your toolhead in the X-Y causes the next Z probe to be off. This is exactly what I was describing from the Troodon data I had, and is very likely a mechanical issue. For a CoreXY it could very well be asymmetric belt tension equalizing from the Z impulse of the first probe, or just a little slop in the motion system settling after being pulled left or right.
Is your machine a floating gantry type or does the bed move?
More tests. As can clearly be seen the first probe after moving back to CENTER is off in comparison. From the results here it certainly doesn't appear to be a mechanical issue so I'm agreeing with Kevin that discarding the first seems to be hiding something subtle in Klipper.
Moving your toolhead in the X-Y causes the next Z probe to be off. This is exactly what I was describing from the Troodon data I had, and is very likely a mechanical issue. For a CoreXY it could very well be asymmetric belt tension equalizing from the Z impulse of the first probe, or just a little slop in the motion system settling after being pulled left or right.
Is your machine a floating gantry type or does the bed move?
I have a Voron 2.4. So it's a floating gantry type printer. I'm wondering if there is any way to check, maybe by wobbling the print head a bit without moving.
This is kind of a strange issue. If it was a mechanical thing, like snapping into place after an impulse etc, then one would think that other firmwares are affected by the same.
A very superficial search did not reveal similar report with RRF or Marlin
This mornings investigation changed from 64 microsteps on Z to 16 - still the first value is off. Investigated wobbling the print head between probed and after moves and that made no apparent difference in behaviour (first probe of first probe_accuracy was off)
06:58 GO_EOD
06:58 center Z=2
06:58 PROBE_ACCURACY PROBE_SPEED=5 SAMPLE_RETRACT_DIST=2 LIFT_SPEED=5
06:58 PROBE_ACCURACY at X:125.000 Y:125.000 Z:2.012 (samples=10 retract=2.000 speed=5.0 lift_speed=5.0)
06:58 probe at 125.000,125.000 is z=-0.715000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe accuracy results: maximum -0.710000, minimum -0.715000, range 0.005000, average -0.710500, median -0.710000, standard deviation 0.001500
06:58 PROBE_ACCURACY PROBE_SPEED=5 SAMPLE_RETRACT_DIST=2 LIFT_SPEED=5
06:58 PROBE_ACCURACY at X:125.000 Y:125.000 Z:1.290 (samples=10 retract=2.000 speed=5.0 lift_speed=5.0)
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe at 125.000,125.000 is z=-0.710000
06:58 probe accuracy results: maximum -0.710000, minimum -0.710000, range 0.000000, average -0.710000, median -0.710000, standard deviation 0.000000
This is kind of a strange issue. If it was a mechanical thing, like snapping into place after an impulse etc, then one would think that other firmwares are affected by the same.
A very superficial search did not reveal similar report with RRF or Marlin
Marlin and RRF operate in real time, they have less reason to apply an instant stop with basically infinite jerk, they can use at least some deceleration on stop if they want. I can't be bothered to verify because I'm not remotely interested in RRF or Marlin.
Besides, I have high accuracy data from the Troodon showing Z offset drifts by 10um just from making moves in the X-Y. There are no impulses involved because its measured with a native displacement sensor. It can't be anything other than mechanical, and was shown to be a very poor tolerance linear rail.
You can argue whether other machines showing same symptom have the same root cause or not, but its +1 mechanical issue on that machine.
While I am fully in support of adding this to Klipper, especially if multiple users with different printers are experiencing issues related to this, I think that it should be done in the form of an extra probe rather than discarding samples.
In my extensions (referenced in a comment by @GadgetAngel), I chose to add an extra sample as to not lower the size of the sample set. From a quick look at the current PR, it seems that not only will the samples be discarded but the user can set a discard size large enough to where the probing won't have any samples to work with.
...I think that it should be done in the form of an extra probe rather than discarding samples.
I believe that's in fact what the current PR is doing. It first makes samples_discard_first probes that are thrown away and then takes however many samples are specified by samples. However, the docs could be clearer that you are getting M discards plus N samples rather than N samples of which M are discarded.
...I think that it should be done in the form of an extra probe rather than discarding samples.
I believe that's in fact what the current PR is doing. It first makes
samples_discard_firstprobes that are thrown away and then takes however many samples are specified bysamples. However, the docs could be clearer that you are getting M discards plus N samples rather than N samples of which M are discarded.
You are correct, sir! I misread the loop condition.
It looks like this GitHub Pull Request has become inactive. If there are any further updates, you can add a comment here or open a new ticket.
Best regards, ~ Your friendly GitIssueBot
PS: I'm just an automated script, not a human being.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
If I may suggest a couple of modifications to the current PR:
- This setting should really apply to Z homing as well as PROBE. I looked at the code briefly, but homing seems to have a rather different implementation.
- A minor nit: the current "Probe sample discarded" message creates misleading visual groupings:
probe at 30.000,270.000 is z=-0.659781 Probe sample discarded probe at 30.000,270.000 is z=-0.655406 probe at 30.000,270.000 is z=-0.656031 probe at 30.000,270.000 is z=-0.656031 probe at 270.000,270.000 is z=-0.664781 Probe sample discarded probe at 270.000,270.000 is z=-0.659156 probe at 270.000,270.000 is z=-0.659156 probe at 270.000,270.000 is z=-0.658531 probe at 270.000,30.000 is z=-0.670406 Probe sample discarded probe at 270.000,30.000 is z=-0.664781 probe at 270.000,30.000 is z=-0.661656 probe at 270.000,30.000 is z=-0.659781 probe at 270.000,30.000 is z=-0.659781The message follows the discarded samples, so the four probes in each "group" are actually from two different probing sets. Better, I think, to just mark the discards inline:
probe at 30.000,270.000 is z=-0.659781 (discarded) probe at 30.000,270.000 is z=-0.655406 probe at 30.000,270.000 is z=-0.656031 probe at 30.000,270.000 is z=-0.656031 probe at 270.000,270.000 is z=-0.664781 (discarded) probe at 270.000,270.000 is z=-0.659156 probe at 270.000,270.000 is z=-0.659156 probe at 270.000,270.000 is z=-0.658531 probe at 270.000,30.000 is z=-0.670406 (discarded) probe at 270.000,30.000 is z=-0.664781 probe at 270.000,30.000 is z=-0.661656 probe at 270.000,30.000 is z=-0.659781 probe at 270.000,30.000 is z=-0.659781There's a fork of @richardjm's code that fixes this here.
Want me to integrate your changes into my PR? Happy to cherry pick across if you want.
Just had a look and I can't cherry pick as the commit message isn't to Klipper standards
Just had a look and I can't cherry pick as the commit message isn't to Klipper standards
I updated the commit message and rebased onto your current clone. This is a new branch from the link above, now found here.