I have a BTT Eddy probe on a SV08 with mainline klipper and are having some issues with z-offset consistency. First layer height of prints were showing high variance in quality even after multiple offset calibrations.
So, I tried to look into it further and found the variance in measured z-height on a G28 Z command is significantly different (range=0.127mm) than something like the PROBE_ACCURACY run (range=0.018mm). Even with trying to match the speeds/movement distance, the difference is large (example below).
Any reason for the G28 command having a larger error when the sensor itself seems capable of more?
Iâm having the same issue. Eddy accuracy is better than 0.002mm, but the z-offset from SET_Z_FROM_PROBE varies about 0.15mm with every homing.
As a first measure, I deleted the whole G28 override from the eddy config file, so it doesnât set a z-offset at all. Now, I get perfectly repeatable results, with the nozzle being exactly 0.1mm to high at the start of every print. My problem is, that I canât find a good solution, to set the necessary z-offset.
Saving it, after baby stepping, does absolutely nothing. It doesnât even matter what z-offset I use in the [probe_eddy_current btt_eddy] Section, eddy always ends up 0.1mm too high.
My current workaround is, to hardcode the offset into my print_start macro with SET_GCODE_OFFSET Z=-0.1.
I am searching for a better solution.
Does somebody understand how the whole eddy Z-offset thing is supposed to work? BTT says, eddy knows where Z=0 is, so you donât need an offset. But how are you supposed to dial in first layer squish, without changing an offset? The Paper Method alone is by far too inaccurate for good printing results.
Strange coincidence, literally yesterday, I wrote how Z is homed with LDC1612 (BTT Eddy).
Any reason for the G28 command having a larger error when the sensor itself seems capable of more?
They are working in a slightly different way, homing happens when klipper has no idea where Z actually is. Probing happens when Klipper has some idea, so it is optimized.
I can suggest 2 things:
I donât know how your probe is connected, but if you set i2c bus in the config, instead of pins, it should be slightly better, because of the higher communication speed with HW bus.
Second homing move should be slower, to compensate for possible overshoot. Technically, the slower, the better it will be to some degree.
My understanding can be wrong, so you now have a way to test it.
Disclaimer: I do not have BTT eddy, and this is my understanding from the code.
Hope it helps. You can calculate the required step frequency (homing speed) to get step-level accuracy.
Roughly, to query the sensor, we need to read status (5 bytes) + MSB register (5 bytes) + LSB register (5 bytes).
Roughly 9 bits per byte, 15 * 9 = 135 1 / 100_000 * 135 = 0.00135 ~ 1.35ms
With 400kHz (with HW i2c BUS) 4 times faster.
Afaik, voron 2.4 rotational distance is 40, gearing 80/16.
So, at 10 mm/s. there is:
200 * 80 / 16 = 1000 steps per rotation
10 / 40 * 1000 = 250.0 full steps per second ~ 4 ms per full step
40 / 1000 = 0.04 mm per full step
With added microstepping:
2 ~ 0.002 ms per microstep
4 ~ 0.001 ms per microstep
8 ~ 0.0005 ms per microstep
16 ~ 0.000025 ms per microstep
So, roughly you should have constant overshoot between 1/2 and 1/4 of full step. 10 mm/s * 0.001 s = 0.01 mm 10 mm/s * 0.002 s = 0.02 mm
So, with such nice numbers, at 100kHz, you should experience an overshoot around 0.0135 mm.
So, to have enough time, to query the sensor between steps, depends on your microstepping, assume you are using 16, at 100kHz i2c speed.
Saving it, after baby stepping, does absolutely nothing. It doesnât even matter what z-offset I use in the [probe_eddy_current btt_eddy] Section, eddy always ends up 0.1mm too high.
According to the code, z_offset in probe_eddy_current is the trigger height, thatâs it. Klipper uses calibration data, to calculate the expected output of the sensor at this height, and waits till the sensor shows a value below the expected one.
Simply speaking, the sensor returns âheightâ and Klipper waits till the returned height is lower than expected.
But, do we actually need to use eddy, to set a z-offset after homing at all? I donât understand what the benefit is, if it adds inaccuracy. And what is it even supposed to do? I mean, eddy canât fine tune first layer squish for us. We always have to manually dial in the z-offset to our liking anyway. So, what reason would there be, to have eddy interfere with our z-offset in the first place?
In this point I donât understand the eddy documentation provided by BTT. It seems, they think the Paper method is good enough to set the probes offset, and donât provide any way to fine tune at all? Or am I missing something?
The problem I am left with, after deleting eddys G28 overwrite, is basically only, that the way eddy works with z-offset, I canât permanently apply my baby stepping.
I mean, for a workarround I could just leave the real z-offset value alone, and use a custom variable to handle it. But itâs odd to me, that eddy wouldnât provide a way to fine tune. I guess Iâm missing something.
But, do we actually need to use eddy, to set a z-offset after homing at all? I donât understand what the benefit is, if it adds inaccuracy. And what is it even supposed to do? I mean, eddy canât fine tune first layer squish for us
Unfortunately, I canât suggest something or provide solution, as far, as my understanding goes (it can be wrong):
Inductive sensors such as eddy - provide actual high between the nozzle and bed.
So, bed mesh is that. Homing should not matter much, because while creating bed mesh, klipper will know the actual height.
z offset used for nozzle and baby stepping is an absolute correction, should still work while printing because it happens over the created bed mesh.
How does it interact after saving + reload - I honestly donât know.
So, I think you just need to recalibrate your probe to fix something. If you have a constant offset of -0.1, then you should recalibrate with accounting to that offset or figure out where it is coming from.
Baby stepping does work, but saving it doesnât, because the way eddy seems to work (for my understanding) is, that the saved z-offset will only be applied to the trigger height, and not to the actual measurement eddy takes. So, it will take its measurement from 0,1mm higher, but since it will then measure a 0,1mm higher distance to the bed, I end up with the exact same Nozzle height as before adjusting the offset.
For my understanding, there is no way, to fine tune where eddy thinks Z=0 is. The only way to change this at all seems to be the PROBE_EDDY_CURRENT_CALIBRATE macro, with the paper method. But this method just isnât accurate enough, especially for textured beds, where you always have to baby step it down after the paper method.
But with my work around, I consider my problem as solved, at least for now.
I just donât use the SET_Z_FROM_PROBE macro from the eddy repo. (Delete or comment out the whole G28 overwrite in the eddy.cfg file) This way Z=0 is at least always at the same height. I then manage z-offsets with custom variables and macros, instead of the Klipper built-in way. This works fine for me, with perfectly consistent results. My print_start procedure:
Plus two macros for saving and loading the offsets to a file. In my case, itâs a tool changer setup, so managing one more offset doesnât make much of a difference.
Unfortunately, without a klipper log from the event it is hard to guess what the root issue is.
Running a G28 Z0 with the mainline Klipper code and ldc1612 will not be very accurate. The issue is that the current homing code will signal the probe event on the first sensor result at the requested Z homing height. However, we know that in practice the ldc1612 has a measurement noise. To get accurate probe results the code combines dozens of measurements to improve the accuracy. The current Klipper homing code does not currently perform do this, and so is notably less accurate.
It is technically possible to perform homing with the ldc1612 using an ugly two step process. Iâve written about this offline at: eddy_probe_home.md ¡ GitHub
Basically, this ugly hack homes (resulting in an inaccurate home position), then probes (to find a more accurate z height), then adjusts the gcode z offset (to better reflect the actual home position).
If you used the above hack and want to adjust the actual gcode offset, then youâd use something like SET_GCODE_OFFSET Z_ADJUST=+0.100 to alter the SET_Z_FROM_PROBE provided gcode offset instead of replacing it. See G-Codes - Klipper documentation
Just bought my own svo8 and looking to upgrade it to an eddy sensor
But wouldnât it be easier to set a z offset automatically with the touch sensor in the back of the unit and slide the eddy over it or the bed for a approximate z hight offset?
This way youâll get the worst of both worlds, because youâre adding the measurement error of the touch sensor to the error from eddy. Youâre making your contactless Sensor depending on a clean nozzle. If youâre willing to use a nozzle touch sensor for homing, there is no reason to involve Eddy in the process, just use the touch sensor for homig and use Eddy for the bed mesh only.
That aside, it wouldnât help the issue, because this could only compensate for physical variations in eddys position in relation to the nozzle, and the problem lies in getting an accurate position in relation to the bed.
