Unified Bed Leveling - Bug in Marlin 1.1.8?

hi,

I recently switched from bilinear to UBL - hoping to speed up my prints because I can store the mesh.

The mesh creation works fine - so logs below - but I cant print a G26 pattern to verifiy the mesh. It always prints only a few circles and the Z-axis is going up until it crashes to the frame - that is not what I was looking for

Also repeated the process with an erased eeprom - some thing.

Any ideas where the problem is?

I am using a DIY MK2S with fixed probe - worked like a charm with biilinear bed levelling- firmware is marlin 1.1.8

Here is my mesh output:

Send: G29 W
Recv: echo:Home XYZ first
Recv: Unified Bed Leveling System v1.01 active.
Recv: Mesh 1 Loaded.
Recv: UBL object count: 1
Recv: planner.z_fade_height : 10.0000
Recv: # of samples: 100
Recv: Mean Mesh Height: -0.127595
Recv: Standard Deviation: 0.169882
Recv: zprobe_zoffset: -0.3525000
Recv: MESH_MIN_X ((((((210) / 2) - (210) / 2) + 1)>(0 + +23)?((((210) / 2) - (210) / 2) + 1)0 + +23)))=23
Recv: MESH_MIN_Y ((((((210) / 2) - (210) / 2) + 1)>(-10 + +9)?((((210) / 2) - (210) / 2) + 1)-10 + +9)))=1
Recv: MESH_MAX_X ((((((210) / 2) + (210) / 2) - (1))<(210 + +23)?((((210) / 2) + (210) / 2) - (1))210 + +23)))=209
Recv: MESH_MAX_Y ((((((210) / 2) + (210) / 2) - (1))<(200 + +9)?((((210) / 2) + (210) / 2) - (1))200 + +9)))=209
Recv: GRID_MAX_POINTS_X 10
Recv: GRID_MAX_POINTS_Y 10
Recv: MESH_X_DIST 20.67
Recv: MESH_Y_DIST 23.11
Recv: X-Axis Mesh Points at: 23.000 43.667 64.333 85.000 105.667 126.333 147.000 167.667 188.333 209.000
Recv: Y-Axis Mesh Points at: 1.000 24.111 47.222 70.333 93.444 116.556 139.667 162.778 185.889 209.000
Recv: Kill pin on :41 state:1
Recv:
Recv: Unified Bed Leveling sanity checks passed.
Recv: ok
[...]
Send: G29 T
Recv: echo:Home XYZ first
Recv:
Recv: Bed Topography Report:
Recv:
Recv: (0,9) (9,9)
Recv: (23,209) (209,209)
Recv: -0.297 -0.239 -0.227 -0.214 -0.224 -0.262 -0.325 -0.411 -0.513 -0.609
Recv:
Recv: -0.292 -0.217 -0.169 -0.157 -0.160 -0.188 -0.241 -0.292 -0.367 -0.471
Recv:
Recv: -0.245 -0.178 -0.128 -0.103 -0.101 -0.110 -0.151 -0.187 -0.231 -0.305
Recv:
Recv: -0.237 -0.165 -0.135 -0.101 -0.085 -0.059 T:78.68 /0.00 B:58.97 /0.00 @:0 B@:0
Recv: -0.070 -0.094 -0.142 -0.202
Recv:
Recv: -0.255 -0.197 -0.147 -0.108 -0.062 -0.045 -0.019 -0.031 -0.054 -0.094
Recv:
Recv: -0.286 -0.210 -0.153 -0.113 -0.053 -0.006 0.028 0.026 0.018 -0.012
Recv:
Recv: -0.319 -0.235 -0.156 -0.087 -0.033 0.033 0.068 0.081 0.081 0.049
Recv:
Recv: -0.375 -0.253 -0.157 -0.078 -0.002 0.059 0.096 0.106 0.140 0.114
Recv:
Recv: -0.455 -0.312 -0.186 -0.086 -0.002 0.068 0.110 0.155 0.169 0.169
Recv:
Recv: [-0.560] -0.440 -0.261 -0.150 -0.080 0.040 0.102 0.163 0.185 0.179
Recv: (23,1) (209,1)
Recv: (0,0) (9,0)
Recv: ok


and this is the G26 pattern... after this few circles the print suddenly stops and the Z-axis move upwards until I have to reset the printer, or the Z-axis will hit the frame.



any advice will be helpful.
thx

Edited 2 time(s). Last edit at 05/14/2018 09:19AM by coolduke.

I'm having exactly the same problem, same scenario. After googling a lot yesterday evening I found that its to do with the printer printing outside of its mesh I believe and causes a bug where the z-axis just continues to rise.
I found that they have addressed the issue though and has been included in a 1.1.xx bugfix on GitHub. I have tried to install the bugfix FW but now for some reason, I'm having trouble where my z-axis won't home at all now and just continues to raise whenever i go to home all axis, which is weird because I can control the z-axis and it moves in the right direction but when I have it to home it just continues to rise.

I'll be sure to post back if I find anything and would appreciate if you do the same as I wasted a whole evening yesterday trying to solve this and has really frustrated me. Ha

Anyway, try the bug fix, that should address your issue.

very interesting...

could you provide a github link to this issue?

thx

1.1.xxBugfix here

Under the recent changes, you can see

"Added EXTRAPOLATE_BEYOND_GRID option for mesh-based leveling"

which I think is related to our problem. I think I just found the problem I was having with homing the z-axis and so I'm about to upload the new firmware to test it out.

I'm running the above firmware and going through the test print now without any problems. Seems like the issue has been resolved.

Although it looks like the test print is going need a lot of tweaking. I was expecting there to be minimal editing of the mesh since Its auto probed with the bltouch. Don't understand how it created such a bad mesh considering BILINEAR worked so well previously. Very strange, can you post whether you see the same @coolduke
by what i've seen so far it looks like bilinear seems more practical but i'll continue with UBL for this evening and try some prints.

@nicknonsense: thx for the update - I am not quite sure, if should go with the 1.1.xx bugfix version, because it is not considered stable... or if I just cancel my UBL endeavour and go straight back to BILINEAR, which worked quite well.

the only downside of BILINEAR is the waiting time for the process, because it is done before every print - and if you probe 4x4 with double probes - this just take while...

is there a way to store the BILINEAR "mesh" in the eeprom - similar to UBL?

thx

I can understand not going down the bugfix route. Just so you know I run the full test print yesterday without any problems so if you were tempted to continue using UBL then that FW is going work great for you. I have been reading that the z jump is caused by the print going outside of the mesh, if you can expand the mesh so the printer doesn't go outside of it you won't encounter the bug from my understanding, Some were mentioning zero-ing the "Inset" values within the firmware if you are interested in playing around with that.

I think I'm going stick to BILINEAR personally, UBL is just too time-consuming to set up and get perfect for me, I understand it a fully comprehensive toolset for auto leveling but the 2 to 3 minutes for BILINEAR to do its job before each print is fine for me and its basically a plug and plug systems regarding setup.

I haven't come across any way to store the BILINEAR mesh I'm afraid.


GoodLuck @coolduke, hopefully, you'll have a less frustrating time with ubl as I have.


oh and I come across this which was interesting too, allowing you to map the topography of your probed bed, allowing you to visualize the mesh
LINK

Edited 2 time(s). Last edit at 05/15/2018 06:34AM by NickNonsense.

hi

thx for your honest feedback.

Are do doing double or tripple probes with bilinear - or just simple one time probes.

On my 220x220 printbed I did 4x4 tripple probes, which took aprox 5-8 minutes... and that is far too long from my point of view.

thats the reason why I tried UBL in the first place

none the less I will stick to linear for now but will reduce my 4x4 matrix to single probes... which should work fine and save me some time.

best!

@mesh visualizer: I use octoprint on an orange pi.... there is a nice plugin which shows you the mesh... nice and easy!

Quote
NickNonsense
I can understand not going down the bugfix route.

The bugfix releases are the most 'correct'. But they change often and fast. So random issues do show up there. With that said, the bugfix releases are 'better' than the 'stable' releases.

If you need something that isnt going to change because you have 5 printers and want them all running the same firmware, the 'stable' release is a good choice. But in general, bugfix is better.

I just tried the 1.1.bugfix - changed the configuration.h and adv_conf.h - successfully compiled and uploaded the fw-verison... but suddenly my full-gfx-LCD (reprap discount 12864) didn't worked properly.. only showed some artefacts.

thats my story with 1.1.bugfix so now back to bilinar MBL.

@roxy: is this a known problem with the LCD?

thx

Edited 1 time(s). Last edit at 05/16/2018 06:42AM by coolduke.

Strange I'm running the same LCD display without any issues. Not sure what you'll need to look at to resolve that.

I'm using UBL, too.
Works fine, you don't need G26, it's only to verify your mesh.
If I'm using G26 C P5.0 F1.75, it prints 10 patterns along the x-axis in the first y-line (got 11x11 grid, 40x42cm bed),
one at the end of x in second y-line and move z until mechanic border after it.

But my UBL-Mesh works fine, even without it.
Almost better as bilinear leveling every print.

Perhaps someone can tell me the location of the code for G26.

Quote
rc-snail

But my UBL-Mesh works fine, even without it.
Almost better as bilinear leveling every print.

To make Bed Leveling more interesting,

I have been saving bed leveling data for over a year starting with Linear Bed Leveling data and then upgrading to Bi-Linear Bed Leveling data.
See my forum Post below,
Now today I only need to perform a G29 "bed level" and M500 "Store settings" if the mechanical bed leveling becomes out a calibration and needs readjusted.

Then add "M420 S1" to startup G-Code after the last G92.

[forums.reprap.org]

Quote
Roberts_Clif

Now today I only need to perform a G29 "bed level" and M500 "Store settings" if the mechanical bed leveling becomes out a calibration and needs readjusted.

Then add "M420 S1" to startup G-Code after the last G92.

[forums.reprap.org]

You mean "M240 S1" after the last G28 I guess.
But you need to load the grid after printer switched on, don't you?

Quote
rc-snail

Quote
Roberts_Clif

Now today I only need to perform a G29 "bed level" and M500 "Store settings" if the mechanical bed leveling becomes out a calibration and needs readjusted.

Then add "M420 S1" to startup G-Code after the last G92.

[forums.reprap.org]

You mean "M240 S1" after the last G28 I guess.
But you need to load the grid after printer switched on, don't you?

No! I have Never used a M240: Trigger camera

My Startup G-Code
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
;M106 S127 ;set Fan half speed
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z15.0 F{travel_speed} ;move the platform down 15mm
;Put printing message on LCD screen
M117 My Print...
G28 X0 Y0
G1 E4.0 ;prime extruder
G92 E0 ;reset extruder length
M420 S1 ; Bed Leveling On (Marlin)
M220 S32.000000 ; First layer Print Speed

In the video, I power on printer, Connect to Printer USB, Send G28 to Auto home, and Send M420 S, and Last Send M402 V to verify data is available.

It will not let you restore the Bed Leveling data if you have not homed the printer.

Edited 3 time(s). Last edit at 05/16/2018 06:19PM by Roberts_Clif.

hi

... so you can store the bilinear (!) mesh in the eeprom with M420?

I thought you can only store UBL meshes...

thx

Now, I tested it.

Firmware with bilinear-bedleveling settings installed.
Start Printer, sent
G28
G29
M500
Ready.

Printer Reset/Off/On/whatever

Start G-Codes for printing:
G28
M420 S1
Printing G-Codes
Ready.

Really nice feature, the bilinear Grid has been saved with M500.
And leveling with the saved grid activates the M420 S1.

Quote
coolduke
hi

... so you can store the bilinear (!) mesh in the eeprom with M420?

I thought you can only store UBL meshes...

thx

Store the Mesh with Menu Item Store Settings or M500. (The Program does not care it just see's data to store).
Enable Bed leveling using "M420 S" or "M420 S1"
verify Bed leveling using "M420 V" or "M420 V1"

Only a small set of the Unified Bed leveling commands work with other Bed Leveling. I only use Save, Restore and View Data Commands

M420: Enable/Disable Bed Leveling and/or set the Z fade height.
S[bool] Turns leveling on or off
Z[height] Sets the Z fade height (0 or none to disable)
V[bool] Verbose - Print the leveling grid
Send M501 ; Load data
Send a M420 V ; Print the leveling grid
Z-Offset
Z-Offset " M851 Z-0.44 " Sets the Z-offset the input -00.44

It appears that Unified Bed leveling command G29 some do not work with Bi-linear. See Working commands here "AUTO_BED_LEVELING_BILINEAR"
[marlinfw.org]

Ok, back to topic.

I've tested again with UBL and found a hint for the G26-Issue.
It seems, this problem causes in G0/G1-routines, if a used coordinate is bigger than max-limits.
Tried to do G1 X0 Y405 Z0 while the max Y-limit is 404, Head moved to bed-end Y.
Then G1 X402 Y405 Z0, Head moved to bed-end X and then Z lowers until head crashes onto the bed and I switched it off.

So, there are some basic issues in G0/1, I guess.

Edited 1 time(s). Last edit at 05/25/2018 09:10AM by rc-snail.

How old is the firmware you used to find the G0/G1 issue? Some issues have been addressed in that area of the code base in the last two weeks.

It's the latest release 1.1.8, but older than 2 weeks I guess ...

Edited 2 time(s). Last edit at 05/25/2018 02:53PM by rc-snail.

i am struggling with this too- i could not figure out if it was my sensor or glass bed. and i have holes in my mesh-

[imgur.com]

i am tripple sensing, using dc42's ir sensor.

my FW is older than 2 weeks- can someone point me to somewhere that might give me an overview of how to migrate to latest release without loosing my customizations and configurations?

The best way is to use a Visual Diff program to cross everything over. NotePad++ with the visual diff add in works very well.

I use WinMerge Where I can load two different files and compare them side by side.




Thanks Roxy
Will look into this option on Notepad++

Edited 3 time(s). Last edit at 05/26/2018 02:27PM by Roberts_Clif.

Quote
Roberts_Clif
I use WinMerge Where I can load two different files and compare them side by side.
...
Will look into this option on Notepad++

I actually use ExamDiff-Pro. But NotePad++ (with the visual diff compare plug in) is free. I think ExamDiff-Pro has a Demo version if you want to try that.

Quote
coolduke
and this is the G26 pattern... after this few circles the print suddenly stops and the Z-axis move upwards until I have to reset the printer, or the Z-axis will hit the frame.

Did you ever get to the bottom of this?
I've had this problem on and off for a while. It has plagued me on my Delta since marlin 1.1.6 to Marlin bugfix 1.1.x Dated Jul 14, 2018.
I want to be clear, I'm not blaming marlin firmware or calling it a bug...... I was doing things wrong....

Recently I switched from nozzle as probe electrical contact to a Bltouch. Bltouch is better for my DIY magnetic removable flex bed. With nozzle as probe I had to remove the print surface from bed plate so probe could make electric contact between nozzle and bed. Getting the bltouch setup correctly forced me to revisit delta_radius, printable radius, extruder offsets, ubl mesh inset etc. I believe the crash during G26 is a boundary issue. I think if G26 encounters an undefined mesh point or one that is way outside the range of other points it causes the printhead to move toward z max error.

#define DELTA_AUTO_CALIBRATION
#define DELTA_CALIBRATION_RADIUS 100 // mm
#define DELTA_PRINTABLE_RADIUS 95.0
#define AUTO_BED_LEVELING_UBL
#define MESH_INSET 10 // Mesh inset margin on print area

upload new firmware, load defaults, initialize firmware
M502 ;
M500 ;
M501 ;

delta auto config
M665 B70 ;
G33 A P2 V2 ;
M500 ;

unified bed leveling
G29 P1 V4 ; preform ubl probing
G29 P3 ; fill in missing points
G29 S1; Save UBL mesh points
G29 A ; Activate the UBL System
M500 ; Saves settings to EEPROM

set up z offset
M211 s0 ; softendstops off
Set zoffset
M211 s1 ; softendstops off
G33 P1 ; let delta config use new z offset
M500 ;

Fine tune mesh
G28
G26 B60 H205 F1.75 L0.2 S0.4 P2 Q7 ;

At this point the printer prints the mesh. But sometimes it would crash during printing the mesh g26. But always near edge of print bed. Usually same spot too. I got use to being ready to pull the plug or hit reset button.

Two things I do differently from above that I think have solved the issue, time will tell.

1. I didnt realize that you need to do G29 P3 repeatedly until all mesh points are filled. So in the past I had undefined mesh points, because I would only run G29 P3 once.
Also G29 P3 is an auto fill command. It was choosing a few auto values that were very far away from the other points probe found. 90-95 percent of the points G29 P3 chose were ok. But 1 or 2 where 2-3.5mm higher than the rest. I was never looking at the mesh G29 P3 auto created. So I didnt know some values were so out of whack from the others. Maybe that huge difference effects G33's logic?
Now I use:
G29 P3 C0.00 R4
I view the mesh G29 T, then goto areas with undefined points and fill them in. Using G29 P3 C0.00 over and over until all points have a value.

2. #define MESH_INSET 10 // Mesh inset margin on print area
For a Delta you need points around the edges of printable radius - using any inset value takes points away from the edge.
so now I use:
#define MESH_INSET 0 // Mesh inset margin on print area.

Those 2 changes are the ones I think solved print head moving toward z max while doing G26. (I never knew G26 printed half and quarter circles, in the past I didnt have enough edge points)

Maybe G26, needs more sanity checks. For noob users.

Edited 1 time(s). Last edit at 07/20/2018 07:09PM by nuroo.

I installed a Classic BLTouch and it works great.
Trying UBL
The UBL routine does many points and sends the probe off of my bed.
using ---- Marlin_10_7_bugfix_Bltouch --- version of marlin

changing settings doesn't seem to do much?

Can you help to keep probe on bed?

You should be using the latest Bugfix version. It is difficult to support old versions of the code.

You are moving the nozzle off the mesh. Set up things so the mesh is actually on the print bed and you are not moving the nozzle off the mesh.

With that said... I did put in a lot of code to handle the case where the nozzle moves off the mesh. It is possible you have found some corner case where a bad Z-Height correction value is being returned.
If that is the case... I do want to understand and fix that.

Right now, I'm gearing up to add more 'Off the mesh' Z-Height correction options. You really should be keeping the nozzle on the mesh. But I understand that puts a big burden on the user. And I understand it is possible to have a print that extends a little bit off the mesh and you didn't know that was going to happen. I'm going to add options to control how that is handled.

But right now.... Make your mesh big enough the nozzle doesn't leave the mesh.

Edited 1 time(s). Last edit at 07/31/2018 01:58AM by Roxy.

Where is "the mesh" setup?
How do I make it smaller than my bed?

Folgertech FT5

bed 290 x 290mm
BLtouch is 54mm +Y offset

Tnx