DELTA_ANALYZE CALIBRATE=extended using wrong heights

General Discussion
1

I got told I can’t post bugs/issues in the GitHub issues section and need to post here instead. I don’t want to re-write the hole stuff so I’ll ink it here:

Can someone please verify that and point me in the right direction on where in the code this issue occurs so I can potentially fix the code.

I’m a dev - unfortunately not a Python dev and it’s been quite a while since I last wrote some python code so it’s still a bit hard to read for me - especially since I’m not really familiar with the Klipper/klippy codebase.

I think it’s happening around here:

For easier debugging I’m adding my calibration values here:

DELTA_ANALYZE OUTER_PILLAR_WIDTHS=9.06,9.05,9.05,9.07,9.05,9.07
DELTA_ANALYZE CENTER_PILLAR_WIDTHS=9.07,8.99,9.03
DELTA_ANALYZE OUTER_DISTS=73.77,73.92,73.84,73.82,73.94,73.86
DELTA_ANALYZE CENTER_DISTS=73.89,73.93,73.82,73.89,73.83,73.76

Since I first discovered this I now have different, albeit equally bad behaviour which doesn’t make sense at all. I got the exact same results above even after restarts and the day after.

Now a few days later (no delta calibration or bed mesh done in the meantime I get completely different results which are off even more.

Log file from today attached here. Log files from the original run can be found in the github issue.

klippy (2).log (195.1 KB)

2

I just ran the calibration again - after changing microsteps of my ABC motors to 16 and enabling interpolation. For some reason this results in values that are actually plausible:

stepper_a: position_endstop: 397.491771 angle: 210.061620 arm_length: 438.335915
stepper_b: position_endstop: 397.196690 angle: 329.825336 arm_length: 438.397315
stepper_c: position_endstop: 397.003097 angle: 90.000000 arm_length: 439.453453
delta_radius: 226.538857

This calibration also only took a few seconds to complete vs. several minutes for the others.

klippy (5).log (437.9 KB)

Will try to disable interpolation in the printer.cfg now and re-run it and see what it yields.

3

Git version: 'v0.10.0-377-ga02da851-dirty'

You appear to be using modified code, or your local Git repo is corrupt. You need to reproduce using a clean Git version.

4

I added an additional debug message:

pi@klipper:~/klipper $ git diff
diff --git a/klippy/extras/delta_calibrate.py b/klippy/extras/delta_calibrate.py
index 04cbe29e..de6dab31 100644
--- a/klippy/extras/delta_calibrate.py
+++ b/klippy/extras/delta_calibrate.py
@@ -166,6 +166,7 @@ class DeltaCalibrate:
         # Setup for coordinate descent analysis
         kin = self.printer.lookup_object('toolhead').get_kinematics()
         orig_delta_params = odp = kin.get_calibration()
+        logging.info("orig_delta_params: %s", orig_delta_params);
         adj_params, params = odp.coordinate_descent_params(distances)
         logging.info("Calculating delta_calibrate with:\n%s\n%s\n"
                      "Initial delta_calibrate parameters: %s",

The latest logs are from -377. The initial klippy.log is from a clean branch without this change.

5

Here you go, from a clean branch:

32 microsteps (broken):
klippy (7).log (874.4 KB)

16 microsteps (working):
klippy (8).log (1018.5 KB)

Looks like this could come from configured microstepping in the config. Microstepping values imho shouldn’t affect the outcome of DELTA_ANALYZE.

It doesn’t affect the normal calibration in a way that it’s broken, so this shouldn’t either.

What could be done to eliminate this issue?

// Edit:
running DELTA_ANALYZE with configured 64 microsteps now. This is taking ages compared to seconds for the calculations with 16 and 32.

64 microsteps (broken without a clear pattern at first glance):
klippy (9).log (1.1 MB)

6

If you change the microsteps on the printer then you’ll need to rerun the basic DELTA_CALIBRATE command (along with SAVE_CONFIG) before running DELTA_ANALYZE. This is necessary because the DELTA_CALIBRATE command encodes its measurements as the number of step-pulses from endstop to z contact. If the microsteps changes then the number of step-pulses wont be accurate and the DELTA_ANALYZE command will not produce correct results.

-Kevin

7

Yeah, that’s the conclusion I ended up with.

But why doesn’t it invalidate the basic DELTA_CALIBRATE results? (rhetorical question mostly).

Would it make sense to save the used microstepping for the basic routine so it can be used for correct “extended” calibration?

From the manual it isn’t clear that changing microstepping affects/invalidates delta calibration results (which imo it shouldn’t do anyways?)

Changing microstepping basically forces you to re-print the whole thing and start measuring the part all over again (as delta_calibrate invalidates the extended calibration).

8

I agree Klipper could have done a better job at warning about an incorrect configuration.

It’s not immediately apparent how to check for it, though, as any of rotation_distance, microsteps, endstop_position, etc. would make the DELTA_ANALYZE command invalid. FWIW, when this code was written, tmc drivers were not as common and changing microsteps was not common. I guess one could write code to look for absurd “initial heights” and inform the user something is wrong.

We can update the docs - the procedure was intended to be DELTA_CALIBRATE, SAVE_CONFIG, print test object, DELTA_ANALYZE - with no notable changes in config or hardware between any of those steps.

Cheers,
-Kevin

1 Like
9

If I get enough spare time (will take a while) I’ll probably look into Klipper’s delta calibration routine further myself.

Ultimate goal at some point for me would be to port over the Delta Calibration routine from RRF anyways.

Need to gather some experience with the Klipper codebase first though…

10

FYI, I added a note to the docs (commit e43fd4fa).

-Kevin

1 Like
11

Just a heads up we will need a M579 if you want to follow the RepRap calibration since it avoids different arm lengths in lieu of a X and Y correction factor. I started a thread for this as well since I use those correction factors for shrinkage when i am doing very tight tolerance prints. Right now I am using an excel to fake the advance calibration values to scale my X/Y shrinkage till I mangle the code.

The Klipper calibration with over 5mm arm lengths deltas (true error is only 0.5mm) have surprised me but i understand you need a decent arm change to affect X/Y scale in the tower directions, and it does work… I kind of want Klipper’s delta calibraiton added to RepRap and RepRap’s axis correction factors added to Klipper. ^^

12

You can use skew_correction on a delta - which may do what you want (I’m not sure).

-Kevin