BTT Eddy variance with home command

Basic Information:

Printer Model: SV08 - Mainline Klipper

Hi,

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.

0.00135 / 0.000025 = 54
10 / 54 = 0.185 mm/s
40 / (1000 * 16) = 0.0025 mm

If the sensor has enough sensitivity and resolution to provide that.

Hope it helps.

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.

I had a similar experience with the BTT Eddy:

  • With a fixed z-offset, the homing value would become unstable and jump up to 0.2 mm.
  • BTT mentions this behavior a bit unclearly here.
  • The “beta macros” seem to be an improvement but still not to my liking.

Finally, I reverted the BTT Eddy mod and went back to the MicroProbe on this printer.

1 Like

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:

    G28          
    QUAD_GANTRY_LEVEL
    BED_MESH_CALIBRATE ADAPTIVE=1 METHOD=rapid_scan
    SET_GCODE_OFFSET Z=0 MOVE=0
    SET_GCODE_OFFSET Z_ADJUST={printer["gcode_macro T0"].z_offset} MOVE=1

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.

As a result of this limitation, the mainline code does not recommend using the ldc1612 sensor for homing: Eddy Current Inductive probe - Klipper documentation

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

Hope that helps a little,
-Kevin

1 Like

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.