Unsolved Mystery. Weird Z0 behavior around build perimeter.

[bdjohns1]

I think adjusting endstop offsets in firmware causes the problems... this is precisely the variable we want to eliminate - math errors by the controller board.

Firmware carriage offsets are not factored into actual motion planning. When you G28 the printer and it hits the endstops and backs off, it moves the carriages down by some number of steps according to the firmware settings. If you only use the adjustment screws, that number is 0. Otherwise, it's some other number, with each step repeatable to ~0.01mm or better depending on microstepping and how many teeth your pulleys have. (Try getting 0.01mm accuracy on those screws. You might get it, but it'll take way longer.) Whether the carriage is at 403.8461mm purely because of adjustment screws, or adjustment screws + firmware offsets, makes no difference. As soon as the carriages get where they're going, that becomes "relative zero" and the printer's coordinate system is initialized. After that, the printer doesn't use the carriage offsets in any calculation until G28 is run again.

Right. It's literally an integer add/subtract operation for # of steps during the homing sequence before any of the delta math gets done, so there's no risk of rounding / truncation errors. bot, look in Repetier's Printer.cpp for a function called Printer::homeZAxis() if you need to satisfy your curiosity.

All you need to know is your mm/step, which I'm pretty sure can be left as a simple exercise to the casual observer who knows their steps/mm

If you're just lazy, on the stock configuration RoMax it's 1 / ((16 microsteps/step * 200 steps/rev) / 40 mm/rev) = 0.0125 mm/step.

[Jimustanguitar]

.0125 per microstep

[bdjohns1]

.0125 per microstep

I had the 16:1 conversion in there. In the firmware, once you define motor steps/revolution, steps/mm and microsteps/step, then from there on in the math, 1 "step" = 1 microstep = 0.0125mm.

[mlapaglia]

Okay, I'm going to suggest what I remember my steps for resolving this were:

1) set the 0,0 point at your desired height (paper thickness).

2) Set all three tower points at the same height. This should now mean the plane is level? Not necessarily.

3) Move the hot end from A tower position and 0,0, watching very closely to the path of the nozzle. Does it travel STRAIGHT across the bed? Or does it lift up and then back down from the tower to the center point? Adjust your firmware settings until this is FLAT. My making this flat, your plane will likely be sloped in an odd direction. That's okay.

4) Re-set every tower height as in step 2.

5) Now you will move the hot end from the tower points to "opposite" tower points. As in the point of the bed directly across from the tower, in between the other two. You now have to set these opposite heights by adjusting the physical end stop screws. Continually adjust the screws, set all the height points, move the hot end across the bed.

6) Repeat steps 1-5 until you are happy with results. By repeatedly adjusting these variables, you will slowly bring your machine closer and closer into spec. When adjusting this, you'll maybe want to bring the hot end farther away from the bed and use the firmware movements of 1mm and .1mm to "measure."

If any of this is unclear let me know... it's possible you've tried repeating this procedure, but it was what lead to my solution. When I get my max v2 kit I'll take pictures and detail my calibration process (if it even works).

Thank you for the detailed description, I think you are pretty much right on. I do very much the same thing.
Yes, it can be very tedious and time consuming , but worth the effort. And far better than any auto probing routine I have seen so far.

Sorry to bother, but for step 3 how are you adjusting this in the firmware?

[bot]

It is no bother at all, that's what we're here for. I was running marlin on a homebuilt rostock at the time, so I was adjusting the delta radius via the DELTA_SMOOTHROD_OFFSET variable. I'm not yet familiar with the firmware people are using on the MAX (I just got mine, it's lying in pieces). But by increasing and decreasing the delta radius, you alter the plane to be more or less concave or convex. More info can be found here: http://minow.blogspot.ca/index.html#4918805519571907051" onclick="window.open(this.href);return false;

[mlapaglia]

Ah so it's the same procedure in the manual, cool I'm done up to that step.

For step 5, when I move the nozzle to the opposite end of tower, the nozzle lifts from the bed. The instructions say to adjust the end stops. I'm guessing this means the two towers closest to the nozzle and not the far one?

[bot]

I worded that step poorly. You adjust the ONE end stop screw for the ONE tower that moves the most to make that movement, You'll notice the other two towers essentially do not move, while the one that moves down the greatest is the one across from where the hot end would be.

I apologize for my very poorly worded and explained "instructions." The gist of what I wanted to convey was that you should be constantly adjusting variables, which will put other variables out of whack, and slowly by repeating the calibration process you will find an acceptable equilibrium.

Edit:

To clarify, I remember having the same instinct as you and adjusted the two closest end stops first, but then I would have to go and change them again anyway. I realized I wanted to be optimizing each individual tower for their deficiency of the "greatest movement" if that makes any sense at all.

Another tip I would impart would be to make sure your steps/mm are set correctly for each individual tower. I'm not positive about this, but I suspect differences in their construction might lead to minuscule differences in scale which would stack up and create problems if not calibrated.

[bdjohns1]

Another tip I would impart would be to make sure your steps/mm are set correctly for each individual tower. I'm not positive about this, but I suspect differences in their construction might lead to minuscule differences in scale which would stack up and create problems if not calibrated.

Not if you're using GT2 belting (which everyone here who bought a RoMax did) - you have to try really hard to have construction differences that should cause you to adjust steps/mm, unless you've chosen to arbitrarily swap out motion components without having the base knowledge of what or why you'd change things.

The "circumference" of a toothed pulley = number of teeth * tooth pitch. For the stock seemecnc pulleys, that's 20 teeth and a 2mm pitch = 40mm. One revolution of the pulley = 40 mm of movement. That's the beauty of synchronous belting. This is one of the settings that you absolutely do not want to monkey around with to address construction deficiencies. Repetier-Firmware even defines it that way for you in the configuration.h file. You enter # of teeth and tooth pitch, and it does the math for you:

Code: Select all

#define DELTA_DRIVE_TYPE 0

#if DELTA_DRIVE_TYPE == 0
/** \brief Pitch in mm of drive belt. GT2 = 2mm */
#define BELT_PITCH 2
/** \brief Number of teeth on X, Y and Z tower pulleys */
#define PULLEY_TEETH 20
#define PULLEY_CIRCUMFERENCE (BELT_PITCH * PULLEY_TEETH)

/** \brief Steps per rotation of stepper motor */
#define STEPS_PER_ROTATION 200

/** \brief Micro stepping rate of X, Y and Y tower stepper drivers */
#define MICRO_STEPS 16

// Calculations
#define AXIS_STEPS_PER_MM ((float)(MICRO_STEPS * STEPS_PER_ROTATION) / PULLEY_CIRCUMFERENCE)
#define XAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM
#define YAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM
#define ZAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM

Note that you don't even have the option in the firmware to change the steps for a specific axis in Repetier - they all get the same calculated value. That's a pretty good indication that you shouldn't be screwing with that number unless you have a really convincing reason to do so.

[bot]

Well, I'm used to Marlin. I actually find it very odd that Repetier assumes all axes are created equally... differences in belt tension could cause differences in movement... no? (My brain is struggling to compute that...)

Either way, I was only suggesting to CONFRIM that the steps/mm were correct. No harm in that.

BTW, you could easily adjust each axis by adding an appropriate arithmetic argument:

// Calculations
#define AXIS_STEPS_PER_MM ((float)(MICRO_STEPS * STEPS_PER_ROTATION) / PULLEY_CIRCUMFERENCE)
#define XAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM +10
#define YAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM +20
#define ZAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM

[bdjohns1]

Well, I'm used to Marlin. I actually find it very odd that Repetier assumes all axes are created equally... differences in belt tension could cause differences in movement... no? (My brain is struggling to compute that...)

Either way, I was only suggesting to CONFRIM that the steps/mm were correct. No harm in that.

BTW, you could easily adjust each axis by adding an appropriate arithmetic argument:

// Calculations
#define AXIS_STEPS_PER_MM ((float)(MICRO_STEPS * STEPS_PER_ROTATION) / PULLEY_CIRCUMFERENCE)
#define XAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM +10
#define YAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM +20
#define ZAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM

You could, but again, take it a hint that they're not meant to be adjusted. You could also define PI = 3.2 in the code if you want, or set PULLEY_CIRCUMFERENCE to be 0, but that's not smart either. Can != should.

Belt tension is not a significant factor here unless you do something exceptionally wrong. These belts are reinforced with either fiberglass or Kevlar cording so that they don't stretch. They are specifically designed to provide repeatable motion without requiring excess tension. Trust me on this one - part of my day job involves dabbling with motion control systems for packaging equipment, and one of them has synchronous belting driving a 250 kg tool around at 10 m/s with position accuracy usually under 0.2 mm.

The only way a GT2 belt is not going to move in a predictable fashion is if you're so loose you skip teeth on the belt or have damaged it to the point of missing teeth, and if that's happening, again, you've got bigger problems than trying to get your Z height dialed in to within 0.1mm. The procedures in the manual for setting up the belts are sufficient to get it right.

[bot]

Okay, okay, okay. Sheesh. It's just funny that this is the one area of the machine's calibration where the mathematical calculated value "always" translates to the real world value.

[626Pilot]

The procedures in the manual for setting up the belts are sufficient to get it right.

I wish that was enough.

His idea is not bad. There may not be a provision for adjusting the gain on each stepper now, but that doesn't mean the original coder doesn't want one. It may simply not have occurred to them that it would be beneficial in the first place, but something not occurring to a programmer nearly crashed Neil Armstrong and Buzz Aldrin into the moon. On another occasion, a Russian programmer's oversight nearly started a nuclear war, and it took an officer disobeying orders to stop that from happening. We are not omniscient

The problem is that the carriage opposite an area with Z error is either moving too much or not enough, so directly adjusting the "gain" on the steppers could be one way to fix it. I thought about something similar. It would require an arm length test. First, you'd level the endstops. Then, you'd do the printer radius calibration, but it would be a little different!

Instead of testing one tower, you test all three and take the average elevation. If the elevation is too high, the printer thinks the arms on that tower are longer than they really are, so we reduce their virtual length. If the elevation is too low, the printer thinks the arms are shorter than they really are, so we increase their virtual length.

We use some iterative mathematical heuristic (adjust it a little, test, adjust again, test again, etc.) to turn that into an adjusted delta rod length. If the firmware doesn't support individual lengths per arm, but DOES support individual tower radii (which I think Repetier and maybe Smoothie do) I think those can be adjusted instead. I'm not positive, but I think they have a similar impact on the inverse kinematics. Because I'm not positive, my preference would be to adjust the arm length and leave the tower radii alone.

[626Pilot]

This problem caused my nozzle to jam today, which lead to a comedy of errors, except less funny because at the end of a long chain of events my heater block is ruined. I won't get a new one until Tuesday, so I have some time to work on some code to implement the above test. Checking the Smoothie source, I think I know what to do. It also looks like the Z-probe system has been elaborated in the couple of months it's been since I did my own code, so I need to figure out how to hook my code into that. I think it will make things easier.

[0110-m-p]

Just decided to finally update repetier firmware to v0.91 and software to v1.0.6, then do a full machine recalibration with the dial indicator since I have been having some lifting issues between towers Y and Z.

Doesn't sound like I'm having as big of an issue as some, but can't seem to get one spot good enough. I'm <0.001" off at the center and all towers. Then only 0.001"-0.002" (0.025-0.05mm) off between towers Y/Z and X/Z, but the build surface is 0.005" (0.127mm...basically a full layer thickness) low between X/Y.

Any ideas? Check out the video...

http://youtu.be/J5VIr-2wydM" onclick="window.open(this.href);return false;

[626Pilot]

Your probe is showing low near Z and high near XY's midpoint. Try adjusting the Z screw. You may be able to get it within 2-3 thou of variation, less than a layer height at 0.1mm.

[0110-m-p]

Your probe is showing low near Z and high near XY's midpoint. Try adjusting the Z screw. You may be able to get it within 2-3 thou of variation, less than a layer height at 0.1mm.

I feel like I'm running in circles in terms of bed level calibration playing with tower rotation, printer radius, and the endstop screws, but am so close to getting it right. The only thing I haven't played with is tower specific radius settings. What you suggest seems too simple at this point to "fix" it, but I'll give it a try.

FYI, I'm using an E3D V5 hotend with 0.4mm nozzle and 0.15mm layer height (0.24mm first layer). I also have 0.25mm and 0.6mm nozzles. I haven't used the 0.25mm nozzle yet because I don't feel like I'll get good adhesion with my current platform flatness and am thinking about throwing the 0.6mm nozzle in to make the system a little more numb to platform flatness.

Also, since this is my first time seeing what the bed really looks like with a dial indicator (as opposed to the "drag a piece of paper under nozzle" or feeler gauges under nozzle tests), how good is "good enough" in terms of overall build platform flatness?

[626Pilot]

For flatness, I would go with whatever minimum layer height you want to use divided by two. I like 0.1 layers, so I would be okay with 50 microns or less.

Anyone using a Smoothieboard or an Azteeg X5: My experimental branch of Smoothieware

So far, I have implemented two commands. G29 does a repeatability test on your Z-probe. Arguments are S (number of samples, default 10) and E (skip the eccentricity test - saves time but may be less accurate). G31 doesn't do much yet other than probe some test points and report their depths. When it's done, if my assumptions are correct, it will be able to figure out the best combination of individual tower radius, rotation (position along the printer's radius) and arm length. If that isn't enough, I suppose I'll have to implement a height map. One way or another, this damn thing is going to print what I tell it to print, at the layer height I tell it to print it at.

Here's what a repeatability test looks like using my custom Z-probe:

Code: Select all

06:03:08.311 : [RT] Repeatability test: 30 samples, eccentricity test is on.
06:03:08.311 : [RT] 1 step = 0.00469 mm.
06:03:19.230 : [RT] Test 1 of 30: Measured 1823 steps (8.545 mm)
06:03:22.279 : [RT] Test 2 of 30: Measured 1825 steps (8.555 mm)
06:03:25.328 : [RT] Test 3 of 30: Measured 1823 steps (8.545 mm)
06:03:28.377 : [RT] Test 4 of 30: Measured 1825 steps (8.555 mm)
06:03:31.427 : [RT] Test 5 of 30: Measured 1825 steps (8.555 mm)
06:03:34.475 : [RT] Test 6 of 30: Measured 1826 steps (8.559 mm)
06:03:37.527 : [RT] Test 7 of 30: Measured 1825 steps (8.555 mm)
06:03:40.575 : [RT] Test 8 of 30: Measured 1826 steps (8.559 mm)
06:03:43.625 : [RT] Test 9 of 30: Measured 1828 steps (8.569 mm)
06:03:46.678 : [RT] Test 10 of 30: Measured 1827 steps (8.564 mm)
06:03:49.728 : [RT] Test 11 of 30: Measured 1824 steps (8.550 mm)
06:03:52.778 : [RT] Test 12 of 30: Measured 1826 steps (8.559 mm)
06:03:55.830 : [RT] Test 13 of 30: Measured 1826 steps (8.559 mm)
06:03:58.877 : [RT] Test 14 of 30: Measured 1826 steps (8.559 mm)
06:04:01.927 : [RT] Test 15 of 30: Measured 1825 steps (8.555 mm)
06:04:04.977 : [RT] Test 16 of 30: Measured 1824 steps (8.550 mm)
06:04:08.029 : [RT] Test 17 of 30: Measured 1827 steps (8.564 mm)
06:04:11.080 : [RT] Test 18 of 30: Measured 1827 steps (8.564 mm)
06:04:14.132 : [RT] Test 19 of 30: Measured 1828 steps (8.569 mm)
06:04:17.181 : [RT] Test 20 of 30: Measured 1826 steps (8.559 mm)
06:04:20.234 : [RT] Test 21 of 30: Measured 1828 steps (8.569 mm)
06:04:23.285 : [RT] Test 22 of 30: Measured 1827 steps (8.564 mm)
06:04:26.334 : [RT] Test 23 of 30: Measured 1826 steps (8.559 mm)
06:04:29.386 : [RT] Test 24 of 30: Measured 1826 steps (8.559 mm)
06:04:32.438 : [RT] Test 25 of 30: Measured 1828 steps (8.569 mm)
06:04:35.490 : [RT] Test 26 of 30: Measured 1828 steps (8.569 mm)
06:04:38.542 : [RT] Test 27 of 30: Measured 1828 steps (8.569 mm)
06:04:41.592 : [RT] Test 28 of 30: Measured 1827 steps (8.564 mm)
06:04:44.644 : [RT] Test 29 of 30: Measured 1826 steps (8.559 mm)
06:04:47.691 : [RT] Test 30 of 30: Measured 1826 steps (8.559 mm)
06:04:47.691 : [RT] Stats:
06:04:47.691 : [RT]   range: 5 steps (0.0234 mm)
06:04:47.695 : [RT]      mu: 1826.067 steps (8.560 mm)
06:04:47.696 : [RT]   sigma: 1.413 steps (0.007 mm)
06:04:47.696 : [RT] Repeatability: 0.0234 (add a little to be sure)
06:04:47.696 : [RT] This score is average.

[0110-m-p]

Thanks, that was basically what my goal. Currently I am liking the 0.15mm layers with my 0.4mm nozzle...so flatness of 0.003" was my goal. Glad I was on the right track.

Right now I am just using the dial indicator in the center of the effector with the Trick Laser tool holder to make sure the printer's geometry is correct, but doing a z-probe check of the system prior to each print would be nice down the road. So far my printer has been very reliable since this is the first recalibration I have done in nearly 200 hours of print time.

[lordbinky]

Is there any interest in a 3rd party application for bed levelling? I was able to correct several things with a custom smoothieware firmware and some mat lab curve fitting to improve my bed levelling to a max of .015 difference. I'll post my methodology at some point for the impatient, but here's my dilemma. It is much easier for me to implement this in c++ and use a real fpu and avoid any small processor quirks, as well as the issues that would create come from trying to implement it in multiple firmwares since I wouldn't want anyone left out.

Much simpler to provide a script to run and have a user play middleman or just have the program connect to printer. I'm likely going to have to do it for myself, but if another human is ever going to lay eyes on it..well that's a whole new level of effort. How quickly I can achieve this is also a little in the air. I'll be honest, I've been inactive fixing up my house to sell since I'm trying to get out of New Mexico, so as long as my efforts in finding a new job are slow this will go fast, if I succeed it'll get put to the side indefinitely as would be expected.

I'm confident in my method and the algorithms to achieve a true auto calibration. Key features of this tool would be a consistency test. The result of this would determine the maximum accuracy achievable in the bed levelling. I used this in my custom firmware to determine optimal settings for motor current, identify a loose belt, and smaller nit picks. With that the program can then measure points with a know error, and perform a curve fitting to the data. When it is graphed, it is easy to pick the next setting to correct, but I'm sure At the worst I can implement some heuristics and pick what to change next. Doing this manually allowed me to see why I had different X/Y measurements in my prints. This isn't actually a bed levelling, but it is a calibration of the machine in reference to the bed.

I think I can implement it with minimal effort on the user end with firmware independence as long as the firmware allows changes to tower position from gcode commands and a sensor. Let me know if it is something you guys think is still worthwhile, I would definitely post it on github once I feel it won't cause an arc of the covenant response when the source is opened. I also typed this on an iPad so forgive my laziness in cleaning up this post.

[626Pilot]

If you make a middleman program, you have to publish it for three different OSes and it has to be made aware of how each different firmware needs to be told what the offsets are.

It would be better, I think, if you publish your methodology. Then, I can implement it in Smoothie and plumb it directly into Smoothie's representations of the needed offsets. (This would require knowing the actual math rather than asking a third party program for it.) Anyone who likes working with awful Arduino spaghetti can port it to Repetier/Marlin, along with whatever code is required to allow them to change those variables live without recompiling. I would rather get a root canal than ever launch the Arduino IDE again, so that someone will not be me. However, Smoothie is well-organized. The working code should be easy to port once it's done.

My branch of Smoothie implements individual radius, angle, and arm length offsets for all three towers directly into the forward and inverse kinematics, and these are saved in /config-override when you type M500 so they will be remembered the next time. I am also working on some heuristic code to figure out the best possible adjustments. It seems you are further along than I am, so I'd love to see what you've done.

Also, what probe are you using?

[0110-m-p]

So I finally got my build platform "flat enough" with a max deviation (high-low) of 0.004". I optimized the calibration the best I could and ended up with a range of +0.0015/-0.0025" when the center is at zero. This is opposed to the more natural +0.000"/-0.004" that happens when using the X,Y,Z, center height = 0 calibration only.

It is odd the way I improved it though since I couldn't get any better with software changes or end stop screw settings. I ended up playing with where I put the glass build plate clamps and the size of clamps used. I used two small clamps on either size of the heated bed wiring next to the Z-tower, one large clamp directly inline with both the X and Y towers, and no clamps at all in between towers.

I still don't understand how the height can be correct based on X, Y, and Z-towers, but not based on the same points between the towers with equidistant build plate clamping. On my machine, I was consistently calibrating to zero on the towers and center and it would be 0.003", 0.005", and 0.012" low between all towers (calibrated tower rotations so that no spots were high). For some reason I also couldn't get the spot opposite the Z-tower to not be the lowest point. Just hate having to configure clamps on the bed to get it level rather than being able to get it correct in software.

[lordbinky]

I just replaced the hotend with microswitch that sat in the same holder.

What I want to avoid is implementing a least squares fit function for paraboloids on any of the firmwares, although smoothie would be my first choice if I were to do it there.

All I need are the Z-Height of 13 points on the bed to perform good enough fit, which I could get away with as long as the firmwares supported the necessary gcodes. Then I could leave it up to the user to format the corrections into the proper gcode format for that firmware. Leaving all the heavy coding (and computing) off of the controllers.

Now I'll give a brief rundown of my logic since it worked for me. Disclamer: All assumptions are based on my personal experience and may not reflect reality.

When I graph the result, it's easy to visually identify the next variable to adjust, which is where the heuristic comes in. Typically the weird Z0 behavior is due to the tower geometry changing an elliptic paraboloid which is what we expect (ie near perfect builds) into a hyperbolic paraboloid (those of us in the weird Z0 group). I also want to note that whenever we do not have a true elliptical paraboloid for our 'level' movement, we will get differences (stretching) in the X/Y on prints.

With the proper firmware offsets we can correct this difference and push it back toward an elliptic paraboloid where it is easier to improve the Z0 height behavior. I've found adjusting tower radius position is the most effective adjustment in manipulating the movement back into an elliptical form. After that adjusting the tower distances from the "center" manipulates the movement to place the min/max point to the center. Once you have an elliptical paraboloid for the Z0 heights with it's center matching the [0,0,0], it's the standard endstop and print radius adjustments.


tl;dr;

The goal is to turn bed profiles like this(hyperbolic paraboloid) :

Into this:

Where the standard bed leveling works out nicely.

[626Pilot]

Interesting, looks like we chose all the same test points for the general surface map. I have 13 of them and they're all in the same places!

I also devised a test, using different test points, called Y-line, where I draw a line from the Y-tower passing through the print center to the other side of the bed, and chop it up into an arbitrary number of segments. I then have the probe walk that line, probing each segment's endpoint. I also probe two points 10mm away from the line and perpendicular to it, based on the theory that the X tower will have more influence on the point to the left, and the Z tower will have more influence on the point to the right. It looks like this, with the probe touching where the dots are:

Code: Select all

(towards center)
                     \    .
                       \./
                      ./\    .     (closer to Z)
                          \./
                         ./ \    .
(closer to X)            \./
                             ./  (Y tower)     

Sure enough, the probing revealed some "saddling" behavior. The point on the Y-line would always be at a different elevation than the point closer to the X tower, and they would both be at a different elevation than the point closer to the Z tower. The data was definitely defining individual parabolic curves! The depths would start high or low, get better close to the center, and then go back to being high or low as it approached the opposite side of the print surface.

For the first test, I tried a simple gradient descent ((origin depth - point's depth) * factor) coupled with some logic to change the arm length. I found that this could be useful in correcting very small positioning errors, on the order of 1/4 mm or so, but in order to correct a deviation of 0.8mm, the logic had to crank up one of the arm lengths by 4mm! Further increases had diminishing returns, and I don't think anyone's arms are THAT far apart in length. So, the next things I will look at are tower angle (which I had much better results with before) and tower radius.

I would like to set up some heuristics that try various adjustments and pick the best ones. This worked well with my tower angle code. It would perform dozens of combinatorics, i.e. {x, y, z}, {x+1, y, z}, {x-1, y, z}, {x, y+1, z}, {x, y-1, z}, {x+1, y+1, z}, {x+1, y-1, z}, etc. I think I'd try tower angle and delta radius first (since they're likely to produce bigger changes) and then arm length to see if any further improvements can be wrung out.

That should give us the best possible corrections to the printer's notion of its physical geometry. That is the first thing to shoot for because it corrects positioning errors on all three axes. If the bed is still too "rough" after that, the surface can be depth-mapped and that can be used to correct for Z, although X and Y probably won't be helped. Smoothie has something called a "compensation transform" (see src/modules/robot/Robot.cpp) that appears to have been designed for that exact purpose.

[lordbinky]

When I did it manually I would do an endstop and delta radius before I'd process the 13 test points. There were times I would have missed the transformation into an elliptical paraboloid if I didn't. My process took a long time because I'd do the endstop and delta radius adjustments often, and I also didn't try to optimize those functions since I knew it'd converge after a few iterations eventually. I know I can put the paraboloid center somewhere off the printable area and have it stretched to where the test points return relatively close values. To me, this is a false positive calibration. It may be good enough to print with, but it isn't the optimal solution and slight changes to the printer's physical arrangement changes the leveling more than one would expect. This is a scenario I think leaves a person scratching their head as to what changed to throw everything off so much when it was 'calibrated' just a moment ago.

I gotta find my notes since I recorded the parameter changes each time with the graphs I made.

My methods didn't work without plotting results with curve fitting. The curve fitting covers up variables I don't want to deal with (other than errors introduced by movement consistency) and exaggerated the parts I was looking for, which is mainly where the center of the paraboloid would be and what towers to squish it back into a symmetrical shape.

With a focus on adjusting radial position: I only adjusted one tower at a time, when there were adjustments that needed two towers to be adjusted, things looked worse for a couple iterations.

For tower radial position, without checking my code, I believe I used the point opposite the tower, and then the nearest two perimeter points, adjusting the tower radial position until those three points were within a set variance. I'll go through and document better how I did things, I just gotta find my notes.

Still, I think when I went through this I roughly captured most of the odd bed leveling forms.

[lordbinky]

Sidenote: I'm printing a 3DR so I can put all my spare parts to use and hopefully speed up development if I do work on formalizing a true calibration.