Interaction between mesh bed compensation and homing
-
There is a report in another thread that if you repeatedly home and then run G29, the height map Z offset increases each time. So I decided it was time to review the interaction between bed compensation and homing. In particular, when the Z height gets set as a result of the homing process, should the firmware:
(a ) set the height in user coordinates, then apply bed compensation to calculate the machine coordinates; or
(b) set the height in machine coordinates, then apply inverse bed compensation to calculate the user coordinates?
In either case, if the homing process homes to somewhere other than Z=0 (e.g. the trigger height of a Z probe), and bed compensation taper is enabled, should the tapered compensation or the full compensation be applied?
It turns out that this is not simple because there are several different cases:
1. Z homing (or just running G30) using the same Z probe that is used for G29 probing. The XY position used for Z homing may or may not coincide with a G29 probe point.
2. Z homing using an endstop switch (with or without a G92 command following the homing move). In most printer designs, the XY position of the head could be anywhere.
3. Z homing on a delta where all 3 endstop switches are triggered and the height is set to the homed height as found by auto calibration. The head is approximately centred, but auto calibration may have left a small height error at bed centre, which G29 may correct for.
I think I know at least some of the answers, but I'd like to hear your views before I make any changes to the behaviour.
-
This certainly is a complex issue.
In the case of my printer which is a converted FFCP Cartesian setup I would expect the following to apply.
Home using the Z-Probe to obtain a reference point with the known offset. Let's say the nozzle is 0.25 mm off the bed when the Z-Probe fires. We then know our reference distance.
The bed probing should always assume Z = 0 so it ends up with positive and negative numbers.
During moves the calculated positive and negative offsets should be applied to the Z-Probe offset that was obtained during homing.
In the case of grid compensation (and maybe more) the number that's closest to the homing reference could be found and then removed from all the other probe points creating a zero referenced map. Having the zero referenced map makes it easy to apply that map to the homing reference during moves. This also lets you easily change the reference height and still have a completely valid map.
Edit: Finding the probe point closest to Zero making that zero and removing it from all the other points makes more sense I guess then caring about the original reference. This still gives you a zero based map.
Just my thoughts.
Jeff
-
Still thinking on this issue.
Going back to my first post you really shouldn't care about the z offset at all for the compensation map. You should only care about the differentials from zero. So I'm going to stand behind my concept of probing, finding the value closest to zero , making that value zero and offsetting the rest of the probe points by that difference. Once a zero based map is obtained the Z offset should be applied during moves and not have anything at all to do with the compensation map.
Jeff
-
From my point of view only the following makes sense: Set the absolute machine position if one or more axes are being homed (via G1 S1/G30/G92) and then apply user-defined full compensation (if any) on-top to calculate the new user position (b). When G29/G30 S/G32 is invoked for calibration, set the new compensation parameters, recalculate the user position and apply the new parameters when incoming moves are processed. If G92 is called outside homing macros, it should set the user position to the specified value, so the machine position would have to be recalculated by taking the inverse of the compensation parameters (a ). Either way G1 S1 is rather special but I'm wondering if we need to support that outside the homing macros anyway.
When an axis is being homed, I'd expect the firmware's machine position points at the defined minimum/maximum/Z trigger height. If compensation is used (e.g. via M556/G29/G32), those parameters should be used on-top and work independently.
I'm pretty sure such a design would cover all three cases and resolve the current G29 offset problem, but I hope I'm not missing any essential details here. Comments?
-
I think if any form of compensation map is treated as a separate entity and always an offset (zero based) it could then be used to adjust and calculate any moves with any other form of offset or compensation being factored in. If you keep it zero based you could in theory apply multiple forms of compensation as needed. The compensation should never include any other offsets when being stored, those offsets should be factored in only during moves.
Jeff
-
I should probably explain myself a bit more.
If you probe 50 points or 5, or 3, etc. and level shift all the points by the point that is closest to zero you now have a zero referenced based map that can be used during time of move with any other offsets. By doing this level shift you eliminate any possible error introduced by a z offset. It becomes an offset map and not a movement map.
Jeff
-
However it's solved I hope there will be some good description of it. I'm not sure how things affect each other and what the routine should be before a print with the current setup.. I'd opt for a KISS solution!
