What is the problem? printer is not leveling on all four corners before it prints. And due to that, is not centered.
What did you already try to solve it? updated Cura to 15.04.6 and still same issue
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...) I have the lulzbot TAZ6 running cura 2.6.69 and 15.04.6
There's not enough information here to answer your question. Please provide at least the additional information in the parenthesis.
The auto leveling of the TAZ 6 is initiated by the Gcode commands in the Start Gcode. Since you mention Cura 15.04.06 I'm guessing you are sending .stl files to OctoPrint instead of slicing them with Cura 2.6.69 (LulzBot Edition?) and sending the gCode to OctoPrint.
If the printer is only touching 3 corners during probing, then you have one of the early 1.1.5.xx firmware releases that used 3-point instead of 4-point grid. Start by using Cura 2.6.69 to update your Taz6 to latest firmware.
Howerver, the number of points used in leveling is irrelevant to centering of the model on the bed. That is typically a problem with the bed definition in the slicer. Post your slicer (Cura 15.xx and 2.6.xx) machine configuration so it can be compared against the actual bed size.
I'm also not sure what the leveling has to do with the 'centering' of a print.
I do experience leveling failures quite a bit on my Taz 6 that aren't recognized as failures. What happens is that a small amount of filament is blocking the nozzle from making electrical contact immediately and instead 'squeezes' the filament out of the way as it is pushing on the leveling washer. It eventually makes contact and continues on storing that bad value.
Does the Taz have the same problem as the Mini, in that once you upgrade to the latest firmware included with Cura 2.6.69, you can no longer slice with older versions of Cura? Apparently, the start gcode changed which throws the coordinates off a bit. So if you update the Mini's firmware, you can no longer slice with the profiles created in 15.04 and imported into OctoPrint's Cura engine (unless you figure out the changes in the start gcode and make similar changes before exporting the profiles).
@John_Mc - Yes, the issue is the same. It is not with the slicer or sliced code per se, but with the start Gcode scripts pre-pended onto the sliced file.
With 1.1.5.xx or later, moves while an endstop is triggered can alter the leveling matrix, causing all kinds of Z coordinate issues, and attempted moves beyond an endstop result in incorrect coordinates that affect subsequent moves. In the case of the Mini, the G29 coordinates actually caused the latter problem -- not sure whether that applies to the Taz6 or not -- but the rest does. Version 1.1.5.xx and later change how the leveling matrix and endstops are handled.
As long as you adopt the new start gcode, you're OK with any slicer. Specifically, three things:
(1) Don't make any Z moves when an X or Y endstop is triggered -- so for example, don't "home" and then move up/down before moving XY away from the endstops. When writing gcode, always "move away from the endstops" immediately after any G28 operation.
(2) Check that your start gcode doesn't attempt to move beyond X or Y endstop -- on older 1.0.xx firmware, the current_x and current_y were clipped to the endstop value when that happened, but with 1.1.5.xx and later the position becomes invalid. For example, if X_Max is 159 and you execute a "G1 X170", movement will obviously stop at 159 but current_x will still be set to 170 (older firmware would have clipped it to 159). The problem with that is that the next move is referenced from X170 instead of X159 where it actually is.
(3) You may need to add a "G28 XY" (and then move away from endstops) after the G29 sequence completes. I say may because it is model-specific; the G29 coordinates exceed endstops on SOME sub-models of the mini, and not on others -- not sure about the Taz6. Rehoming XY corrects any incorrect XY coordinate that may have been caused by an attempt to move beyond the XY endstops.
Hope that helps...