Help me understand auto bed leveling

[ngarafol]

This one is more of a request for clarification than an issue, so hope it is tolerable to post it here.

I own prusa i3, rework 1.5 diy version by emotiontech. It has direct extruder and inductive probe 12mm diameter one with 4mm sensing distance. Sensor is NPN type, so is directly wired to ramps 1.4. Bed is mk3 one, without glass. As bed is 3mm aluminium, after some time it is not flat. Thats where inductive probe is supposed to help.

Currently I am running "old" marlin, version 1.0.0. Command M851 accepts only negative values (meaning probe is expected to be above nozzle, right?). For some reason I compiled marlin with Z_MIN_POS -1 because I thought it would solve problem when nozzle was too high so filament was not sticking to bed but curling and tangling around nozzle. Yesterday I removed nozzle to clean it (printing ABS, had a little clog) and screwed it back. And again seems like I managed to move nozzle 0.1mm or more and again prints start too high. BTW in start gcode I have G28 and G29, and use grid with 3 points, so 9 total locations to probe.

Someone please link me to some resource explaining ABL or please explain me with Z_MIN_POS -1 what values are "acceptable" when running G29 command? All probe points at -1.xy values? 0.xy values? -0.yx values? Its confusing to me what exactly does Z_MIN_POS -1 do? As I get it, it enables nozzle to travel 1mm below Z0, right? So in theory, for Z offset values I can input maximum value of -1 since Z_MIN_POS is set to -1 right?

And what if I need to raise nozzle - Z offset positive value? I need to build newer marlin version that accepts positive values? Again sorry but I really need some guidance since its not making much sense in my head. If some parts are missing or more info is needed I will provide it.

Edit: found this link: https://github.com/MarlinFirmware/Marlin/wiki/DNE-Bed-Auto-Leveling So I believe I should adjust Z offset until nozzle is around 0.1mm above bed at Z0?

[Roxy-3D]

It depends on the type of Auto Bed Leveling you are using. But with no correction happening, it is not unreasonable to set the nozzle height at .1mm using Z_PROBE_OFFSET_FROM_EXTRUDER. At least in the the devel_ubl branch, z_offset is probably going away. Try to keep that at 0.00mm unless you really need to put a value into it.

[ngarafol]

Well being marlin 1.0.0 version, it has grid leveling and 3 point leveling. Here are the default setting, I only altered grid making it 3x3 instead of 2x2

http://pastebin.com/YfHQrgKx

[Blue-Marlin]

Command M851 accepts only negative values (meaning probe is expected to be above nozzle, right?).

No! Command M851 accepts only negative values (meaning probes trigger point is below the nozzle. The trigger point is about 4mm below the round blue/yellow bottom surface of your probe.)

For that generation of Marlin (https://www.youtube.com/watch?v=EcGFLwj0pnA) is a usable guideline.

[thinkyhead]

Of course, now we allow a negative M851 Z offset for a probe that triggers when the nozzle is above the bed, and we allow a positive offset for nozzles that need to press against the bed to trigger a switch. This changes the behavior of M851 Z compared to previous versions, so users will need to watch out when upgrading to 1.1.0.

[ngarafol]

Managed to flash RCBugFix release of marlin. Played with mesh leveling, and it is going in right direction, but will give devel-ubl a try since manual adjusting is obviously not my expertise (using feeler gauge). Will have to increase number of points to 4 or 5 since 3 is not enough for my current bent bed.

[thinkyhead]

The automated equivalent of Mesh Leveling in RCBugFix is called AUTO_BED_LEVELING_BILINEAR. It works well, but one trick it doesn't (yet) do is divide up moves when they cross the grid lines.

[ngarafol]

Do you recommend going to devel-ubl branch? I heard nice things about ubl :)

On Thu, Oct 27, 2016 at 12:25 PM, Scott Lahteine notifications@github.com wrote:

The automated equivalent of Mesh Leveling in RCBugFix is called AUTO_BED_LEVELING_BILINEAR. It works well, but one trick it doesn't (yet) to is to divide up moves between the grid areas.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/5091#issuecomment-256604790, or mute the thread https://github.com/notifications/unsubscribe-auth/AEhGyEsmUYf8HEJmaa7jez5HIycvvICjks5q4HwjgaJpZM4KhHHS .

Pozdrav, Nikola

[Roxy-3D]

It works well, but one trick it doesn't (yet) do is divide up moves when they cross the grid lines.

I don't understand how the nozzle can track the mesh if it doesn't do that? The reason I say that is if the move is long (say 2 or 3 mesh cells), unless you correct the Z height periodically during the move you won't be following the bed's topography.

Do you recommend going to devel-ubl branch? I heard nice things about ubl :)

It is a 'Development' branch. So, you need to be willing to accept the fact that you may hit a bug that needs to be figured out. But it really does work well. I've deliberately sought out the worst piece of glass I could find with dips and bumps in it. I can get a perfect 1st layer every time when printing on it.

[Roxy-3D]

@ngarafol Take a look at this thread: https://github.com/MarlinFirmware/Marlin/issues/4948

The title and direction of it changed. There are complete directions to guide you through the process of bringing up UBL. And Wookie is now posting pictures of his Mesh Validation Patterns and the topographical maps being used to generate them. He is in the 'Home Stretch' of getting his 340mm x 350mm print bed defined. It is my expectation that when he gets his mesh definition finished, he will get a perfect 1st layer every where on his bed, every time.

[thinkyhead]

I don't understand how the nozzle can track the mesh if it doesn't do that?

An oversight. It worked just great for DELTA and now works just fine for SCARA, but it definitely needs that addition to work as-intended on Cartesian.

[Roxy-3D]

An oversight. It worked just great for DELTA and now works just fine for SCARA, but it definitely needs that addition to work as-intended on Cartesian.

Oh! At least in the Delta and Scara case, the lines are automatically broken up into small segments anyway. But that doesn't happen with Cartesian! I get it!

[ngarafol]

Thanks guys. I am not 100% on it, but it is becoming clearer. I switched to devel-ubl branch, fired up g29 p1 O and saved it. Also, when testing with G26 there were some problems printing on some part of bed, so either I didnt manually load saved mesh or probe measured distance wrong or problem was Z offset set to 0. After setting z offset to -0.05 manually it seems to fix first layer. But there is still work to do - benchy did not stick when printing :D

[Roxy-3D]

Also, when testing with G26 there were some problems printing on some part of bed, so either I didnt manually load saved mesh or probe measured distance wrong or problem was Z offset set to 0. After setting z offset to -0.05 manually it seems to fix first layer. But there is still work to do - benchy did not stick when printing :D

The intention is to get the Mesh close with G29 P1. But the very first 1 or 2 Mesh Validation Patterns probably won't come out perfect. What you want is for them to be 'Good Enough' that you can see where the problem areas are. You then move the nozzle to those areas and do a G29 P4 R O and edit the various Mesh Points in that area. Then move to the next 'Bad Area' and do another G29 P4 R O.

You should see noticeable improvements in the 2nd G26 Mesh Validation Print. But probably, you are still not done. You will see that you are getting closer to having perfect adhesion in more areas of the bed, but you need to go back and do a few more G29 P4 R O's. It is OK and normal for it to take 3 or 4 iterations to get the Mesh Validation Pattern to print perfectly. (I'm deliberately using a horrible piece of glass that has bumps and dips all over it. It takes me 3 or 4 iterations to get the Mesh perfectly defined and I know what I'm doing!)

[github-actions[bot]]

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.