Inconsistent homing results

>First, levers are less accurate than buttons as there is a lot of variation in the throw.

True, but not this much. And that does not explain the repeatable dependence from speed.

>Is the Z latch backoff long enough to always back off the lever? How much travel does it take to always back off the lever?

I haven't examined the minimum required. The specified 6mm is certainly enough. In all the tests I can hear the switch clicking both ways. It is always clearing the switch, but it seems to have a hard time figuring out when to stop when backing away.

>Can you post your Z settings?

Those are at the top of my post. Scroll the window sideways to see all of them.

I played with it some more this morning. I found that:

- Jerk setting has a noticeable effect to where it stops - as expected. When using the fast end of the machine, speed also has an effect. So, when I got different stopping positions at speeds 1000 and 2000, nothing is wrong.

- At slow latch and search velocities, it does not obey the latch backup setting, but stops as soon as the switch is cleared. This I think is the real issue.

My 1/3 - 2/3 results at speeds 500 was likely the "right-at-the-limit" setting for yesterday's star positions. Today, I didn't get any random results, the machine stopped either at the switch or the specified backup position.

Workaround: Don't be ridiculously slow. :) So, while you do want to fix this, it is not urgent for me.

I understood that latch backoff means the amount of travel that is done to other direction homing switch trips, and it is my responsibility to set it big enough that it actually clears the switch. Also, I thought that zero backoff is an additional parameter that I can set (if I want to) to make workspace zero different from the hardware limits.

So, what the latch backoff is supposed to be used for?

I did some more poking. Empirically, it seems that if latch velocity is small, it is ignored. The machine moves slowly and stops as you say, as soon as the switch clears. If the velocity is large, it moves the full latch backoff amount.

> The deceleration should be actually starting when the switch transition occurs. Please let me know if you see evidence to the contrary – that would be a bug.

Unfortunately, I do see the contrary. These are the settings:

$z
[zam] z axis mode                 1 [standard]
[zvm] z velocity maximum       1000.000 mm/min
[zfr] z feedrate maximum       1000.000 mm/min
[ztm] z travel maximum           80.000 mm
[zjm] z jerk maximum           2000 mm/min^3 * 1 million
[zjh] z jerk homing            5000 mm/min^3 * 1 million
[zjd] z junction deviation        0.0100 mm (larger is faster)
[zsn] z switch min                3 [0=off,1=homing,2=limit,3=limit+homing]
[zsx] z switch max                2 [0=off,1=homing,2=limit,3=limit+homing]
[zsv] z search velocity        1000.000 mm/min
[zlv] z latch velocity         1000.000 mm/min
[zlb] z latch backoff            25.000 mm
[zzb] z zero backoff              0.000 mm
tinyg [mm] ok>
tinyg [mm] ok>
$3
[3ma] m3 map to axis              2 [0=X,1=Y,2=Z...]
[3sa] m3 step angle               1.800 deg
[3tr] m3 travel per revolution    8.000 mm
[3mi] m3 microsteps               2 [1,2,4,8]
[3po] m3 polarity                 1 [0=normal,1=reverse]
[3pm] m3 power management         0 [0=remain powered,1=power down when idle]
tinyg [mm] ok>

Note the long zlb value. On homing, the z travels all 25mm, even though it certainly has enough time to stop. On slower zlv settings, it does stop right after the switch clears. I tried on other axis which have different settings, but their behaviour on my machine is as you say.

Btw, I was NOT correct about the latch backoff functionality. I thought the machine would start from the "bottom" of the switch and always back off the specified amount (like my z behaves now). I think I get it now, and I need to change my settings - or maybe not, I actually like the current behaviour. Fast settings produce good clearing for the switches (although not as you intended) and the homing is swift.

And if I may phrase it a bit differently, this is how I now understand homing operation (please correct me if this is (still) not right): When the homing cycle has stopped at the "bottom" of the travel, it starts backing away at the specified speed*. When the switch clears, the machine has picked up some speed, but it stops when it can*. The resulting end position has nothing to do with latch backoff value, but is a function of the speed and jerk settings.

(*: Latch velocity and jerk homing values are used)

Since I have an active thread about homing results, my results might be of interest: We found a bug, but when TinyG is used as intended, the results are not bad. I got new battery to my caliber, and run some experiments:

Common factors: 8 microsteps, lever based good quality switches; lv= latch velocity, about twenty tries on each setting:

Z axis, linear screw stepper, 8mm/rev, 1.8deg. step:
lv 50: homing repeatibility < 0.01mm (under my caliber resolution)
lv 100 - 500 (still within no bug area, but on the fast side): +0.05 .. -0.05 mm
lv 1000: +.10 .. -0.10 mm

X&Y axis: belt driven system, 40mm/rev, 0.9 deg. step. Here, I did not encounter the bug; slow setting is the intended use, fast setting the "stop whenever you can" case:
lv 1500 (definitely in the fast area): +0.15 .. -0.15mm
lv 500 (borderline area): +0.05 .. -0.05mm
lv 100 (slow): under caliber resolution

The absolute home postion is different in each case. Imo, this is of no importance. A CNC machine is a combination of mechanical design and control electronics settings. If you change something, it is expected that physical things change as well (like where the gantry really is after homing).

Conclusions: It pays off to use the system as the designer intended. :) Lever switches can be very repeatable, at least when relatively new.

So, to the contrary to the thread title, homing results are actually very consistent.