Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

probe_eddy_current: Fix "z-offset" did not apply as expected #6625

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bigtreetech
Copy link
Contributor

Currently, many users have reported fine-tuning the z-offset during printing to make the first layer perfect. After printing is completed, SAVE_CONFIG and restart to print again. The z-offset does not take effect and still needs to be adjusted.

This is because when using Eddy as the z-axis endstop, the parameter of z-offset is applied to the homing, and the actual height of the z-axis at which the homing stops varies depending on the value of z-offset. So it is necessary to fix a homing height so that z-offset can take effect as expected.

In theory, the correspondence between the frequency and distance of Eddy is obtained through Paper test and calibration, and theoretically, z-offset does not need to be adjusted at all. But in reality, there are indeed many users who need the z-offset function.

The ldctap you previously implemented can also solve this problem.

@KevinOConnor
Copy link
Collaborator

Thanks. I don't think this change will work correctly though.

It looks like the change will alter the homing position if one homes with the ldc1612, but it will not alter the probing positions.

Unfortunately, basic homing with the ldc1612 is currently not accurate at all. When probing, many measurements (20+) are taken from the ldc1612 and averaged to estimate the height. However, if one were to home with the ldc1612 the toolhead is halted on the first measurement found above a particular threshold - that mechanism is highly susceptible to noise.

It is possible to home with the ldc1612, but it would require a second PROBE stage after the initial Z homing to obtain more accurate results. The steps would be something like https://gist.github.com/KevinOConnor/cb8690ba11019808295fb8d89fb2ef41 . If one follows these more precise steps, though, the PR here would not impact the overall homing results, as the PR here doesn't change the results of PROBE.

I agree it would be useful for Z_OFFSET_APPLY_PROBE
to work correctly with the ldc1612, but I think a larger change would be needed so that the PROBE results are also updated.

(It would also be useful for the ldc1612 homing code to not require a separate PROBE stage, but that is a lot more work as it requires refactoring of some of the low-level homing code.)

-Kevin

@freakydude
Copy link
Contributor

freakydude commented Jul 6, 2024

I also tried eddy (coil) these days. It seems to be working in my initial tests - but similar to what @bigtreetech mentioned, I am having problems with the first layer/z offset after homing. I had the same temperatures while testing, so hopefully it is not thermal drift. Issues in this case means - after adjusting the z offset while printing the first layer - the rest prints very nicely. So scanning the bed mesh does not seem to be wrong. But after homing again - the same problem repeats.

@KevinOConnor Two more things:

  1. I do not have an aditional z endstop, so this guide (https://www.klipper3d.org/Eddy_Probe.html) was missing something important. I had to set the SET_KINEMATIC_POSITION Z=20 by hand. If I didn't do this, the PROBE_EDDY_CURRENT_CALIBRATE command that ends with z is not homed. And I couldn't home it without a probe. Maybe I have misunderstood something - but if not, execute this is the missing hint in this procedure.
  2. I used to use a BTT MicroProbe and before I got the previous trick, I tried to enable the probe in addition, confgured as before. So I had a section [probe] and a section [probe_eddy_current btt_eddy]. In this order I got:
    Klipper reports: ERROR
    gcode command QUERY_PROBE already registered
    
    When I reordered the section [probe_eddy_current btt_eddy]...[probe]) I got:
    Klipper reports: ERROR
    Option 'pin' is not valid in section 'probe'.
    
    Both sections work fine when they are alone.

What I was trying to do was to use the microprobe as z endstop and the eddy as a fast solution to generate a bed mesh.

Is it a bug that you can't configure both together? Does this not occur with a physical end stop? Is it even necessary once the eddy implementation has eliminated the error mentioned?

Would be nice if you or someone could clarify this.

... and as always, let me know if I can help ...

Thank you very much.
Kind regards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants