Marlin: [1.1.x] UBL - G29 P1 - Crash
UBL - G29 P1 - Crash
Hi, I updated Marlin to the latest commit from bugfix-1.1.x (da9f3868d5) and with my usual setup (MKS Gen 1.4) the command "G29 P1" will produce a crash and a reset of the board.
Steps to Reproduce
To reproduce the crash just:
- Pull latest commit from bugfix-1.1.x (da9f3868d5)
- Copy and overwrite my attached configs
- G28
- G29 P1
Expected behavior: Start the typical mesh creation.
Actual behavior: There is a little movement along the x asix (3/4 mm) before the crash, just a little before the probe try to reach the bed.
Additional Information
My configuration is MKS Gen 1.4 + 5xTM2208 (the one on E0 is connected by UART) and there is an original BLTouch.
brisma
All 18 comments
I do not know if this is related with this build. When I homed the Z-axis, x and y went perfectly, then z would do the first probe slowly, then the second would slam down into the bed fast. I rolled back to an earlier from 4/27 and I do not have that issue. I'm on MKS Gen 1.4 and tM2130 x and y, tm2208 for z
pmbroth
on 1 May 2018
I'm not sure if this is true... But did your EEPROM get invalidated with the new firmware? Can you load the new firmware, and do a M502 and M500 to initialize the EEPROM? And then home the machine with the nozzle up 100mm so you can manually trigger the Z-Endstop and probe so you have lots of room to check for proper behavior.
I'm not sure this is true... But I think there may be an issue with the probing that is related to the EEPROM being invalidated. It would be good to hear what your results are.
Roxy-3D
on 1 May 2018
Yes, I already tried to reset the eeprom, restore default settings, moving up the z axis and many other tests... But when i send the G29 P1, before the creation of the first point of the mesh, when the probe start to moving down Marlin crash, and in the terminal I see some useless byte code (like 0x3B 0x0F etc etc)...
Tomorrow I will try to revert to the commit of one week ago to see if the problem disappear, just to be sure that it isn't a problem of my configuration, but i doubt, because the normal G28 is working correctly :/
brisma
on 1 May 2018
A reboot usually means there feedrate is too high for the AVR processor to keep up. What is your M503 S0 output (especially, your steps-per-mm and top feedrate values)?
Be sure to get the latest bugfix-1.1.x as things are always being adjusted.
thinkyhead
on 2 May 2018
I doubt is a problem related to feedrate, one week ago everything was working correctly with the same config :)
Anyway, the result of M503 S0 is:
Log Output
> Send: M503 S0
> Recv: G21 ; Units in mm
> Recv: M149 C ; Units in Celsius
> Recv:
> Recv: M200 D1.75
> Recv: M200 D0
> Recv: M92 X100.00 Y100.00 Z400.00 E418.50
> Recv: M203 X400.00 Y400.00 Z8.00 E50.00
> Recv: M201 X2000 Y2000 Z100 E10000
> Recv: M204 P800.00 R1000.00 T1000.00
> Recv: M205 S0.00 T0.00 B20000 X10.00 Y10.00 Z0.30 E5.00
> Recv: M206 X0.00 Y0.00 Z0.00
> Recv: M420 S0 Z10.00
> Recv: echo: G29 I999
> Recv: echo: M421 I0 J0 Z0.00
> Recv: echo: M421 I0 J1 Z0.00
> Recv: echo: M421 I0 J2 Z0.00
> Recv: echo: M421 I0 J3 Z0.00
> Recv: echo: M421 I0 J4 Z0.00
> Recv: echo: M421 I0 J5 Z0.00
> Recv: echo: M421 I0 J6 Z0.00
> Recv: echo: M421 I1 J0 Z0.00
> Recv: echo: M421 I1 J1 Z0.00
> Recv: echo: M421 I1 J2 Z0.00
> Recv: echo: M421 I1 J3 Z0.00
> Recv: echo: M421 I1 J4 Z0.00
> Recv: echo: M421 I1 J5 Z0.00
> Recv: echo: M421 I1 J6 Z0.00
> Recv: echo: M421 I2 J0 Z0.00
> Recv: echo: M421 I2 J1 Z0.00
> Recv: echo: M421 I2 J2 Z0.00
> Recv: echo: M421 I2 J3 Z0.00
> Recv: echo: M421 I2 J4 Z0.00
> Recv: echo: M421 I2 J5 Z0.00
> Recv: echo: M421 I2 J6 Z0.00
> Recv: echo: M421 I3 J0 Z0.00
> Recv: echo: M421 I3 J1 Z0.00
> Recv: echo: M421 I3 J2 Z0.00
> Recv: echo: M421 I3 J3 Z0.00
> Recv: echo: M421 I3 J4 Z0.00
> Recv: echo: M421 I3 J5 Z0.00
> Recv: echo: M421 I3 J6 Z0.00
> Recv: echo: M421 I4 J0 Z0.00
> Recv: echo: M421 I4 J1 Z0.00
> Recv: echo: M421 I4 J2 Z0.00
> Recv: echo: M421 I4 J3 Z0.00
> Recv: echo: M421 I4 J4 Z0.00
> Recv: echo: M421 I4 J5 Z0.00
> Recv: echo: M421 I4 J6 Z0.00
> Recv: echo: M421 I5 J0 Z0.00
> Recv: echo: M421 I5 J1 Z0.00
> Recv: echo: M421 I5 J2 Z0.00
> Recv: echo: M421 I5 J3 Z0.00
> Recv: echo: M421 I5 J4 Z0.00
> Recv: echo: M421 I5 J5 Z0.00
> Recv: echo: M421 I5 J6 Z0.00
> Recv: echo: M421 I6 J0 Z0.00
> Recv: echo: M421 I6 J1 Z0.00
> Recv: echo: M421 I6 J2 Z0.00
> Recv: echo: M421 I6 J3 Z0.00
> Recv: echo: M421 I6 J4 Z0.00
> Recv: echo: M421 I6 J5 Z0.00
> Recv: echo: M421 I6 J6 Z0.00
> Recv: M145 S0 H195 B60 F0
> Recv: M145 S1 H235 B80 F0
> Recv: M301 P30.46 I2.45 D94.83
> Recv: M304 P235.67 I45.66 D304.70
> Recv: M851 Z-1.85
> Recv: M906 T0 E800
> Recv:
> Recv: M900 K0.00
> Recv: ok
Buffer overrun issues won't crash the machine, but will only exhibit odd behavior. Generally speaking, reboot is only caused by the stepper ISR monopolizing the CPU, thus triggering the watchdog.
Please test today's bugfix code, and if you still get a crash then see if M203 Z4 before G29 P1 makes any difference. Then see what happens if you disable USE_WATCHDOG.
thinkyhead
on 3 May 2018
If low memory (and buffer and stack over runs) is suspected... M100 can help us detect that issue. I doubt that memory is so low we are seeing problems caused by that condition. But if we can't find another explanation, we should turn that on and see how much free memory you have.
Roxy-3D
on 3 May 2018
Same bug with the attached configuration and this is the output of my M100 command:
__brkval : 0x0000
__bss_end : 0x188E
start of free space : 0x188E
Stack Pointer : 0x2193
gallynero
on 12 Jun 2018
__brkval=0x0000 means nothing has been allocated yet. You should initialize the M100 command and then do a few commands... Especially some G29 commands like G29 T and G29 W. And then check and see what it says for free memory. It should actually give you a number of how much memory was free at the worst case point in time.
Roxy-3D
on 12 Jun 2018
In my case, the only solution was to decrease the number of grid points to 5 x 5.
brisma
on 12 Jun 2018
I get this log:
Log Output
- m100
SENDING:M100
__brkval : 0x0000
__bss_end : 0x188E
start of free space : 0x188E
Stack Pointer : 0x2193
Initializing free memory block.
2059 bytes of memory initialized.
- g29 p1
SENDING:G29 P1
echo:Home XYZ inic.
echo:busy: processing
Mesh invalidated. Probing mesh.
- m100
SENDING:M100
__brkval : 0x0000
__bss_end : 0x188E
start of free space : 0x188E
Stack Pointer : 0x2193
- g29 t
SENDING:G29 T
Bed Topography Report:
( -106,106) ( -106,106)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
14 | . . . . . . . . . . . . . . .
|
13 | . . . . . . . . . . . . . . .
|
12 | . . . . . . . . . . . . . . .
|
11 | . . . . . . . . . . . . . . .
|
10 | . . . . . . . . . . . . . . .
|
9 | . . . . . . . . . . . . . . .
|
8 | . . . . . . . . . . . . . . .
|
7 | . . . . . . . . . . . . . . .
|
6 | . . . . . . . . . . . . . . .
|
5 | . . . . . . . . . . . . . . .
|
4 | . . . . . . . . . . . . . . .
|
3 | . . . . . . . . . . . . . . .
|
2 | . . . . . . . . . . . . . . .
|
1 | . . . . . . . . . . . . . . .
|
0 |[ . ] . . . . . . . . . . . . . .
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
( -106,106) ( -106,106)
- m100
SENDING:M100
__brkval : 0x0000
__bss_end : 0x188E
start of free space : 0x188E
Stack Pointer : 0x2193
- g29 w
SENDING:G29 W
Unified Bed Leveling System v1.01 inactive.
Mesh 0 Loaded.
UBL object count: 1
planner.z_fade_height : 10.0000
of samples: 0
Mean Mesh Height: 0.000000
Standard Deviation: 0.000000
zprobe_zoffset: 0.0000000
MESH_MIN_X (-(116.0) + 10)=-106.00
MESH_MIN_Y (116.0 - (10))=106.00
MESH_MAX_X (-(116.0) + 10)=-106.00
MESH_MAX_Y (116.0 - (10))=106.00
GRID_MAX_POINTS_X 15
GRID_MAX_POINTS_Y 15
MESH_X_DIST 0.00
MESH_Y_DIST 0.00
X-Axis Mesh Points at: -106.000 -106.000 -106.000 -106.000 -106.000 -106.000 -106.000 -106.000 -106.000 -106.000 -106.000 -106.000 -106.000 -106.000 -106.000
Y-Axis Mesh Points at: 106.000 106.000 106.000 106.000 106.000 106.000 106.000 106.000 106.000 106.000 106.000 106.000 106.000 106.000 106.000
Kill pin on :41 state:1
Unified Bed Leveling sanity checks passed.
- m100
SENDING:M100
__brkval : 0x0000
__bss_end : 0x188E
start of free space : 0x188E
Stack Pointer : 0x2193
How to debug in real time for find this error ? I fix 2 error in another versión but Reading the code this is more complex.
Thanks
gallynero
on 12 Jun 2018
How to debug in real time for find this error ? I fix 2 error in another versión but Reading the code this is more complex.
The problem is within the scope of the probe_entire_mesh() function (within ubl_G29.cpp). I would start by adding a few lines of debug code within the loop that finds points that still needs to be probed and the actual call to the probe routine. Something like:
if (do_furthest)
location = find_furthest_invalid_mesh_point();
else
location = find_closest_mesh_point_of_type(INVALID, rx, ry, USE_PROBE_AS_REFERENCE, NULL);
if (location.x_index >= 0) { // mesh point found and is reachable by probe
const float rawx = mesh_index_to_xpos(location.x_index),
rawy = mesh_index_to_ypos(location.y_index);
SERIAL_PROTOCOLPAIR("Doing index ( ", location.x_index);
SERIAL_PROTOCOLPAIR(",", location.y_index);
SERIAL_PROTOCOLPAIR(") = (", rawx);
SERIAL_PROTOCOLPAIR(", ", rawy);
SERIAL_PROTOCOL(")\n");
const float measured_z = probe_pt(rawx, rawy, stow_probe ? PROBE_PT_STOW : PROBE_PT_RAISE, g29_verbose_level); // TODO: Needs error handling
z_values[location.x_index][location.y_index] = measured_z;
SERIAL_PROTOCOLPAIR("Back from Z-Probe. Value= ", measured_z);
SERIAL_PROTOCOL("\n");
}
SERIAL_FLUSH(); // Prevent host M105 buffer overrun.
} while (location.x_index >= 0 && --count);
When you get the values for when it fails... That will give some very helpful hints on what we are looking for.
Roxy-3D
on 13 Jun 2018
But looking at your:
MESH_X_DIST 0.00
MESH_Y_DIST 0.00
values.... These are clearly wrong. Something is causing these values to be 0.00 instead of being in the 14mm range.
MESH_X_DIST and MESH_Y_DIST are calculated in ubl.h. They are:
#define MESH_X_DIST (float(MESH_MAX_X - (MESH_MIN_X)) / float(GRID_MAX_POINTS_X - 1))
#define MESH_Y_DIST (float(MESH_MAX_Y - (MESH_MIN_Y)) / float(GRID_MAX_POINTS_Y - 1))
Your MESH_MAX_X and MESH_MIN_Y seem rather odd to me. I think the following define is probably wrong...
#define MESH_MIN_X (X_MIN_POS + MESH_INSET)
#define MESH_MIN_Y (X_MAX_POS - (MESH_INSET))
#define MESH_MAX_X (Y_MIN_POS + MESH_INSET)
#define MESH_MAX_Y (Y_MAX_POS - (MESH_INSET))
You seem to be using X_MAX_POS to define MESH_MIN_Y and Y_MIN_POS to define MESH_MAX_X which seems odd even for a delta!
gloomyandy
on 13 Jun 2018
@gallynero — Try this:
#define MESH_MIN_X (X_MIN_POS + MESH_INSET)
#define MESH_MAX_X (X_MAX_POS - (MESH_INSET))
#define MESH_MIN_Y (Y_MIN_POS + MESH_INSET)
#define MESH_MAX_Y (Y_MAX_POS - (MESH_INSET))
Thanks @Roxy-3D , @gloomyandy & @thinkyhead i try this solutions and comment the results.
gallynero
on 13 Jun 2018
@thinkyhead work perfect with yours solution, i set 15 point and work too.
Sometimes the trees do not let see the forest.
Thank you @Roxy-3D , @gloomyandy & @thinkyhead for yours help and work.
gallynero
on 14 Jun 2018
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
![github-actions[bot] picture](https://avatars2.githubusercontent.com/in/15368?v=4&s=40)
github-actions[bot]
on 19 Aug 2020
Related issues
Glod76
·
3Comments
Tamonir
·
3Comments
esenapaj
·
3Comments
Anion-anion
·
3Comments
Bobsta6
·
3Comments
Most helpful comment
@gallynero — Try this: