LDC1612: additional options

[nefelim4ag]

The first patch with the current somewhat necessary. Without it, the carto is practically unusable.
From my oscilloscope probes, it shows low, low-amplitude voltage <1.2v with a calibrated 29 value.
When it is hot, it is worse.
So, I got a lot of:

        // Sensor reports an issue - cancel homing
        ld->homing_flags = 0;

From raw data on the host, it seems even in this case, it is occasional, so technically, it can be possible to filter it or trigger it later.

High current fixes this issue and is autocalibrated to 19 ~ 6 / 31 * 19 = 3.67 mA.

The second patch is optional, it is added simply because:

I've seen some strange noise sometimes (like frequency is not stable enough), but I guess it should not affect the sensor.
All data that I'm able to get from the sensor are strongly <3.15MHz (~3.1 at Z=0).
(Closer -> higher, hotter -> higher).

We can technically disable amplitude errors, or at least I think - I will add a patch with some error feedback somewhere.
Because it is really not an obvious error in the current setup.
Also, it can be good to get the low/high amplitude status value, but I was not really successful in doing so from Python.
So, I did not invest time here.

Thanks.

[KevinOConnor]

Thanks for working on this. We can certainly add new config options, but I think it would be good to first get a feeling for what the total set of options should be and how a typical user will calibrate them. That is, I think we'd want to avoid adding piece-meal options which may unnecessarily complicate the config.

Separately, it's been suggested at #6785 (comment) that it may be useful to ignore some amplitude errors if the frequency indicates the probe is far from the bed. (That is, there's no need to be picky about an accurate reading if we know the distance isn't particularly accurate anyway.)

Cheers,
-Kevin

[nefelim4ag]

I think it would be good to first get a feeling for what the total set of options should be and how a typical user will calibrate them. That is, I think we'd want to avoid adding piece-meal options which may unnecessarily complicate the config.

Alas, I can't comment on the overall option set and how the finished EDDY probe should look.
My understanding is still somewhat limited.
I agree there should be no option that I cannot explain how to calibrate or define (there is a config reference).
If the concern is that I left it for the user, it is easily fixable.
I can calibrate them, but not describe them in the configuration reference.
This is my vision in the context of the existing implementation.

0. Install probe
1. Move bed to zero/touch nozzle ~ 0
2. Check auto current: it would be some value N
3. Move bed/Z far away, probably far let it be 20..50+mm or half of max_z
   (or just exponential search, where x2 distance no longer affects the value).
4. Check auto current: it should be N-1, or less.
5. If value > 24 = 3/4 * 31, try high current and repeat from Z=0 and step 2
6. If high current value <= 8 = 1/4 * 31, use low current range.
7. Return to zero again.
8. PROBE_EDDY_CURRENT_CALIBRATE ... (probe offset/distance calibration).
9. If the max frequency is lower than the next lower deglitch, -> decrease the deglitch¹.

I can automate this and somewhat suggest as the default.
It is in the docs: https://www.klipper3d.org/Eddy_Probe.html
Or even reduce it to what we have now, but with the conditional 2 step current check with that large distance.

The only caveat is that currently this is a separete procedure, with required save config between LDC current calibrate and Z map.
So, maybe the auto load of the new current value in runtime, and return Z to zero, to allow the PROBE_EDDY_CURRENT_CALIBRATION - can help with setup a little. And or reuse of Probe helper here.

I can just update PR with that.

I do not want to complicate the planned homing rework/refactor.
Nor do I want to complicate things in general.

About small features, what I can think of:

1. Do the sparse Z map with 1mm (?) step². Where we rise Z as long as the difference between measurement points is larger than the stddev.
   If the difference <= stddev, remove the point and all subsequent points.
   To roughly map the Z space.
2. Define PROBE_EDDY_QUERY, to get the current value.
   (But IDK yet if it would be useful to do SET_KINEMATIC_POSITION and so avoid fragile³ homing for now).
3. Babystep the calibration Z values (or shift them by the GCODE_Z_OFFSET)⁴.

Separately, it's been suggested at #6785 (comment) that it may be useful to ignore some amplitude errors if the frequency indicates the probe is far from the bed.

Mmm, it seems to me that it would be hard to do with the current code and/or homing implementation.
I mean to say to the mcu conditionaly, that this specific flag is noop for now.
But we can disable it from the host by the config I guess?
Query probe, large Z (sparse map!) - disable, move, check, move ... meeh.
I would hope that the host-side query can allow us to avoid that completely.

Thanks!

---

Footnotes

1. This is somewhat disputable where/when the frequency is low enough, and technically requires some additional experiments with temperature drift, and I mentioned that I'm okay with not adding it - it is optional. ↩

2. I hope in combination with query and at least eddy.get_status() for macros it can work. ↩

3. I mean fragile in the sense of how it behaves now sometimes. Also, there are unexpected, random Homing Timeout errors over USB. I didn't figure it out yet._ ↩

4. I know there is no real Z offset. I honestly struggle with Z calibration with a piece of paper over rough PEI. It is easier to fine-tune the final value with printing: https://docs.ratrig.com/commissioning-guides/v-core-3-1#z-offset.
   I guess there can be complications with the current homing/probing and the thermal drift. It is somewhat compromise from current macro hacks. ↩

[nefelim4ag]

I removed the high current from the config reference and incorporated it into the drive calibration routine.
If it is okay to use the probe routine in this place, it can be incorporated to get Z=0 and the deglitch value.

Otherwise, I guess the deglitch setting can be removed for now until someone can prove its usefulness.
From my brief checks, there are no frequency spikes in the data with the current ODR setting, so averaging/precision.

Thanks.

[nefelim4ag]

Alas, I do not have precision equipment to verify the numbers https://www.ti.com/lit/an/snoa950/snoa950.pdf
But I hope this can give some rough idea, because they seem not to have a linear scale. Measurements are taken with a multimeter on a 5V board supply.

(Weird drops of current or if there are no significant changes - skipped)

mode	Current Boost=0	Boost=1
Standby	17.61 mA	17.70 mA
IDRIVE 1	+0.65 mA	+0.67 mA
IDRIVE 7	--	+0.81 mA
IDRIVE 9	--	+0.88 mA
IDRIVE 10	--	+0.93 mA
IDRIVE 11	--	+1.04 mA
IDRIVE 13	+0.73 mA	+1.20 mA
IDRIVE 15	+0.75 mA	+1.43 mA
IDRIVE 16	+1.22 mA	+2.02 mA
IDRIVE 17	+1.37 mA	+2.33 mA
IDRIVE 19	+1.41 mA	+2.63 mA
IDRIVE 20	+1.51 mA	+2,82 mA
IDRIVE 21	--	+3.17 mA
IDRIVE 22	--	+3.57 mA
IDRIVE 23	+1.67 mA	+4.06 mA
IDRIVE 24	--	+4.20 mA
IDRIVE 25	+1.81 mA	+4.67 mA
IDRIVE 27	+2.05 mA	+5.65 mA
IDRIVE 29	+2.35 mA	SKIP
IDRIVE 30	+2.42 mA	SKIP
IDRIVE 31	+2.74 mA	SKIP

So, I would adjust the thresholds slightly further.