[BUG] Move to probe position inside loop?

[Nick]

#In your rev_hop function, you have the return to probe position inside your loop which is calling it every time.
That doesn't seem right unless I'm missing something?

I forked this project and moved it outside and got better results

Your code:

def _tap_rev_hop(self, step_size: float, stop: float, probe_min, probe_speed: float):
        probe = self._probe(self.z_endstop.mcu_endstop, probe_min, probe_speed)[2] # Moves until TAP actuates
        steps = int((abs(probe) + stop) / step_size)
        for step in range(0, steps):
            # Why inside the loop? You only want to return to the probe position once
            self._move([None, None, probe], probe_speed) # Move back to probe position

Correction:

def _tap_rev_hop(self, step_size: float, stop: float, probe_min, probe_speed: float):
        probe = self._probe(self.z_endstop.mcu_endstop, probe_min, probe_speed)[2] # Moves until TAP actuates
        steps = int((abs(probe) + stop) / step_size)
        self._move([None, None, probe], probe_speed) # Move back to probe position
        for step in range(0, steps):
            z_pos = probe + (step * step_size) # checking z-position
            self._move([None, None, z_pos], probe_speed)
            self.printer.lookup_object('toolhead').wait_moves() # Wait for toolhead to move
            if not self._endstop_triggered():
                travel = abs(probe - z_pos)
                return(step, probe, z_pos, travel)
        return None

I'd make a pull request but I've already tweaked the code to add a new tap function to essentially "retap" and see how many steps it takes to retrigger moving at the step rate. It then reports the "retap" distance, the difference between the retap distance and the original distance found with the rev_hop and then takes the average of the two. They're usually extremely close (.005mm or so) but I was curious about the variance in triggering. I might add onto it and do short movements to trigger and untrigger to see how much variance there is out of curiosity but the tap looks about as accurate as predicted.

Also, Awesome project. If you deprecate it and I pick it up I'll 100% give you all the original credit and only annotate my changes.

[Anonoei]

Hello @TheFuzzyGiggler !
First off, I'd be happy to hand over the repo to you and answer any questions you may have (I probably could have commented things better)

Retap sounds interesting and could be useful for other people's setups.

I split it out into two different functions for taping:
"_tap_simple" does what you're saying, and probes, then lifts up the toolhead until it de-actuates
"_tap_rev_hop" probes, steps, and probes again.

Originally the default was _tap_simple, but I got better results with rev_hop. The idea behind it was some people's (possibly mine included) would stick, so when it lifted it would get a higher-than-normal value until tap slid down and de-actuated. By using rev_tap it ensured it would always start fresh for each height, hopefully making it so that didn't happen.

To bypass using rev_hop you can do AUTO_TAP TAP_VERSION=DEV DEV_FUNC=_tap_simple

Or you could make new versions to override it as well by doing something like:

class tap_CL_CNC_SIMPLE(TapVersion):
    Name = "CL_CNC_SIMPLE"
    Min = 0.03
    Max = 1.0
    Multiple = 2
    Adder = 0
    func = "_tap_simple"

[Nick]

Your project actually has me going down a rabbit hole now, I've expanded it to use an accelerometer on the toolhead to better determine when the probe actually touches the bed. There's a distinctive spike in the data at that point. The big thing I'm running into and scratching my head on is... I can get a repeatable z offset that's off by only .06mm (this is with totally ignoring any of the actual auto_tap values in the config and in the python file) and I'm trying to figure out where that .06mm difference is coming from.

I'm thinking it may be the lag in accelerometer movement due to the force to dislodge the tap from it's magnets. Trying to work out a way to to test that and see how I can make a way where users can run a small calibration command to determine the force of the magnets on their tap since everyone's will be slightly different.

I'm trying to get away from any "magic numbers" needed, aka extra factors or adjustments that are needed per tap variation. Ideally it'd be a one stop shop for "If you've got a tap, download this klipper extension, run this quick calibration, run the command and boom. There's your perfect z offset."