[FR] G-code command/option to probe known object and update nozzle-to-probe offset

wlritchi commented 3 years ago

Is your feature request related to a problem? Please describe.

Use case: On some printers, gradual deformation in the gantry may lead to a shift in the position of the probe relative to the nozzle, which would be addressed by recalibrating the nozzle-to-probe offset. This process can be done manually, but is tedious, especially without an LCD. I'm looking for a small firmware feature that I think would greatly simplify this calibration process.

Are you looking for hardware support?

Nope, software feature for existing supported hardware.

Describe the feature you want

For comparison: Marlin currently supports using a probe reading and a known good offset to update the Z axis position (G28 Z), and also supports using a probe reading and a known good position to report the positioning error (G425).

I want a G-code command to use a probe reading and a known good Z axis position to update the probe offset non-interactively. I imagine a usage somewhat like the following:

G999 X10 Y20 Z30

With this command, the print head would move such that the probe is located at X10 Y20 (according to the existing nozzle-to-probe offset), then probe downwards. Suppose that when contact is made, Z is 35. Then the Z component of the nozzle-to-probe offset would be set to -5.

Alternative: as an extension of `G425`

It may make the most sense to implement this as an extension to G425. Note that while G425 supports updating offsets between multiple extruders, it normalizes the values such that extruder 0 has zero offset, and cannot update the offset between the probe and the extruder (which Marlin treats separately from the inter-extruder offsets).

I think the minimum required additions to support my use case are:

G425 supports all probes supported by Marlin, rather than only supporting passive probes that pull a pin high or low. For example, it should be able to use a BLTouch or other probe that has to be deployed to become active.
G425 accepts a boolean parameter that, when enabled, causes it to update the nozzle-to-probe offset based on the position error for extruder 0.

Nice-to-haves for usability:

G425 accepts the position and dimensions of the calibration object as parameters, not just as constants in Configuration.h. I mention this desired addition because, even if it's not a priority, planning for this feature may influence parameter name choice for the above.
G425 accepts parameters controlling the direction(s) to probe in. Currently it probes in every direction it thinks it's capable of, while users may want to only update the Z offset (for example).

Additional context

I may implement this myself and open a PR, but I wanted to check first to make sure I'm not missing an existing feature, and to get design feedback on the most useful/general way to meet my use case.

There's prior discussion of similar ideas at #18305, which asked about non-interactive updates to offsets. For offsets between extruders, this is in fact already supported by G425. That FR mentioned as prior art Haas' G37 which appears to be similar.

More radical brainstorming: If I were implementing this from scratch, I would be inclined to remove the nozzle-to-probe offset, and instead treat every extruder including extruder 0 as having an offset from the probe. Alternatively, I would consider treating the probe as a tool, and storing its offset (from tool 0) in the tool offsets array rather than treating it separately.

thisiskeithb commented 3 years ago

On some printers, gradual deformation in the gantry may lead to a shift in the position of the probe relative to the nozzle

Is this common to a specific brand or design? I would think this would be a really important part of a printer that should be redesigned if it continually deforms.

wlritchi commented 3 years ago

My gantry has a really bad BLTouch attachment mechanism (my own design, my own fault) so there's definitely a pretty big "hardware at fault" aspect. But then again, bed leveling is like this too, and we're okay with features to help with that as long as they're behind a flag :)

DerAndere1 commented 3 years ago

What is the benefit of this feature versus prior art set of commands (G38.2 straight probe, G43 Tool Offset Compensation as described in the RS-274 standard, plus Haas G37 Automatic Tool Offset Measurement) ?

wlritchi commented 3 years ago

The equivalent workflow with G38.2 is to probe to the workpiece, report the current position, calculate the difference between this position and the expected/known good position, report the current probe offset, calculate the new probe offset to account for the position error, and set the probe offset to this new value. Much like bed levelling using a feeler gauge, it's a manual process that's tedious, and automating it is a usability improvement. Additionally, despite having done this process several times, I still find that I'm prone to calculation error because I get confused about whether the offset needs to be increased or decreased. Putting it in software reduces the opportunity for user error, as long as we can present an easy-to-understand interface.

The equivalent workflow with G425 is similar, except that the first calculation is done for you. By my reading, G425 currently doesn't support the BLTouch, though.

The Haas prior art (G43/G44 to enable, G37 to measure) is a reasonable design, and if implemented, I believe it would meet my use case. There are two main reasons I expressed my FR in a different way:

My reading of G37's design is that it assumes that all tools may have an offset from "true zero" in the toolhead coordinate system. I like this design, but my understanding of Marlin's current model is that tool 0 does not have an offset; the position of that tool defines the coordinate system. Therefore, implementing G37 would probably involve changing a lot of assumptions in the current codebase. I opted to ask for what felt like the smaller change: keep the current distinction between "inter-toolhead offsets" and "nozzle to probe offset". If the Marlin team would rather implement G37 and start treating the probe as "true zero", I'd be happy with that too.
I believe that #18305 was originally asking for G37 support, and was directed towards G425 as an existing solution with a bit more manual work. Given that G425 is already viewed as covering (some of) the use cases for G37, I presented an option for how to extend G425 to meet my use case, rather than adding an entirely new command.

DerAndere1 commented 3 years ago

Marlin's current model is that tool 0 does not have an offset;

I expect that this will change: For multi-purpose machines, we should implement G43 tool length compensation anyway and that would make Marlin behave more standard-conforming. Plus, it will pave the way towards G37.

MarlinFirmware / Marlin