G30 single probe method?

[see3d]

The G30 is supposed to probe one point and generate the Z offset. The stock FW actually did 2 probes and generated two results. M4MPMD probed once and generated one result. M1.1.x is probing the bed 3 times for each call and generating one result. What algorithm is it using to turn 3 probes into one result? Sorry if I am asking a question that is already documented. I just did not see it. The answer does affect my alignment algorithm.

[see3d]

To expand on the question about the G30 method, below are 4 spreadsheet charts that show the effect of selecting different radii for setting the M666 and M665 bed alignment settings. The radii for tilt can be different than for bowl. The the example, tilt can be 25,37.5,50mm and the same for the bowl. The results are quite different depending on what the optimization goals are and how much of the bed is used. I would suggest that the goal should be the base alignment that produces the best overall result after the G29 mesh grid is applied. Also note that the M665 and the M666 values interact, so I tune both at the same time on each iteration. Also to get the least warping, all 3 arm plots should match each other as close as possible.

With M4MPMD, I was able to do a G30 with or without the mesh being applied to the returned values (it was included at my request). That way I could see how well the G29 algorithm worked (since the probe points for bed calibration are not the same as the G29 mesh grid). I don't see offhand how I can accomplish that with 1.1.x-119r11. A parameter flag for the G30 would be nice to have.

I have been working on getting my spreadsheet to be compatible with 1.1.x.

[aegean-odyssey]

I configured Marlin's probe behavior to average 3 taps. Here's the snippet from the Configuration.h file:

// The number of probes to perform at each point.                               
//   Set to 2 for a fast/slow probe, using the second probe result.             
//   Set to 3 or more for slow probes, averaging the results.                   
#define MULTIPLE_PROBING  3

I agree with you that the G30 code would be far more useful if it could report a "mesh-corrected" Z-value for the position being probed. Marlin though specifically disables the bed mesh correction for the G30 code, and I suspect it's done to avoid a slew of complications with the motion planner and whether or not there is a valid mesh to begin with. I think the safe approach here is to leave the probing process alone, but report the Z-value and a computed "mesh-corrected" Z-value (even though the mesh is disabled).

Also, the G29 code has its share of issues when it comes to editing a mesh, namely that there is no way to create a valid mesh without executing the G29 automatic bed leveling. This shortcoming complicates efforts to programmatically create a mesh. I'm planning to add a G29 C0 parameter that will create a zero (but valid) mesh. Once a valid mesh exists, the values can be easily edited. I think I'll be able to squeeze this into the firmware.

Finally, as you point out, the X,Y locations for the bed level mesh of the G29 code are fixed in a rectangular grid, while the G30 code allows measurements across the bed. The mesh of the G29 code should be adequate, but it may require meshes generated by another means to be "resampled" at the G29 code grid points.

[see3d]

I do recall that Mickey did have to jump through some hoops to get the mesh corrected values to work right. I believe that a computed mesh corrected value would be workable. Perhaps it could be a V parameter that makes it return the computed value. That way the value parsing would not be different, just the command for which value to return. The point being that the value returned has the offset of the computed mesh value between mesh grid points.

An alternative would be to always return first real followed by the mesh computed offset value. A zero mesh would always return a zero for the second value. Add the values together to get computed probe value. This might have more uses.

[aegean-odyssey]

I made changes, untested, but the code compiles and fits into the available flash memory! So, these are the things that are on deck:

• M205 Q<n> is now M205 B<n>
• temperature measurement uses 12-bit A/D readings (instead of 10-bit)
  • and smoothing via an IIR (infinite impulse response) filter
• G30 outputs Bed X: <n> Y: <n> Z: <n> Q: <n>
  • ; where Q: <n> is the mesh-corrected Z value (maybe should be just the correction value?)
  • ; (Q only displays if the mesh is available)
• a few fixes for G29.
  • G29 C0 creates a valid mesh of all zeros (F, B, L, R can also be used)
  • G29 C0 Z<n> creates a valid mesh of all <n> values (F, B, L, R can also be used)
  • G29 D (dryrun) really does not change the mesh now, and can be used to sample the bed
  • G29 J (without W) clears the mesh
  • G29 W I<n> J<n> U writes NaN in slot (I,J)
  • may also change for "G28 must be run first" requirement to only apply when G29 causes motion
• M503 now includes G29 F<n> B<n> L<n> R<n> C0 to show the mesh boundaries

[see3d]

Good list of changes! The G30 Q value could be either corrected or correction value. Leave it like you have it. One is just an addition or subtraction to get the other.

[mulcmu]

Changes look great!

Could another parameter be added to G29 to provide a ratio value to adjust L based on change to R to maintain dimensional accuracy from here? Defaulting to 0 would keep current functionality.

[see3d]

@mulcmu I was just going to suggest this for the whole M666,M665,G33,G29 calibration chain, but I will put into its own issue. It can be done outside the printer, and perhaps that is the better place, but if it is included, then it should be done right.

[PurpleHullPeas]

@mulcmu Glad to see that people other than me, @see3d , and @aegean-odyssey have read the tutorial! I think a ratio parameter would belong in G33 since that is the command for automatic M665/M666 calibration. G33 currently only adjusts M666 XYZ and M665 RXYZ (depending on options). Adding an option for ratio would add L to that list.

[aegean-odyssey]

Yes, G33 is the place for such things. Codes M665, M666, and M851 seem to do what they need to do. And if one accepts that a bilinear bed mesh correction is adequate to compensate for the shape of bed, G29 with upcoming changes should suffice as well.

That leaves G33. Currently I'm of the mind that Marlin's G33 algorithm should not regarded too sacredly, and that maybe with all of the experise here, it's time to replace it. Though G33 P1 V1 (aka G29 P0) should be retained.

Besides, I'm not sure if incremental changes to G33 are a win, or if such changes can be squeezed into the available program space.

I've set up a repository specifically to experiment with calibration strategies in the hopes to improve the automation calibration of the MPMD printer. So far, it holds a couple of scripts I used to generate alternate bed level meshes.

[PurpleHullPeas]

The adjustment ratio has been a part of community tutorials since around May 2018. If the adjustment ratio gets added to MPMD Marlin 1.1.X, then there would no longer to a need to run my Python script, which would be a great thing for user accessibility.

[aegean-odyssey]

@see3d, I'm looking over your spreadsheet plots (very nice, by the way), and it strikes me that firmware's dodgy probe compensation may be affecting your results. To disable the probe compensation, you can set the debug option, M111 S128. I'm sorry that this didn't occur to me sooner.

[aegean-odyssey]

@PurpleHullPeas, I've got a lot of catching up to do; you all have far more experience with the printer than I -- I'm trying to grasp and absorb it as quickly as I can. I don't want to supplant anyone's work, but I do want to distill whatever makes sense into polished firmware for the printer. I think a better G33 code will result from everybody's input.

[see3d]

@aegean-odyssey I feel I can speak for all of us who have spent many months or years trying to understand the details and even reverse engineer parts of the MPMD FW design. Your efforts and successes in bringing Marlin 1.1.x to the MPMD are greatly appreciated. We are here to take advantage of your work and hopefully provide you with what we have learned to make your job easier and more effective. The goal is to improve the user experience for many and upgrade the capabilities of the MPMD as much as practical.

I don't know if you have access to the MP Mini Delta Users Facebook group. I did not see your name in the users. That is where I have posted my extensive information about the MPMD.

I also have been working on updating my alignment spreadsheet to be compatible with Marlin 1.1.x. I have not released this to the general public yet, because it may be too technical for the average user. A spreadsheet is a very limited from a UI perspective. I use it right now as a research tool and to align my own machine. You are welcome to a link to the copy (google sheets), if you would like.

My plan was to write a user friendly stand alone app that would do all things MPMD from alignments to printing. I made a lot of progress on it, but had to put it aside for a while due to large demands on my time right now. It is written in LiveCode, which makes the UI a lot easier for me. It has a free cross platform open source community version. I have a paid Indy version that can compile stand alone apps for Windows, Mac OS, and Linux. It can even run on iOS and Android, which gave me the idea of using a cheap tablet as a very capable front panel with WIFI, sort of like the RPI ones. This all seems a bit out there for me at the moment, but one can dream... lol

[see3d]

@aegean-odyssey Interesting about the probe compensation. I was not aware of it. I will try that. Another reason for the wonky probe at one end may be due to hysteresis. I move to the tower position to start my G30 probes. Then I move in the opposite direction for the rest of the points. I have noticed that in printing a spiral from outside to inside, then spiraling back out again with a small offset, the two lines are different thickness. I can run more experiments on hysteresis.

[PurpleHullPeas]

@aegean-odyssey There is certainly a lot to be considered. However, as I understand it, just adding the K adjustment factor for M665 LR adjustment would bring G33's calibration algorithms up-to-date with the currently-released revision of the MPMD community documentation. The K factor is low-hanging fruit. Much of the other stuff covered in those documents are hardware mods/alignments, routine maintenance, troubleshooting, profiles, FAQ, etc.

Full M665 LRABCDEF calculations would be great, but I think it could take a while before we get there and even longer before we are convinced that it is ready for public release.

Regarding probe compensation, I think I am going to add the disable code into my Start Gcode. I got some really bad first layer behavior following a power cycle when I forgot to disable it again.

[see3d]

@aegean-odyssey

I'm looking over your spreadsheet plots (very nice, by the way), and it strikes me that firmware's dodgy probe compensation may be affecting your results. To disable the probe compensation, you can set the debug option, M111 S128. I'm sorry that this didn't occur to me sooner.

That is right! I was wondering why the basic shape of my bed plot changed from an S curve to a U curve when I changed from the Marlin4MPMD to Marlin 1.1.x. Here are two successive plots with the only change disabling the probe compensation (whatever that is). NOTE: There is a little variability in probe to probe. Variability is usually within +/-0.01mm on my machine.

[see3d]

This is what happens when I force the movement at the tower end to overshoot and come back, so that all probes on one tower are moving in the same direction. A 0.1mm hysteresis is evident in every tower. M111 S128 is also active. This is giving a better overall sense of the systematic error in the mechanics. Of course, I am not happy about this hysteresis error. It does not just affect the Z height. It also affects the X,Y position. I was noticing this variation in some small detailed mechanical parts I was printing for a customer. They were barely "good enough". I would like that they were better. I added springs to my arms to take out any ball joint play already. I am not sure where most of the play is found that causes this. I guess one thing I could do is probe one direction, then probe the opposite direction, then average the results of the opposite directions for my final Z. It probably will not change the shape, but might reduce the uncertainty a bit. The bed leveling might tweak in a bit more, but it will not help the actual printing. The only FW thing I could think of would be a hysteresis constant that added or subtracted the number at the appropriate places in the reverse kinematics. It would probably take some trial and error to see how much is in each section. If it is all in the vertical tower positions, then that is easy to isolate.

[see3d]

I modified my spreadsheet to have the M111 S128 and remove the hysteresis in the probe movements. Then I let the spreadsheet relevel the bed. This is the result. You can see that this is far superior to the starting completed alignment without these changes. It is actually good enough to print without a G29 mesh. With the mesh it should be great. This is on my machine which has had every mechanical alignment known done to it. The hysteresis is taken out of the bed leveling, but not the printing, so the G29 mesh would be needed for anything less than a 0.28mm first layer.
NOTE: The G29 moves in a way that has the hysteresis in the points. It would probably build a better mesh if all motion was in the same direction in the pattern ( left to right and bottom to top).

[see3d]

I am going to take an educated guess that the hysteresis is coming from the stepper/tower belt motion. Stepper motors do not have a strong detent in position and even less when micro-stepping. Friction from the idler pulley and carriage and even the ball joints could cause the stepper motor to come to rest a bit short of the detent position (which has zero holding torque at the detent). It could actually overshoot and not return all the way, or come up short depending of the mechanical dynamics and driver patterns. I am running the silent board with 256 micro-steps. The results may be different with a stock driver. It will take a different testbed arrangement to fully characterize the hysteresis of several printers to see if there is a consistent pattern.

I need to take more samples and chart the difference of Z height vs direction of movement. For instance come at a point from many different angles and see what happens. We have 3 towers and each can move in two directions to arrive at the same point, so 6 combinations of motion to get to a point depending on the starting position.

[aegean-odyssey]

Fixed in 119r12

G30 outputs Bed X: <n> Y: <n> Z: <n> Q: <n> ; where Q: <n> is the mesh-corrected Z value (Q only displays if the mesh is available)

[see3d]

@aegean-odyssey I don't know if I am doing something wrong, but I can not get the Q values to make sense on my spreadsheet chart. I changed my spreadsheet so that I could toggle between the G30 Z values and Q values. I aligned my bed with the G30 Z values without sensor probe compensation (first chart). Then I ran a G29 M500. The second chart shows the alignment getting worse instead of getting better with the mesh applied. When I did this with M4MPMD, the alignment would become almost perfect.

Here is the M503 at the time of these:

< 7:37:20 PM: echo: G21 ; (mm) < 7:37:20 PM: echo: M149 C ; (deg C) < 7:37:20 PM: echo:Filament settings: < 7:37:20 PM: echo: M200 D1.75 < 7:37:20 PM: echo: M200 D0 ; DISABLED < 7:37:20 PM: echo:Steps per mm: < 7:37:20 PM: echo: M92 X114.29 Y114.29 Z114.29 E100.00 < 7:37:20 PM: echo:Maximum feedrates (mm/s): < 7:37:20 PM: echo: M203 X150.00 Y150.00 Z150.00 E50.00 < 7:37:20 PM: echo:Maximum Acceleration (mm/s2): < 7:37:20 PM: echo: M201 X800 Y800 Z800 E10000 < 7:37:20 PM: echo:Acceleration (mm/s2): P R T < 7:37:20 PM: echo: M204 P3000.00 R3000.00 T3000.00 < 7:37:20 PM: echo:Advanced: B S T X Y Z E < 7:37:20 PM: echo: M205 B20000 S0.00 T0.00 X20.00 Y20.00 Z20.00 E5.00 < 7:37:20 PM: echo:Auto Bed Leveling: < 7:37:20 PM: echo: M420 S1 < 7:37:20 PM: echo: G29 L-55 R55 B-55 F55 C0 < 7:37:20 PM: echo: G29 W I0 J0 Z-0.02038 ; X-55.00 Y-55.00 < 7:37:20 PM: echo: G29 W I1 J0 Z-0.03779 ; X-37.00 Y-55.00 < 7:37:20 PM: echo: G29 W I2 J0 Z-0.05617 ; X-18.00 Y-55.00 < 7:37:20 PM: echo: G29 W I3 J0 Z0.38517 ; X0.00 Y-55.00 < 7:37:20 PM: echo: G29 W I4 J0 Z-0.09100 ; X18.00 Y-55.00 < 7:37:20 PM: echo: G29 W I5 J0 Z-0.10938 ; X37.00 Y-55.00 < 7:37:20 PM: echo: G29 W I6 J0 Z-0.12680 ; X55.00 Y-55.00 < 7:37:20 PM: echo: G29 W I0 J1 Z-0.01469 ; X-55.00 Y-37.00 < 7:37:20 PM: echo: G29 W I1 J1 Z0.71772 ; X-37.00 Y-37.00 < 7:37:20 PM: echo: G29 W I2 J1 Z0.50385 ; X-18.00 Y-37.00 < 7:37:20 PM: echo: G29 W I3 J1 Z0.46693 ; X0.00 Y-37.00 < 7:37:20 PM: echo: G29 W I4 J1 Z0.45512 ; X18.00 Y-37.00 < 7:37:20 PM: echo: G29 W I5 J1 Z0.65174 ; X37.00 Y-37.00 < 7:37:20 PM: echo: G29 W I6 J1 Z-0.12111 ; X55.00 Y-37.00 < 7:37:20 PM: echo: G29 W I0 J2 Z-0.00870 ; X-55.00 Y-18.00 < 7:37:20 PM: echo: G29 W I1 J2 Z0.55878 ; X-37.00 Y-18.00 < 7:37:20 PM: echo: G29 W I2 J2 Z0.48023 ; X-18.00 Y-18.00 < 7:37:20 PM: echo: G29 W I3 J2 Z0.53421 ; X0.00 Y-18.00 < 7:37:20 PM: echo: G29 W I4 J2 Z0.60084 ; X18.00 Y-18.00 < 7:37:20 PM: echo: G29 W I5 J2 Z0.67445 ; X37.00 Y-18.00 < 7:37:21 PM: echo: G29 W I6 J2 Z-0.11512 ; X55.00 Y-18.00 < 7:37:21 PM: echo: G29 W I0 J3 Z0.69744 ; X-55.00 Y0.00 < 7:37:21 PM: echo: G29 W I1 J3 Z0.59203 ; X-37.00 Y0.00 < 7:37:21 PM: echo: G29 W I2 J3 Z0.53412 ; X-18.00 Y0.00 < 7:37:21 PM: echo: G29 W I3 J3 Z0.52547 ; X0.00 Y0.00 < 7:37:21 PM: echo: G29 W I4 J3 Z0.52971 ; X18.00 Y0.00 < 7:37:21 PM: echo: G29 W I5 J3 Z0.53558 ; X37.00 Y0.00 < 7:37:21 PM: echo: G29 W I6 J3 Z0.73544 ; X55.00 Y0.00 < 7:37:21 PM: echo: G29 W I0 J4 Z0.00267 ; X-55.00 Y18.00 < 7:37:21 PM: echo: G29 W I1 J4 Z0.51165 ; X-37.00 Y18.00 < 7:37:21 PM: echo: G29 W I2 J4 Z0.54164 ; X-18.00 Y18.00 < 7:37:21 PM: echo: G29 W I3 J4 Z0.55449 ; X0.00 Y18.00 < 7:37:21 PM: echo: G29 W I4 J4 Z0.57992 ; X18.00 Y18.00 < 7:37:21 PM: echo: G29 W I5 J4 Z0.59227 ; X37.00 Y18.00 < 7:37:21 PM: echo: G29 W I6 J4 Z-0.10375 ; X55.00 Y18.00 < 7:37:21 PM: echo: G29 W I0 J5 Z0.00867 ; X-55.00 Y37.00 < 7:37:21 PM: echo: G29 W I1 J5 Z0.49506 ; X-37.00 Y37.00 < 7:37:21 PM: echo: G29 W I2 J5 Z0.56616 ; X-18.00 Y37.00 < 7:37:21 PM: echo: G29 W I3 J5 Z0.60851 ; X0.00 Y37.00 < 7:37:21 PM: echo: G29 W I4 J5 Z0.59685 ; X18.00 Y37.00 < 7:37:21 PM: echo: G29 W I5 J5 Z0.64399 ; X37.00 Y37.00 < 7:37:21 PM: echo: G29 W I6 J5 Z-0.09775 ; X55.00 Y37.00 < 7:37:21 PM: echo: G29 W I0 J6 Z0.01435 ; X-55.00 Y55.00 < 7:37:21 PM: echo: G29 W I1 J6 Z-0.00306 ; X-37.00 Y55.00 < 7:37:21 PM: echo: G29 W I2 J6 Z-0.02145 ; X-18.00 Y55.00 < 7:37:21 PM: echo: G29 W I3 J6 Z0.83876 ; X0.00 Y55.00 < 7:37:21 PM: echo: G29 W I4 J6 Z-0.05627 ; X18.00 Y55.00 < 7:37:21 PM: echo: G29 W I5 J6 Z-0.07466 ; X37.00 Y55.00 < 7:37:21 PM: echo: G29 W I6 J6 Z-0.09207 ; X55.00 Y55.00 < 7:37:21 PM: echo:Endstop adjustment: < 7:37:21 PM: echo: M666 X-0.51 Y-0.60 Z0.00 < 7:37:21 PM: echo:Delta settings: L R H S V XYZ ABC DEF < 7:37:21 PM: echo: M665 L122.42 R63.04 H122.42 S120.00 V25.00 X0.37 Y-0.24 Z-0.13 A1.05 B-0.73 C0.00 D0.51 E-0.25 F-0.13 < 7:37:21 PM: echo:PID settings: < 7:37:21 PM: echo: M301 P21.68 I1.59 D73.69 < 7:37:21 PM: echo: M304 P80.00 I12.71 D300.00 < 7:37:21 PM: echo:Z-Probe Offset (mm): < 7:37:21 PM: echo: M851 Z0.28 < 7:37:21 PM: echo:Linear Advance: < 7:37:21 PM: echo: M900 K2.00 < 7:37:21 PM: echo:Filament load/unload lengths: < 7:37:21 PM: echo: M603 L0.00 U100.00

[aegean-odyssey]

Do you think I have a sign error, that is, that I subtract (the error) where I should have added or vice-versa? I thought I followed what Marlin was doing, but I may have flubbed it.

[aegean-odyssey]

Also... with your process:

1. use G30 to create a 1st set of Z (and maybe Q) values;
2. run G29 to create a bed level mesh; and
3. use G30 to create a 2nd set of Z and Q values;

How do the 1st and 2nd sets of Z values compare? If the bed probing is repeatable, the two sets of numbers should be very close. Your 3-step process yields a wealth of information.

[see3d]

I have been trying to figure out if it was a sign error. It does not seem to be that. Some of the errors are + and some -. If you could make me a test version of 10A ACfan SM0001, but output Q as the mesh values, then it might be more clear. I could run a bunch of tests with that.

Doing the G30 probes, then the G29, then the G30 probe again, the G30 Z results did match close to each other.

A key point is that I am probing G30 inline with the radial direction of each arm movement. G29 is measuring a square grid and calculating a mesh. If the interpolation between the mesh grid and my radial grid do not track well, then that could be a source of error. That was the point of my request for having the value of the calculated mesh grid -- to make sure that the algorithms were tracking each other.

I also noted that the direction of X,Y movement can create a 0.1mm backlash error in the Z axis. The way the G29 moves between points will create a lot of this error. After I realized this, I changed my radial movement pattern to always move in the same direction for each point. In my case that only required overshooting then coming back at the point closest to each tower. This keeps all towers moving in a consistent direction. With a square probe pattern it may take a little more thought, because there is a more complicated motion between points.

Edit: I would be neat if the G29 probed a radial pattern for a delta. All the errors due to the arms track radially, so that would give the best mesh. It might not be an easy thing to do though.

[aegean-odyssey]

Thanks for the update. It's good to hear that the bed probing is more or less repeatable -- dodging an issue that would be very difficult to fix.

Here is how Q is computed currently (measured_z is Z):

const float r[3] = { xpos, ypos, 0 };
SERIAL_PROTOCOLPAIR_F(" Q: ", measured_z + bilinear_z_offset(r));

So if I've flipped the sign (and Z(x,y) is repeatable), I think the corrected-Q value is: Z - 2(Q - Z) => 3Z - 2Q => corrected-Q

I haven't spent much time figuring out exactly how Marlin's bed mesh interpolation works (the bilinear_z_offset(r) function above), but as I recall, it seemed to involve direction (of travel) somehow that struck me as an odd approach. The interpolation also includes the values of the mesh that aren't actually reachable by the printer. So it looks like I'll need to become much more familiar with how Marlin actually computes a correction using the bed mesh.

And, probing the bed radially (in essence using a polar coordinate system) is not so much of a problem -- the real issue is that such a mesh (in polar coordinates) would make computing a correction, Z_correction(x,y), (the bilinear_z_offset(r) function above) more complicated and compute-intensive.

I suppose, though, that the probed, "polar" mesh could be converted to a square mesh for interpolation purposes. So regardless of the probe pattern for the G29 code, it would generate a square mesh. Hmm, it would be interesting to see if adding the extra step would be a significant improvement. I'll see about putting together a way to test this idea.

[aegean-odyssey]

@see3d, how would you like to receive a one-off, do_not_distribute firmware? It's built, but I prefer not to make it generally accessible.

[see3d]

You can zip and send to me at see3d at writeme dot com

[aegean-odyssey]

It's away

[see3d]

I got it loaded and did the first run. I am going to have to go over the results with a fine tooth comb and make sure I did not do something wrong before I say anything stupid. The Q (error) pattern at first glance looks strangely symmetrical. The Z pattern is still consistent as before.

[see3d]

Here are the results. First graph is my G30 Z data on my aligned bed. Second chart is Q data. The TZ is of course the Y axis, so it lines up with a normal axis in the G29 grid. It does not look too bad if it were subtracted from TZ. The other two TX and TY don't look anything the Z probe data. All Q data is zero at center of bed:

[aegean-odyssey]

Thanks for your efforts. A little background: I haven't tampered with Marlin's bed mesh corrections; it's unadulterated from the Marlin 1.1.x branch. In the G29 code, I fixed round off bugs in the calculation of the grid positions (X, Y values) that caused the mesh to be off center. But Marlin code is essentially a gazillion "side-effects", so I'll double check to make sure that there's been no "unintended consequences" created.

From your charts, the corrections seem to be in the right range, but like you said, something isn't tracking. Z(x,y) from the G30 should match Z(x,y) of G29 they use the identical routine to probe the bed. Let me look into things. Thank you for scrutinizing the numbers. I'm sure we'll figure out what's going on.

[aegean-odyssey]

Btw, probe compensation is disabled? M111 S128 -- It doesn't affect the mesh correction calculation (Q), but it will change the probe measurement (Z).

[see3d]

Yes, I did the M111 S128. I do not know what probe compensation is doing, but it messed up my probing values. It seems like it should be the default to have it disabled. Perhaps you are using a bed tilt compensation? I actually have that in my spreadsheet for the stock drive (Clip Z Shim), but I am using different switches on my machine that do not have any bed tilt when probing so it is set to zero instead of 0.24mm.

Only the TZ in the above charts track about right. I will run another (manual) test to place the G30 over the same points as the G29 and see if they track there. If they do, then it is the interpolation that is at fault.

Marlin4MPMD has a mode that applies the mesh compensation to the G30 Z value. When I did my align - G29 - test plot with it, the compensation was very good, even though the G30 and G29 points were not the same. Perhaps Mickey did some other coding for the interpolation.

[see3d]

I did a G30 at every G29 point in the same order and did not get any better match between the Z and Q values. The Q (error), was on the same order of magnitude as the Z, but did not correlate. It was almost like the Q values were from a different X,Y coordinate than the Z. Is it possible that the G29 mesh calc has X and Y reversed or swapped or something?

EDIT: After sleeping on it, I tried the same thing again this morning. Now this test does correlate well. The only thing I can think of is lat night I had the machine go a bit crazy while doing one of the G29 tests. I had to power cycle it, and somehow the mesh got scrambled. So the Z and Q look similar (meaning that the Q (error), would have to be subtracted from the Z.

First chart is Z, second is Q taken at all the G29 points:

[see3d]

You mention: "I haven't spent much time figuring out exactly how Marlin's bed mesh interpolation works (the bilinear_z_offset(r) function above), but as I recall, it seemed to involve direction (of travel) somehow that struck me as an odd approach." That strikes me as there being some compensation for backlash. That is easy and obvious for a Cartesian machine, but might not track well for a delta machine (except for the Z direction). Perhaps it is some constant in the code that is set for each axis.

[see3d]

Results with the same setup as in the charts above (EDITED addition). Below charts are going back to the radial probe points. First chart is Z and second is Q (error). This looks similar to using the same G29 probe points. Subtracting the Q (error) from the Z would result is a better bed level. I am at a loss for why it looked bad before. I believe that I used the same sequence on them, but I must have made some mistake. So, the Q number in the version you sent me needs to be subtracted from the Z number to get the proper compensation. Is that what the released r112 is doing, or is it reversed?

Only the end points on the TY plot look like it would get worse with the compensation. That might be due to the extrapolation between the G29 square grid point near TY being at a radius of about 40mm and the TY end points being at 50mm. The error difference between Radius of 40mm and 50mm is non-linear.

[aegean-odyssey]

Oh my, foolish me; a careless mistake.

I checked how the correction was applied in Marlin -- Q was definitely added to Z. But, they're different Zs. More properly...

When Marlin uses the correction:

• Z_commanded + Q = Z_actual

So with G30, it's reversed:

• Z_{actual(measured)} - Q = Z_commanded

Again, a dumb mistake. I'll make the fix. Thank you for figuring it out.

[aegean-odyssey]

Hopefully really fixed this time in 119r13