I am puzzled by the behaviour of a Z-probe (mircoswitch hung from spider, connected as Z Min endstop) which I have recently fitted to my Kossel XL (which I am really pleased with). I am using Marlin 1.1.8
Before fitting the Z-probe I would drive the head to a given [X, Y, zmid] and push a wedge (with height zmid half way along) under the nozzle to determine the offset of the nozzle from the bed, and use [
www.escher3d.com] to refine 4 calibration values (radius and 3 endstops). I update using M665, M666, and check the offsets again, generally getting std dev of under 0.1mm, and a range of 0.2mm, which gives me good prints.
If I use G30 [X, Y] to get Z-probe readings from the same points, they can be 0.5mm to 1 mm different from my wedge. If I track points along a diameter through the towers, there seems to be a linear variation (which is not shown by wedge).
Now here comes the really puzzling bit. If I use a sequence of G1 Z30, G1 Zzval, M119, commands, and a binary chop algorithm to determine the max zval offset at which the Z-probe is TRIGGERED, this matches the wedge values (after removing the mean nozzle-z-probe height difference) to within 0.1mm.
So, using a manual sequence of motor moves to drive locate the Z-probe trigger height gives me readings which correspond with the independent physical wedge, but when I let the G30 code drive the Z-probe until the endstop is hit, it gives values with large differences.
The bottom line is that the laborious wedge calibration gives me decent prints, but the G33 auto-calibration (which follows the G30 method) gvies a 'tilt' of up to 1mm across the bed, with respect to the Z=0 plane, and is useless for printing.
I have looked at the Marlin bugfix 1.1.8 repository, and cannot see any changes in the related bits of code (I think the function forward_kinematics_DELTA() is central to the issue).
Thanks for any help or suggestions.
John
