For my printer, 1.1.5.15a (4 point) gives better results than 1.1.5.15 (3 point).
For comparision, I also ran 1.0.2.22 which compares favorably with 1.1.5.15a.
I’m not sure I understand why, but with the same z-offset (-1.270), 1.0.2.22 seems a bit squished and 1.1.5.15a seems a bit high (I did remember to set e-steps as well). Not sure which way to adjust z-offset to improve both so feel free to educate me!
@b-morgan: We will do additional internal testing. Thank you for the feedback.
Sadness.
I had sub par results from 3point leveling from the beginning…
now additional testing ???
I must be chop liver. 
Glad someone else confirmed my results.
@Marcio
Mind releasing newest firmware with 4point, again.
Don’t take it personally, nuroo. b-morgan’s post was not necessarily what prompted the re-evaluation. Some folks internally have noticed it too, the timing was just coincidental. I never saw a difference on my test printer, but it’s possible that different printers behave differently. So we are expanding the testing. We’ll see whether the results come out different. If so, then we’ll release new builds. If you want something specifically for your printer, let me know whether you need TAZ or mini and what toolhead and I can make a build specifically for you.
@ Marcio.
Taz 6. Single head extruder, 4 point
Okay, attached are the three variants we are (re)testing. The various methods are described in Marlin as such:
Probe 3 arbitrary points on the bed (that aren’t collinear)
You specify the XY coordinates of all 3 points.
The result is a single tilted plane. Best for a flat bed.
Probe several points in a grid.
You specify the rectangle and the density of sample points.
The result is a single tilted plane. Best for a flat bed.
Probe several points in a grid.
You specify the rectangle and the density of sample points.
The result is a mesh, best for large or uneven beds.
Is it possible to use bilinear probing on a stock TAZ 6?
EDIT: I was also getting poor results with 3-point probing.
Based on what I’ve been able to find, it sounds like 3 and 4 point linear auto bed leveling are nearly the same as both result in a tilted plane correction. Bilinear probing should be better, even from only 4 probe points, as it can result in a twisted surface correction profile.
After internal testing, we’ve decided to go with 4-point LINEAR probing. This update will be made on FW .32, which will be released with Cura 2 shortly.
We found BILINEAR 4-point gives poor results. I suspect this may be due to a bug in Marlin. The BILINEAR technique is meant for a grid of points and I suspect the computation is done incorrectly for the right-most or bottom-most cells of the grid, as these could be a special case in the code. This error would be barely noticeable if we were using a large grid, as it would only happen on a relatively small portion of the total bed’s area; but in our case, since we are using a 2x2 grid, our entire bed would fall within the region in which the computation would be incorrect.
This is just speculation, but it seems to explain why in theory BILINEAR would be better, but in practice it is worse than LINEAR for our printers.
Me
In an effort to find a zoffset that worked for the rear left, I’m now throwing the front zoffset too far from the nozzle. The filament actually has a chance to spiral b4 it hits the print bed (front left). And rear left is still not acceptable. Less squished but not ideal. Seems like its one or the other with this firmware or go back to old firmware. I can’t find a happy medium. Adjusting for rear throws off front level. -0.061 is an extreme offset for the front. What’s puzzling is the hardware is the same, only firmware is changing.
I’m not a software engineer but seems like the bed leveling algorithm or calculation is off. The 3 point calculation may describe a plane but perhaps there is an error in the math?Old firmware, zoffset -1.461, old Cura with initial layer height and initial line width for the win.
Marcio
After internal testing, we’ve decided to go with 4-point LINEAR probing. This update will be made on FW .32, which will be released with Cura 2 shortly.
We found BILINEAR 4-point gives poor results. I suspect this may be due to a bug in Marlin. The BILINEAR technique is meant for a grid of points and I suspect the computation is done incorrectly for the right-most or bottom-most cells of the grid, as these could be a special case in the code. This error would be barely noticeable if we were using a large grid, as it would only happen on a relatively small portion of the total bed’s area; but in our case, since we are using a 2x2 grid, our entire bed would fall within the region in which the computation would be incorrect.
This is just speculation, but it seems to explain why in theory BILINEAR would be better, but in practice it is worse than LINEAR for our printers.
Sounds similar to what I was getting at, I feel vindicated. Gonna try Marlin_TAZ6_SingleExtruder_1.1.5.32_e424c92.hex now
Had a chance to play around with the advanced pause feature more…
Marlin_TAZ6_SingleExtruder_1.1.5.32_e424c92.hex
In the config file I noticed you had
#define PAUSE_PARK_X_POS 10
#define PAUSE_PARK_Y_POS (303 - 0) - 10
#define PAUSE_PARK_Z_ADD 10
#define PAUSE_PARK_XY_FEEDRATE 100
#define PAUSE_PARK_Z_FEEDRATE 5
#define PAUSE_PARK_RETRACT_FEEDRATE 60
#define PAUSE_PARK_RETRACT_LENGTH 2
Can I suggest a different park location. With the settings above the head moves up 10 mm and pushes the bed out toward the user. The nozzle ends up just to the left of the homing sensor. Which isn’t ideal for cleaning the nozzle or changing the filament.
I prefer
X220
Y17
+Z50 (relative positioning)
This moves the bed to rear and up by 50mm. So the print is out of the way and its easier to get to the nozzle for cleaning.
In Octoprint I use:
M600 X220 Y17 Z50 ; move Z up +50, move bed back to clean nozzle.
Works better for me. I dont know how the printer will react if it’s for instance already @ 225mm height when a pause command is issued. Then the +50mm may be an issue because it would exceed the max build height. But it allows for more room to work with.
If +50 is too much because of above reason. Then at least consider x220 y17, so bed is away from user during filament change.
Hi Marcio,
I’m also running into probe leveling failures with a clean nozzle on FW 1.0.2.22, any ETA for a release of FW 1.1.5.x ?
Thanks for all the updates!
1.1.5.44 was released with Cura 2.6, around 11/24/2017. If you install and run Cura 2.6.52, it should offer to update your firmware automatically to 1.1.5.44.
You can also download it from http://devel.lulzbot.com/software/Marlin/1.1.5.44 — just make sure to get the correct file for your model /extruder — and can install it with legacy Cura21 or Arduino IDE.
We should be real close to another release… Latest builds are available at http://devel.lulzbot.com/software/Marlin, but beware all those builds should be considered “test builds” until AO formally releases one.
Progress Bar for Octoprint - via M73 (like when printing from an SD card)
Then if you add M73 plugin to Octoprint you get a progress bar while printing 
Did it on my cr10s4, love it.
Could we get this added Lulzbot firmware?
The layer number and z height can be done with simplify3d post processing commands.
{REPLACE “; layer” “M117 Layer”}
{REPLACE " Z = " " Z="}
I don’t see configuration_adj.h in the dev firmware or I would try it. Maybe marcio can weigh in on this.
I think that was just a typo – he was referring to the configuration_adv.h file. And Marcio has already added this define (via changes to configuration_adv.h and Conditionals_LulzBot.h) in the 1.1.8.xx development versions.
I just merged the latest update and didn’t see this option, I’ll have to go back and look for it
DELETED - (Replied to wrong post!)
Definitely enabled in 1.1.8.4, that’s the source I’m basing my builds from right now. I haven’t checked the later builds but assume it is still there.
Searching for “M73” in those files and I’m not coming up with anything, I’m using this repository LulzBot 3D · GitLab
Is it defined in another way or am I on the wrong repo?
