Implement DELTA_GET_CALIBRATION and DELTA_SET_CALIBRATION

[Fabi0San]

Simple implementation of commands to get and set delta calibration parameters.
The main point of adding this support is just so Klipper can be used with external delta calibration solutions such as Delta Micro Calibrator which I authored.

With this merged I'll be able to add Klipper support which has been long requested: Fabi0San/DuCalibrator#1

Signed-off-by: Fabio Santos [email protected]

[Fabi0San]

sigh, this back compat with step_distance is such a pain... I need some time.

[pandel]

Hi!

I wanted to try your PR, but get the following error with current Klipper version (5c10001)

I just downloaded both files and replaced the original ones.

Internal error on command:"DELTA_GET_CALIBRATION"
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/gcode.py", line 182, in _process_commands
    handler(gcmd)
  File "/home/pi/klipper/klippy/gcode.py", line 120, in <lambda>
    func = lambda params: origfunc(self._get_extended_params(params))
  File "/home/pi/klipper/klippy/extras/delta_calibrate.py", line 303, in cmd_DELTA_GET_CALIBRATION
    (",".join(("%.6f" % (n)) for n in delta_params.stepdists))))
TypeError: not all arguments converted during string formatting
Transition to shutdown state: Internal error on command:"DELTA_GET_CALIBRATION"

Regards,
Holger

[Fabi0San]

Thanks for looking Holger, I took a beating from the tests and tried to move things around and ended up breaking something. I'm taking a look and will update here once it works.

[Fabi0San]

@pandel, it should be ok now. It was a silly mistake over operator precedence (%+).

[pandel]

Thanks for the quick fix! I'll give it a try asap.

[pandel]

@Fabi0San
It works now :-). And it is definitely better to move my questions, so see: Fabi0San/DuCalibrator#21

[Fabi0San]

Thank you Holger, those are very good questions and suggestions for the plugin, but unrelated to this Klipper PR.
In the interest of keeping the noise out of this repo, we should either take it offline or make it a bug/suggestion on DuCalibrator repository.

I'll get back to you shortly.

Thanks,
Fabio.

[KevinOConnor]

Thanks. As high-level feedback, I'm not sure this PR would meet our guidelines that new commands have a "high-impact" ( https://www.klipper3d.org/CONTRIBUTING.html ). Said another way, I'm not sure I could identify a target user audience of at least 100 people and it's not clear to me the advantage they would have using the new commands over the existing delta calibration tools.

I could be wrong of course. FYI, a good place to discuss this PR, get testers, and engage a reviewer is on the Klipper Discourse server ( https://www.klipper3d.org/Contact.html ).

-Kevin

[github-actions]

It looks like this GitHub Pull Request has become inactive. If there are any further updates, you can add a comment here or open a new ticket.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[Fabi0San]

Hello @KevinOConnor, thanks for looking, sorry it took so long to respond, work has kept me busy.

Generally speaking, I think that motion control FW such as Smoothieware, Marlin, Klipper gains by being hyper focused on just running GCODE really well. I think we should leave the other specific scenarios such as screens, calibration, slicing, network connectivity, etc to external solutions. Especially now that our ecosystem has grown so much and great solution stacks exist with various plugins for every crazy scenario.

In my specific case, I have been seduced by the speed of Deltas early on and ended up discovering its intrinsic strong calibration dependency and error magnification nature when it was too hard to back out.
I'd argue that very few Deltas out there can deliver dimensional accuracy when printing away from the center, and most are now leaning on mesh leveling too hard.

The calibration processes that exist today take too few calibration points (minimum to resolve linear regression), and that does not account for the noise of probles, belts, pulleys etc. Those unaccounted errors get magnified because Delta.

My approach was to use thousands of calibration points on a very laborious process which I assumed to be once in a lifetime event. Long story short, turns out geometries change, either by my constant modding of various printer parts, expansion of materials with room temperature, or belt stretch by relative humidity, or because I put my printer on trunk of my car and drive like a maniac once a week to bring it to my favorite maker space show and tell.

So I automated my Obsessive Compulsive Delta Calibration process into an Octoprint Plugin which is installed on at least 120 instances of Octoprint:
https://github.com/Fabi0San/DuCalibrator
https://plugins.octoprint.org/plugins/DuCalibrator/

And I have used it with Smoothie, Marlin, and Now Klipper, which all needed a few adjusts to play well with external plugins for all delta geometry parameters:
MarlinFirmware/Marlin#18423
MarlinFirmware/Marlin#18367
MarlinFirmware/Marlin#17299

So that is my pitch:

• Calibration doesn't have to be part of motion control FW
• 120+ users(I can rally more at the Delta forums and Discord)
• Existing calibration methods take too few data points to wash out probing/measuring errors,
• Geometries move.

I hope you'll reconsider even if for the first point alone.
Thanks for all the good work!

[KevinOConnor]

I understand. As high-level feedback, this sounds like something to discuss on Klipper Discourse ( https://www.klipper3d.org/Contact.html ) to gather ongoing feedback from users and developers.

Separately, Klipper also has an API Server that allows great control of Klipper functionality from external programs ( https://github.com/Klipper3d/klipper/blob/master/docs/API_Server.md ).

-Kevin