Marlin: Head crash when using Bi-Linear Leveling

[Adirael]

I'm on 1.1.0 and I can't figure out how to get bed leveling to work. I'm using an IR probe as a Z_MIN endstop, it triggers when the head is 1.35mm away from the glass and using it as a Z endstop works fine, but when I send a G29 the head crashes into the bed when the print starts.

It should be something wrong with my config, since the head goes just 1.35mm too dep and my leveling grid looks alright.

These are my config values and the leveling grid I get

Bilinear Leveling Grid: 0 1 2 3 0 +0.043 +0.201 +0.289 +0.304 1 +0.069 +0.206 +0.298 +0.228 2 +0.091 +0.277 +0.372 +0.233 3 +0.135 +0.257 +0.258 +0.223

If I'm missing some relevant value just let me know
````

define X_PROBE_OFFSET_FROM_EXTRUDER 12 // X offset: -left +right [of the nozzle]

define Y_PROBE_OFFSET_FROM_EXTRUDER 0 // Y offset: -front +behind [the nozzle]

define Z_PROBE_OFFSET_FROM_EXTRUDER -1.35 // Z offset: -below +above [the nozzle]

define Z_CLEARANCE_DEPLOY_PROBE 0 // Z Clearance for Deploy/Stow

define Z_CLEARANCE_BETWEEN_PROBES 2 // Z Clearance between probe points

define X_MIN_POS 0

define Y_MIN_POS 0

define Z_MIN_POS 0

define X_MAX_POS 170

define Y_MAX_POS 180

define Z_MAX_POS 155

define AUTO_BED_LEVELING_BILINEAR

define GRID_MAX_POINTS_X 4

define GRID_MAX_POINTS_Y GRID_MAX_POINTS_X

define LEFT_PROBE_BED_POSITION 15

define RIGHT_PROBE_BED_POSITION 160

define FRONT_PROBE_BED_POSITION 20

define BACK_PROBE_BED_POSITION 160

````

Thanks for reading!

[Roxy-3D]

There is no way to put a Bi-Linear label on this any more. So I guess we change the title.

I wonder why the option to associate a Bi-Linear label with an issue needed to be removed.

[Tannoo]

If you get a leveling grid, how is it crashing? Do the other leveling modes do the same thing?

[Adirael]

I'm going to try the other modes and report back. It's odd, at first I thought the grid was wrong, but the offsets are too small for that to be the reason

[Adirael]

I did what @Tannoo suggested and went to a 3-Point configuration, it worked! I then went back to the Bi-Linear mode and it worked too.

It's odd, it may be related to the configuration saved in my EEPROM, I did reset it between test this time and now it seems to work all the time.

I'll close the issue and back my config up.

Thanks!!

[Roxy-3D]

If you did not do an M502 / M500 you were operating with random values in some very important variables....

[Adirael]

Clearly I was doing something very wrong. I've cleared EEPROM a lot of times (been trying to get the leveling working for a few weeks) but never worked.

Now I'm running without EEPROM. I'll dig it up again once I get a screen, for now it just works fine with EEPROM disabled.

Just did the best print ever with this printer, so I'm very happy.

Thank for the hard work!

[thinkyhead]

We can just use the general "homing/leveling" label for ABL / MBL leveling issues, and consider bilinear as just another ABL option. U.B.L. has its own label because it's been under active development and ought to be more visible in the issue list. Except for this new move-splitting-on-cartesian idea, I'm hoping MBL and ABL will continue to remain unchanged and dormant for a while. At least till we get the 1.2 branch going….

[Grogyan]

Well for the second time trying to do a print, once as UBL and now with Bilinear.
Even with resetting the EEPROM with M502 and M500, i've see the nozzle ram into the bed after G29 has executed.

[Grogyan]

I am wondering if the e/steps/mm is a floating point number might cause the issue

[thinkyhead]

@Grogyan Your e-steps value is probably fine. Decimal point or no decimal point, it is used as a float, and it should have a lot of digits to the right of the decimal point if it's accurately set.

• Are you seeing any slippage on your Z axis when the machine moves Z up or down at faster (homing/probing) speeds?

• Can you post a video showing this bed-ramming behavior?

• Please refresh our memory: Do you home Z with a probe?

• If you go step-by-step: G28 then check Z position with M114; G29 then check Z position with M114… Does the Z position appear correct at each step?

[Roxy-3D]

Well for the second time trying to do a print, once as UBL and now with Bilinear.

If the problem is happening with multiple bed leveling systems... Most likely, its not the leveling system causing the problems.

• Are you seeing any slippage on your Z axis when the machine moves Z up or down at faster (homing/probing) speeds?

I would slow down the Z moves. I would also check if I can power the Z-Motors at a higher level by turning up the step-stick power.

[Bob-the-Kuhn]

Does having positive numbers in the leveling grid mean anything? I'm used to seeing only negative numbers.

Maybe it just means that the Z offset is actually -1.0 rather than the current -1.35.

[Adirael]

@Bob-the-Kuhn I'm not really sure. When doing G28 and printing without doing a G29 it works fine with the -1.35.

Right now it also works fine doing a G29 and I can see the Z axis moving while printing to account for the bed

[Roxy-3D]

Does having positive numbers in the leveling grid mean anything? I'm used to seeing only negative numbers.

I've operated UBL in all three modes... All negative, all positive and a mix of numbers for mesh points.
If you have your Z_OFFSET_FROM_EXTRUDER set accurately... Most likely you will have a mix of numbers. But even in that case... If you look for the location that is the highest (or lowest) and set your home position to be there.... When you generate a mesh that point will be at 0.00 and everything else will be negative (or positive).

[Adirael]

About positive values on the leveling grid: My Z axis is inverted, my print head moves only on the X axis and my bed does the YZ movement. That could be the reason of a positive bed leveling grid, right?

[Roxy-3D]

About positive values on the leveling grid: My Z axis is inverted, my print head moves only on the X axis and my bed does the YZ movement. That could be the reason of a positive bed leveling grid, right?

It isn't hard to imagine a scenario where you home at one edge of the bed, and the bed is tilted up or down from that point. You could very easily construct a case with all positive or negative numbers in your grid.

[Grogyan]

Currently I am posting here, as I try to find the existing thread.
The Z isn't actually ramming into the bed, rather once G29 has completed and starts printing it would extrude non stop in one point and not move.
Ihad recently changed my extruder from a Greg's Style extruder to the E3D Titan, so when changing the e/steps per mm, it was changed from a whole number to a floating point number
From 920 e/steps/mm to 418.5 e/steps/mm in the EEPROM, as specified on their wiki, https://wiki.e3d-online.com/wiki/Titan_Assembly
Not changing the firmware 1.1.xBugFix as of last weekend, and changed only the e/steps/mm to a whole number of 419 e/steps/mm in the EEPROM did the printer print as normal.
Therefore, there is some sort of unsupported floating point.

Please ignore as I found the original thread relating to the exact problem #6636