@dc42 an interesting datapoint.

If I set H2, instead of the stock H5, it seems to trigger K1 properly more often, I suspect because K0 is already triggered at that point, and is ignored.

In the nearterm this is a viable stopgap, with A set to 6 I'm resolving within 3 attempts.

@dc42 that is correct, yes. I'm sure I must be missing something obvious, but I can't see what.

@dc42 they are completely separate, and I can confirm when K0 triggers it does not register on K1 (in the web ui) and vice versa. This is true both when homing, and when manually triggering them.

Situation:

2 probes defined in config.g

; Z-Probe
M558 K0 P1 C"!zprobe.in" H4 A5 S0.03 F1200 T6000 ; set Z probe type to unmodulated and the dive height + speeds
G31 K0 P500 X-42 Y5 Z0.95 ; set Z probe trigger value, offset and trigger height
M557 X30:295 Y30:295 S50 ; define mesh grid
M558 K1 P8 C"^zstop" T18000 F1200 H4 A10 S0.005 R0.2
G31 K1 P500 X0 Y0 Z0.85

K0 is an inductive probe, which maps the bed.
K1 is a Z offset switch, which determines nozzle height.

my homez.g

G91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current position
G90 ; absolute positioning
G1 X343 Y274 F6000
G30 K1 Z-99999

K0 is only used when running the bed.g, which runs separately.

Due to the head configuration and the orientation of the Z offset switch, when the head moves and triggers the K1 switch, it also causes the K0 probe to trigger, sometimes before K1 does.

In some cases, when K0 triggers, the homing action is seen as attempted, and it does not attempt to trigger K1. This can cause a warning that the z probing is inconsistent.

The docs say G30 K1 should just be listening to K1, but it seems like K0 is also getting accepted.

Am I missing something obvious?