I dug my mini out of storage, downloaded the latest lulzbot cura 2.6.52 and then updated the firmware to the latest and it’s printing in mid air. The nozzle is exactly 10mm above the bed.
The auto levelling was initially not working correctly - the nozzle would crash into the washers much harder than i remember it used to. There was some build up of plastic and oxidisation on the nozzle so i gentle cleaned that off. That resolved the levelling routine - it very gently touches the washers now like it used to.
Still, when it finishes levelling it goes to 10mm above the build plate, waits to heat then tries to print at that height.
I decided to try M502 reset EEPROM because i saw a mismatch when doing M500 dump eeprom - v23 eeprom and v40 marlin. Now both are v40 but still no joy.
I’ve compared gcode from an old gcode i had printed a few times before, there’s no difference in the setup gcode really. There’s no smoking gun G1 Z10 or whatever.
Well, i found the link for the old Lulzbot Cura 21.08, installed that, installed the mini firmware from that release, did an M502 / M500 and it’s printing perfectly again.
The GCode from Cura 2.6.52 doesn’t seem bad so i guess it’s the current firmware for single extruder mini that doesn’t like my printer.
I’ll try printing rocktupus from Cura 2.6.52 on the current (old) firmware next just to prove it’s defintely the newer firmware my printer doesn’t like.
Really strange because it’s not a brand new firmware, i wouldn’t expect to be the first to run into an issue.
The firmware released with 2.6.52 (1.1.5.44, I believe) has some odd issues with leveling. In particular, if (after leveling) any vertical (Z) moves are made while against an endstop, the bed level compensation matrix is altered in a bad way. This is due to changes in the way endstops are handled, and how the Homing command (G28) is handled – but can be worked around with changes to start scripts. Different people will experience this in different ways, depending on the gcode sequences used.
For example, what I experienced… My first print after power-up would work just fine (Home, Wipe, Probe, Print). But a second print without power-resetting the printer would Home, then head for the wiper pad – but never get there, attempting to wipe about 10mm above the pad. (The probing sequence would then continue, and eventually printed OK). This behavior was caused by the startup script moving downward while at the X endstop – and messing up the bed level matrix (which is no longer cleared by G28), making the firmware think the bed was lower than it really is.
These issues are being worked. The Aleph Objects firmware developer is aware and understands the problem, and is implementing solutions (some in firmware, some in starting gcode scripts).
There should be a new Cura2 release coming soon. It will include a combination of gcode start script changes and new firmware that should address this. So when the next Cura2 release comes, give it (including new firmware) a try – hopefully it will solve this issue for you.