DEV2: Bed leveling grid area wrong?
Hi,
yesterday I grabbed the version from github to restart working with my printer.
- I use EEPROM
- I use Repetier Server
In my configuration.h it is written:
#define LEVELING_METHOD 1
#define L_P1_X 15
#define L_P1_Y 280
#define L_P2_X 15
#define L_P2_Y 15
#define L_P3_X 280
#define L_P3_Y 15
#define GRID_SIZE 4
#define ENABLE_BUMP_CORRECTION 1 // CPU intensive, so only activate if required
#define BUMP_CORRECTION_START_DEGRADE 0.5 // Until this height we correct 100%
#define BUMP_CORRECTION_END_HEIGHT 2 // From this height on we do no correction
#define BUMP_LIMIT_TO 1.5 // Maximum allowed correction up/down, <= 0 off.
My bed is 300x300mm² large.
I cannot find zje L_P1_X ... values in the EEPROM.
I switch on my printer and enter G32 S2 by Repetier Server.
What I observe:
- Homing z,y,x as I wish.
- It moves down to the height where it should start the bed levelling
- It moves in x/y by the distances given in EEPROM "Z-probe X offset [mm]=-108" and "Z-probe Y offset [mm]=-10"
(everything as expected)
- It moves to the first point where it should measure the height of the bed.
Here it moves to (1|1) instead of (15|280). There might be a reason for starting in the liwer left edge, but this would be in my case (15|15). I cannot find any EEPROM setting which could override the setting from the config. Is that correct? The upper right point is (191|291) as I can read from the display during levelling.
- It moves along the different point of a 4x4 grid, but in fact it is not symmetric as expected. Total x-distance is smaller than total y-distance (where y is correct)
- After finishing it seems to home
- It moves to the y-center, but a bit left of the x-center (some cm).
- It looks like it's moving by "Z-probe X/Y offset" landing RIGHT of the x-center
- It probes
- It it is moving back by "Z-probe X/Y offset"
Bold ist what I do not understand.
LC_P... in the configuration.h, but they are totally different.
#define Z_PROBE_BORDER 1
with a bed of the 190x290 mm², but than the upper right point is calculated wrong.
In LevelingMethod.cpp I can find getBedRectangle xMin, xMax, yMin, YMax, which lets me assume, that it does not use the points mentioned above, but the bed dimensions.
In my EEPROM I have set:
Printer Bed X Min [mm] = 0
Printer Bed Y Min [mm] = 0
Printer Bed X Max [mm] = 280
Printer Bed Y Max [mm] = 280
If this is used, I would expect lower left: (1|1) upper right (279|279), which does not fit to the values (191|291).
1. Which settings are used for the grid area?
2. Why is it not connected to the bed area?
3. What am I doing wrong?
best regards
karl.ranseier
Comments
I switched to a 3x3 grid to see the positions clearer.
So after measuring the grid it moves to the most right position, if I see that correctly. That should be okay, but I have in mind from another discussion, that it should be in the center. That may have changed.
is not used for grid leveling. Grid leveling uses bed size reduced by Z_PROBE_BORDER. That area is further reduced by the z probe x/y offsets so it is guaranteed that all points in measured area are reachable with active z-probe.
For z max homing this function tests the z max length:
okay, that explains the changed area. But why is it reduced by the z probe x/y offsets ? I do have a maximum area of movement (x: -65...475) and an area of the heted bed (x: 0..300). Why reduce the measured area by the offset if it fits within the maximum reachable area?
In my opinion it should look like:
// calc min and max coordinates defining the area reachable by ZProbe
In my opinion it would even be better to land exactly on a point of the grid, otherwise there might be a bump which makes everthing wrong. Soemething like:
A reminder: after that procedure the z-position seems to be uncalibrated, which is indicated by the flashing ????.?? at z: on the display.
which sets xyMinMax to the values of the bed depending on the printer type active. For deltas it is e.g. taken from radius.
ZProbeHandler::xOffset() is just fetching the x offset value for z probe so it can be used to calculate reachable bed area.
So that part looks fine so far. Check probe offsets and what the printer type returns if it does not match expectations.
M360 returns bed position btw, so it is easy to check where that would be and it can be changed in eeprom.
Using bed center is in deed better also it must be a real difference to make it not work this way.
I saw that a test if distortion should be corrected is wrong since it would always be off where it gets added.
Would this version:
work better? It will not use grid align test because grid is only one leveling method. Others work differently so there is no rule to get the point. But normally it should be neglectible now that the distortion is added in height computation. Before it was not considered at all so much bigger.
If that works I will push it to github.
I think. Need to find out why or fix it after z probing.
By the way, does the last probing really make sense?
Here is an example how it may look like:
https://drive.google.com/file/d/12JL6I2AVE99le32W5GiJB2pm8FJXthvj/view?usp=sharing
This is again the same discussion like probing exactly on the grid.
If i understand the procedure correctly it would make more sense to probe the highest point in the grid than a centered point. Just a thought. I know that my print area is 161 mm high and my slicer is set to a maximum value of 159 mm. If the firmware is not doing it exactly, I think one can even skip the last probing.
In the special case of z max homing there is the extra code which we are more or less discussing about. What it does is to ensure that after homing z=0 is where you expect it. So it homes, goes down and measures the distance to bed vs. expected distance and corrects z max height with the difference. So yes it makes sense to do this, only question is if it is the best solution we can think of and if the error remaining is negligible.
We disable distortion correction before homing but autoleveling is active. Then we measure height that includes distortion. For correction we assume
so if we previously had distortion correction active it would correct that also as good as possible. The big slope in your example is already fixed by rotation so only the small distortion error gets fixed. Maximum error is max. difference between real bed and interpolated distortion values. Of course least at the grid measure points but negligible because printing also works. If it would not work you would increase grid count to reduce the error during print and then it also gets reduced here.
And thank you again for all of this support. I hope that my testing helps you, too, so both sides have a benefit.
Because I think "clapping hands" does not help enough, I just bought the Pro Version of Repetier-Server (even if the regular version is definetly enough for me).
xMin = RMath::max(Motion1::minPosOff[0] + ZProbeHandler::xOffset(), xMin);
minPosOff contains tool offsets and it makes no sense to add zprobe offset to that. It is either tool offset or z probe offset that is active and this must be measured from printer limits.
I'm still not 100% sure with the complete transformation. I have to redo offset handling since I think it adjust in the wrong coordinate system, also difference is normally quite low.
src\motion\LevelingMethod.cpp: In static member function 'static bool Leveling::measure(GCode*)':
src\motion\LevelingMethod.cpp:280:44: error: 'rotMin' was not declared in this scope
280 | xMin = RMath::max(Motion1::minPos[0] + rotMin[0] + ZProbeHandler::xOffset(), xMin);
| ^~~~~~
src\motion\LevelingMethod.cpp:281:44: error: 'rotMax' was not declared in this scope
281 | xMax = RMath::min(Motion1::maxPos[0] + rotMax[0] + ZProbeHandler::xOffset(), xMax);
| ^~~~~~