Marlin 2.0.x UBL Not populating last column of offsets

What is the problem?
When running the UBL steps G29 P3 T is dropping off the last column of offset data.
What did you already try to solve it?
Update Marling to latest 2.0.x bugfix branch.
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, Unrelated information: OctoPrint 0.13.9, OctoPi 0.14.0
Related information: Marlin 2.0.x bugfix.

This is the reporting data, notice the "." character in the last column.

Send: G29 P3 T
Recv: 
Recv: Bed Topography Report:
Recv: 
Recv:     ( 10,290)                                                              (290,290)
Recv:         0       1       2       3       4       5       6       7       8       9
Recv:  9 | -0.144  -0.286  -0.209  -0.183  -0.118  -0.084  -0.007  +0.038  +0.084    .
Recv:    |
Recv:  8 | -0.013  -0.154  -0.173  -0.192  -0.216  -0.148  -0.160  +0.066  +0.292    .
Recv:    |
Recv:  7 | +0.010  -0.003  -0.130  -0.294  -0.170  -0.164  +0.063  -0.094  -0.094    .
Recv:    |
Recv:  6 | +0.065  -0.001  -0.183  -0.149  -0.205  -0.245  +0.088  +0.041  +0.041    .
Recv:    |
Recv:  5 | +0.145  +0.013  -0.074  -0.259  -0.188  +0.011  -0.029  +0.165  +0.359    .
Recv:    |
Recv:  4 | +0.378  +0.060  +0.047  -0.050  -0.073  -0.146 [+0.006] +0.185  +0.363    .
Recv:    |
Recv:  3 | +0.354  +0.311  +0.093  -0.009  +0.058  +0.093  +0.079  +0.214  +0.349    .
Recv:    |
Recv:  2 | +0.454  +0.301  +0.299  +0.235  +0.244  +0.192  +0.196  +0.306  +0.417    .
Recv:    |
Recv:  1 | +0.477  +0.430  +0.426  +0.422  +0.239  +0.328  +0.319  +0.358  +0.398    .
Recv:    |
Recv:  0 | +0.542  +0.442  +0.346  +0.471  +0.499  +0.452  +0.391  +0.452  +0.513    .
Recv:         0       1       2       3       4       5       6       7       8       9
Recv:     ( 10, 10)                                                              (290, 10)
Recv: 
Recv: ok P15 B3

Anybody else here using Marlin UBL that may have any ideas? About to start searching that repositories issues now.

For it's obviously a Marlin issue, most information you may get at Marlin.
Especially it's a development version...

Looks like line 239 is what's responsible for printing the period and the underlying cause is NaN.

Yeah, I know. That's where I've started looking. I actually think the issue is related to max_software_endstops and probe offsets. The x max enstop is causing the head not to move to a position where the probe can get to because of it's x offset. Looking for the option to extend that now.

1 Like

And your X_BED_SIZE is correct in configuration.h?

It happened to me also. In my case it has happened because the probe could not reach that points, but issuing a G29 P2, the values were populated automatically based on the points measured. In my case, worked.

I´ve found this different behavior was introduced in Marlin 1.1.9.

Another thing I´ve done, is using G29 P4 to recalibrate all points manually. I use a probe that senses the aluminum of bed, but I nave a surface above it that does not copy the aluminum irregularities with perfection.

So with a combination of increasing my X_MAX_POS and my MESH_INSET I was able to get it to work right. I might also have been able to just uncomment and set the MESH_MAX_X value to X_MAX_POS + X_PROBE_OFFSET_FROM_EXTRUDER. I might go back and try that to reduce the MESH_INSET back down to get as much bed measuring as possible.

Thanks for the G29 P2 tip, if it comes up again I'll give that a try.

Yep, I found that setting the MESH_MAX_X value to (+/- depending on probe offset direction) X_PROBE_OFFSET_FROM_EXTRUDER gives me the largest probing area and I was able to reduce the MESH_INSET value back down to 10 for the other perimeters.

2 Likes