Problems with Marlin Bed Leveling Compensaion G29

I apologize for not having my configuration.h file and g-code script with me here at work, but this problem has been troubling me and I have a moment to put this question out to the community...

I had been using automatic bed leveling compensation successfully for several months. I use the toggle with slide activator system made by "1013" for the Lulzbot Taz (here). I start each file with a custom g-code script which moves the x-carriage to the right in order to deploy the probe, run the G29 probing series, and then return to the X home position which then raises the probe.

I was using the "grid" function with 4 points, so it was probing 16 places in total. My initial settings were conservative, so the probe did not come within 30-40cm of the edges of the bed. I decided to expand the probing envelope by 10-15cm in each direction, and that's where my problems started.

My printer will move to the probe deployment position (X=273), deploy the probe, and then run the G29 probing series for all 16 points. At the end, it is supposed to move to X=14, then move slowly to X=0.1 in order to retract the probe. Instead, it moves first to X=25 +/-, and then to about x=10 +/-. This corresponds to the X offset, between probe and tip, that I have set at 9.4mm. When polling for position using M114, the printer reports that it is, in fact, at X=14 and X=.1, when it is clearly at X=25 and then X=10.

I noticed that others my have had problems with the "Z safe homing" definition, so I have commented it out and it has not changed this behavior. The ONLY thing that I had changed were the bed probing positions, and everything worked perfect up to that point. Changing the positions back to their original settings does not remedy the problem, so I really wonder what I may have done.

Does anyone know what might be going on here? I can upload the config.h and g-code in a few hours, but I was hoping that someone may know exactly where to look.

Edited 1 time(s). Last edit at 03/23/2015 04:24PM by stonedcoldskier.

Attached Configuration.h, G-Code shown below. Can anyone tell why this is happening? The printer thinks that it is probing points at X=40, when those points are acutally at about X=20.

M203 X50 Y50 Z4 ; set max rapid rates mm per sec
G91; set to incremental motion
G1 Z15.0 F3000; raise Z
G90; set to absolute motion
G28 X0 Y0; home X and Y axes
G1 X252 F3000; go to probe deployment position
G1 X268 F350; deploy probe
G1 X40 F3000; go to safe place
G28 Z0; Home Z axes
G29; probe bed
G1 Z15.0 F240; raise probe off bed
G1 X14 F3000; go to probe retract position
G1 X0.1 F500; retract probe
G1 X1 F350; move away from limit switch
M206 X0.0 Y0.0 Z0.0; offset home position for fine tuning

Edited 1 time(s). Last edit at 03/25/2015 09:35AM by stonedcoldskier.

X/Y-Offsets must be integers. Correct that first and test again.
[github.com]

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Tried that... saw another post about floating numbers and was hoping that would make the difference. It did not.

So I'm still fighting with this and have yet to find the solution. I did run my bed-leveling g-code line by line, and it seems that the positional awareness is somehow changed at the end of the G29 sequence. All points are probed where they should be, and the last probing point is X=40, Y=265. Without moving from that point, the X/Y offset is then applied, and polling with M114 reveals that the printer is now reporting its position as X=31.77, Y=178.00. My X offset is 8mm and Y is set at 86mm.

I understand that it is applying the offsets at the end of the G29 sequence, but why has it never done it in this fashion before? Also, why does it think that it's at X=31.77 when it is at X=40, and the offset is 8mm even? Same with the Y offset - 178mm + 86mm = 264, but it has not moved from Y=265...


If I move the X-Axis to the endstop and then poll with M114, it shows the current position as being X=-8. The Y-Axis does the same, and reports its position at -88.5.

I have tried reversing the sign of the offsets but, as predicted, the axis will then try to travel past the zero point, trigger the endstop, and then start skipping when it can go no further. .

Does anyone have any ideas?

SENDING:G29
Bed x: 40.00 y: 0.00 z: 13.34
Bed x: 230.00 y: 0.00 z: 11.73
Bed x: 230.00 y: 265.00 z: 10.47
Bed x: 40.00 y: 265.00 z: 14.63
Eqn coefficients: a: -0.02 b: 0.00 d: 14.58
planeNormal x: 0.02 y: -0.00 z: 1.00
echo:endstops hit: Y:0.00 Z:14.63
>>>M114
SENDING:M114
X:31.77 Y:178.00 Z:13.23 E:0.00 Count X: 31.97 Y:178.00 Z:12.76
>>>G1 Z15
SENDING:G1 Z15
>>>M114
SENDING:M114
X:31.77 Y:178.00 Z:15.00 E:0.00 Count X: 32.00 Y:178.00 Z:14.52
>>>G1 X14 F3000
SENDING:G1 X14 F3000
>>>M114
SENDING:M114
X:14.00 Y:178.00 Z:15.00 E:0.00 Count X: 14.23 Y:178.00 Z:14.79
>>>G1 X0.1 F350
SENDING:G1 X0.1 F350
>>>M114
SENDING:M114
X:0.10 Y:178.00 Z:15.00 E:0.00 Count X: 0.32 Y:178.00 Z:15.00
>>>M114
SENDING:M114
X:-7.60 Y:178.00 Z:15.00 E:0.00 Count X: -7.38 Y:178.00 Z:15.12
>>>M119
SENDING:M119
Reporting endstop status
x_min: open
x_max: open
y_min: open
y_max: open
z_min: open
z_max: open
>>>M114
SENDING:M114
X:-8.00 Y:178.00 Z:15.00 E:0.00 Count X: -7.78 Y:178.00 Z:15.13
>>>M119
SENDING:M119
Reporting endstop status
x_min: TRIGGERED
x_max: open
y_min: open
y_max: open
z_min: open
z_max: open
>>>M114
SENDING:M114
X:-8.00 Y:-22.00 Z:15.00 E:0.00 Count X: -7.78 Y:-22.00 Z:15.12
>>>M114
SENDING:M114
X:-8.00 Y:-88.00 Z:15.00 E:0.00 Count X: -7.78 Y:-88.00 Z:15.11
>>>M119
SENDING:M119
Reporting endstop status
x_min: TRIGGERED
x_max: open
y_min: open
y_max: open
z_min: open
z_max: open
>>>M119
SENDING:M119
Reporting endstop status
x_min: TRIGGERED
x_max: open
y_min: TRIGGERED
y_max: open
z_min: open
z_max: open
>>>M114
SENDING:M114
X:-8.00 Y:-88.50 Z:15.00 E:0.00 Count X: -7.78 Y:-88.50 Z:15.11

Simple, your bed is really uneven. Marlin calculates the complete transformation. Thinkmit is a dice and one side is your bed. When you turn it, every side will also move.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

You raise a very valid point, but I think there may be more at play. Part of the printer is unsupported where I have it, and the Ultem bed surface is not completely flat. In that run, I had to trigger the endstop manually at the last point because it was approaching a binder clip, but I have had this problem in other runs that only show about 1.2mm deviation (in X, and in Y) across the entire surface. It's certainly not perfect, but would it be so bad that the head is 8mm off in the X direction and 88.5mm off in the Y?

For anyone who happens upon this thread with a similar issue: It seems that Marlin Issue #1262 was the problem that I was experiencing. Updating to the latest development version has solved the problem.