What might cause a z-offset to no longer be correct?

Snapmaker 2.0
1

Disclaimer: this is my first 3D printer, and while I’m learning a lot, I clearly still have lots to learn.

My out-of-the-box auto leveling was quite decent, but I’m fine tuning the leveling mesh as a learning exercise (and because I’m an incorrigible perfectionist). I’ve been using techingtech and Tone’s excellent resources. It was going quite well, and I’d gotten 3/5 of my test squares beautifully smooth… but the next time I booted up the machine, my center square was way off. Nozzle was way too close.

I started out with settings that gave me an excellent center square (3.638 for the center mesh coordinate). Every step of the way, as I adjusted the other coordinates, I logged the new mesh coordinates, and I1J1 never varied. Yet for some reason, it’s now giving a completely different result.

I didn’t change the bed, toolhead, filament, or… well… anything.

Am I expecting too much from the machine, and this variability is just expected behavior I need to work around whenever I print?

Any insight would be lovely. Thank you!

2

I don’t understand what you’re describing. Gonna have to provide either pictures, or your mesh, or something to work with.

Just taking it as you described it, it sounds like you did something wrong rather than the machine having variability.

If I was to guess, you didn’t home in between changing your mesh values.

3

Ah, my bad! I’ll try to clarify.

Here’s the initial mesh that I started with, with I0J0 at top-left. (geez, I can’t format with whitespace on a forum post? sorry for how ugly this is)
3.965 — 3.908 — 3.974
3.654 — 3.638 — 3.863
3.416 — 3.498 — 3.819

I tested my level periodically by printing 5 squares - one at each corner, and one in the center. At this point, with this mesh, I got a perfect center square, but the others were off.

I adjusted the mesh points manually. My MO was basically to test how tight the calibration card felt at the center point (which I knew was good), then to adjust the other points until they felt like that. So if it was too loose at I0J0, for example, I’d run “M421 I0J1 Q-0.1” and “M500”.

Eventually I ended up with this mesh:
3.915 — 3.858 — 3.974
3.554 — 3.638 — 4.013
3.316 — 3.578 — 3.919

But for some reason, when I did a test print with this, the center square was now quite a bit too tight. This really surprised me, because I never changed the center coordinate; it stayed at the same value the whole time. I chalked it off to, like, one-time weirdness, called it a night, and came back to it the next day. But I got the same results the next day - the center square was too tight, even though I1J1 was still 3.638.

Hopefully that’s a little clearer! Apologies for the vague first description.

With that out of the way - it’s very likely I didn’t go home between changing the values! I did sometimes, but it was honestly out of superstition cause I didn’t know I was supposed it, and I didn’t think it would actually do anything, lol. Can you explain why that’s an important step? I’d have thought that the current position of the nozzle wouldn’t matter when setting the mesh values.

4

It’s been some time since I’ve done this, just working from memory, so very possible I’m off my rocker here.

I seem to recall the mesh being fundamentally tied in with homing, and changing the mesh may or may not adjust the current in-memory location correctly. Re-homing between adjusting the mesh would correct any variance acquired, but it also may be an unnecessary step.

Are you using a 3x3 mesh? 5x5 is the minimum acceptable, and if your bed has higher frequency oscillations you should consider running an 11x11 grid.

However, as you have probably seen around the forum lately there is a long standing bug where the bed is measured ~20mm away from where the software thinks it is, so the corrections will never be perfect.

The reason is because the software is double compensating for the probe offset from the mesh values. That alone may explain your issue if it’s small (it is).

It appears you’re chasing perfection here. Aside from the hair-pulling experience that can be, I’ll just add you should consider measuring and enabling backlash compensation. It’s an easy way to gain free performance, and improve the accuracy of your measurements.

For example, if you were not careful to take your measurements in the identical direction of travel every time then you will have a +/- backlash error introduced into your measurements, which wouldn’t fully explain the difference, but would partially.

M425 X0.02 Y0.02 Z0.02 F1 S0 will correct for the factory specified backlash, you can easily measure it yourself in Z using the card friction while jogging in +/-0.01mm (or smaller) steps. backlash compensation is not saved to the firmware, you would need to put it in the header of your gcodes that run on the machine, or in a macro you run at startup.

7

Thank you for the excellent advice! Backlash compensation sounds like a net win, I’m hopping on that right away. Does the factory specified backlash tend to be pretty accurate, or is there enough per-machine variance that you’d recommend measuring it myself?

8

This is something I absolutely, 10000% would never have thought of. Wow. Thanks for the warning!

9

Since it sounds like you enjoy tinkering I’d suggest you measure it for your machine.

Z is easy to check with the calibration card and friction, I find X and Y easiest to test with a circle g-code with the laser, an error will show up at the 4 edges

PXL_20201224_001003432~2
PXL_20201224_001003432~22753×3646 1.49 MB

You can see .10 is under corrected, and .20 is overcorrected.

This is when I had a wobble in the X axis due to hitting something and loosening up the internals, repaired since. Then backlash went back down to about a tenth of that error.

I made that file in lightburn for the toolpaths, and then edited the file to add the change in backlash before each circle starts.

10

What causes this? Isn’t this something that should be prioritized to fix? Especially since it’s not mentioned anywhere in the manual that it could cause damage. This sounds more to be an oversight on Snapmaker’s part. And a bad one.

12

@WilliamBosacker wow. Well… I have a habit of cycling it off while setting up the next job and turn it back on. I guess I’m lucky lol.

13

I had seen comments about this before but not experienced it, probably because I use Octoprint which automatically switches the machine off after a print. On my last very big print I had to change the filament and for some reason when I un-paused, the print was not aligned with the model. Strange so I stopped the print, did a G28 to home all the axes and moved the head to the position that should have aligned with the model - it didn’t! An all axes home did not re-home the axes. The position reported by M114 was correct, it was just the head that was not where it should be. For the record after poweroff/on, I started the print at the point I had paused it and it finished without error so it was unlikely to be a hardware issue.
I will now be powering off between prints and when I get me/machine time, try and find a way to re-produce the error so that I can investigate what is going on. My prints and the pause where initiated from Octoprint so not using the touch screen at all.
I have a suspicion based on levelling that the touch screen does other stuff but of course we cant see that as it’s not been published.
I think this should be raised on GitHub as it is important though I would rather do that with something that proved the issue rather than it happens sometimes when you do a large print. @WilliamBosacker saying it happens with large prints aligned with my experience and thats going to make it hard to re-produce I guess.