Z-probe and bed leveling issues (with workarounds and details) - request for comments

[osnwt]

I was trying to use bed leveling and found few issues as well as many others. I thought where to discuss them: forum or issue tracker. I decided to be here because it is more tech-oriented place, and my post is not for end-users. I ask to discuss them first here, then we can split them into separate tasks to fix if necessary.

To Repetier: maybe makes sense to close old (and often answered) issues here?

Platform: classic Mendel-type printer (Zonestar P802M, Melzi)
Z-probe: mechanical end-stop placed on the servo lever. Switching position - 7mm under hotend tip (when active, servo down).

Issues:

1. Invalid Z-probe sequence for classic printers.

Expected:
- If current height is below (Z_PROBE_HEIGHT + Z_PROBE_BED_DISTANCE) - go to that (ensure that active probe will not hit the bed).
- Activate the Z-probe using Z-probe start script (move servo down, previous step ensures that it is safe).
- Move to the first probe point and continue probing.
- After all points measured deactivate the probe using end script (move servo up).

Real:
- if current height is known and upper than (Z_PROBE_HEIGHT + Z_PROBE_BED_DISTANCE) - it goes down to it. If current height is below that (say, Z=0) - it does NOT go up and hits the bed activating the probe.
- Activate the Z-probe using Z-probe start script, the rest is ok.

Comments:
- It looks like current implementation is hard-coded for Delta printers that always homed to the top.
It does not work safely for classic printers with active Z-probe that is below hotend tip when active.
- Actually, it should first move to the 1st Z-probe point, then activate the servo (run script). But
might be other scenarios, so maybe 2 start scripts are necessary: initial and when over the bed. See next issues.

Workaround:
- I do relative Z10 move in Z-probe start script. That works, but makes unnecessary z-moves when we already have a plane.

2. When printer is powered up, it assumes X=Y=Z=0. That is wrong, and if G32 is activated, it will probe in a random bed place.

Workaround:
- I do G28 in Z-probe start script. It ensures homing, but makes unnecessary move if G29 is triggered or if we already homed.

Solution:
- keep trace of X/Y/Z homing (always good to know if we did at least one home for the axis).
- On G32/G29 ensure we homed by X/Y if were not yet. May be optionally.

3. For printers with X/Y home position not over the bed doing G29 will Z-probe in that place - out of bed - and crash.

Workaround:
- None, do not G29 when not safe.

Solution:
- Do not do Z-probe when not over the bed. This implies we know if we were homed (see above).

4. If you have highly uneven bed, assuming we use bed leveling, doing X-home does not change Z position. It may crash into the bed.

Same for the Y. G1 X0 takes into account the bed plane, but homing seems to not.

Solution:
- have no idea, really. But I found that hard way doing tests with uneven bed.

5. Invalid bed plane calculation.

Details:
- I did tests having left bed side (X=0) 10mm higher then right size (X=200). I do Z-probe using 3 points method, and it works. After that I do G1 Z5 (absolute), but I really have Z around 2mm only. Going Z0 crashes into the bed.
- Going to corners with X=0..max, Y=0..max seems that plane was calculated (Z distance between hotend tip and the bed keeps the same during movement). But the value of that Z distance seems to be wrong. And doing G1 Z0 crashes into the bed.
- Doing this on an even bed has more or less correct Z distances.

Comments:
- I do not know what that means. One guess might be that it's due to Z-probe X/Y offset of hotend. But even hand-moving X position to the right to the X offset value (where bed is lower) does not fix the distance correctly.

Solutions:
- Probably the plane calculation should be rechecked and fixed. Did not look into the math, sorry.

6. Invalid bed plane calculation (another issue).

Details:
- Doing bed autoleveling results that on the right (P2) I have slightly different Z distance. I thought that was my Z-probe issues and was going to fix it for that spot. But after I read on forum that many users found the same, I now thinks that is a plane calculation or compensation issue. I have quite repeatable Z-probe results, so do not believe that is a measuring error. Rather compensation error.

Solutions:
- Probably the same issue of plane calculation. Should be solved with the previous issue.

Conclusion

Bed leveling had major rewrite recenly. Still, it is not usable at all and needs more fixes. I am ok to test/help with it. But since I have no delta printers and not in a business of reprap firmware, my help might be limited to verification and suggestion.