Giter VIP home page Giter VIP logo

Comments (12)

zech avatar zech commented on June 19, 2024 1

I think @pfn has a point here.

But that would require to define [probe] as a virtual Z endstop.
That way the endstop would only be used to find the offset between nozzle and switch but still including the tunable switch offset to define the squish you want.

The different build plates would be handled by probing the surface directly to find our 0 because it's defined as a virtual Z endstop.

Unless there's something he's missing (or I am) I'd think that's correct and it would eliminate one step and maybe some variance as well.

And we only need to find this offset once per hotend/nozzle change and maybe temperature change if we'd consider thermal expansion of the nozzle (that maybe a reason for the current procedure alone).

It's also possible that defining the probe as a virtual Z endstop could disable the physical Z endstop. I guess that would require some more "modding" in Klipper to get both the virtual Z endstop and the physical one as a measuring device.

from klipper_z_calibration.

zellneralex avatar zellneralex commented on June 19, 2024

Many of use have more than one flexplate aka print surface, furthermore there is thermal expansion of your bed. To get these 2 factors in the measurement you need to probe the surface.

The whole process is done to find the optimal gcode offset for the current situation before you lay down the first layer.

from klipper_z_calibration.

pfn avatar pfn commented on June 19, 2024

Many of use have more than one flexplate aka print surface, furthermore there is thermal expansion of your bed. To get these 2 factors in the measurement you need to probe the surface.

The whole process is done to find the optimal gcode offset for the current situation before you lay down the first layer.

@zellneralex this is rote repeating what others have said and is not grounded in geometry. The nozzle offset from clicky switch is constant regardless of build surface in use (you can switch build plates from 1mm to 5mm or any other difference and it has no bearing on Z offset of clicky). There is a factor of thermal expansion of the nozzle, but it is also constant (assuming printing at a consistent temperature, otherwise it varies about a babystep going from PLA to ABS). Swapping build plates, bed thermal expansion and heat soak does not affect Z offset.

In general, my variance using auto is about 0.015mm, which is enough to be off by a babystep if used every print; I would prefer to lock in a stable setting and not auto-Z every print and potentially be off a babystep. Perhaps it is a little more valuable when printing at temperature extremes (PLA to PC)

from klipper_z_calibration.

zellneralex avatar zellneralex commented on June 19, 2024

What has the klicky offset to do with that? The offset between the external endstop and the print surface is variable if you have 2 flex plates where one is eg 1 mm and the other is 1.2 mm. To compensate for differences like that you need to probe all 3 points
1 Endstop
2 microswitch body to get an offset between your endstop_pos and klicky
3 surface to get the gcode offset for the current situation

from klipper_z_calibration.

pfn avatar pfn commented on June 19, 2024

Clicky offset is the only probe that matters. Any homing probe should be done with clicky, IMO, not the Z endstop. Deriving a Z offset for the Z endstop superfluous as the number can only ever be calculated by the use of clicky while the clicky is used for all probing moves.

from klipper_z_calibration.

TitusLabs avatar TitusLabs commented on June 19, 2024

Yes, I think you're right. Instead of the Z-Endstop, it would be possible to use the probe as virtual endstop. So, probing bed is Z=0 and then probe the nozzle and the probe in relation to this to get the nozzle's offset. This solution maybe much more tricky with Klipper. And what is your benefit? Do you want to drop the third probing on the bed?

  • I would still probe/home the bed before Z calibrating because the offset value changes a lot over time in my closed printer printing ABS.
  • And using the probe for homing is more difficult. The probe must be mounted to the Gantry. It would be impossible to home Z with the probe mounted to the bed.
  • And in any case it needs the switch for probing the nozzle (and the switch) - then, why not use it for homing too?
  • Changing this would lead to a breaking change...

Is there a good reason to do so what I'm not aware of?

from klipper_z_calibration.

pfn avatar pfn commented on June 19, 2024

I mostly want to understand why the third probe is necessary, but difficulty with klipper would explain the reasoning. I have my own implementation of this that doesn't require the last bed probe, but it's not on klipper.

I wanted to make sure I wasn't missing anything with regard to what opportunities I would miss without the last bed check. It seems like there isn't anything for my configuration.

from klipper_z_calibration.

TitusLabs avatar TitusLabs commented on June 19, 2024

The most reason is that a homing is not so accurate as a probing. And the homed Z=0 may have changed since then. In this routine it doesn't matter since I probe the nozzle again in step 1 (and it's even relative to Z=0). But I would also repeat the probing on the bed since this could have slightly changed too... this is the beauty - it is always perfect! It doesn't rely on old probing/homing values. And as I already wrote, some points may not be so important if your printer does not get so hot...

What is your implementation? Is it public?

from klipper_z_calibration.

pfn avatar pfn commented on June 19, 2024

What is your implementation? Is it public?

@TitusLabs my implementation is https://github.com/pfn/voron2-rrf-config/blob/master/macros/Calibration/Calibrate%20Z%20Offset -- plain and straightforward.

from klipper_z_calibration.

TitusLabs avatar TitusLabs commented on June 19, 2024

Oh nice, an other implementation for RRF 👌 It seems to be so much easier ... but it's so unreadable 🤯

from klipper_z_calibration.

pfn avatar pfn commented on June 19, 2024

Oh nice, an other implementation for RRF 👌 It seems to be so much easier ... but it's so unreadable 🤯

I get what you're saying. I read gcode fluently as a result of using rrf. Sucks for anyone that doesn't though.

from klipper_z_calibration.

TitusLabs avatar TitusLabs commented on June 19, 2024

I think, I need to play with RRF again on my next printer. RRF2 and DuetWifi2 times are long ago..
I will close this now

from klipper_z_calibration.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.