Confused on Z offset saving / changing?

Snapmaker 2.0
1

I don’t normally play with Z offset (i like to get my calibration right).
However was testing last week and set it to -0.05 when printing from the screen.

I noticed after a powering back on today during the home process when doing home from screen it sends the following to my octoprint console.

Recv: leveling ON
Recv: Apply Z offset: -0.05
Recv: X:-19.00 Y:347.00 Z:328.89 E:0.00 Count X:0 Y:142800 Z:133600 B:0
Recv: ok

I want to print from octoprint today and i don’t want this offset to apply.

I couldn’t find a way to adjust this on the settings on the A350 screen.
I found I could adjust the setting if i went files > select a file > adjust settings but when i back out the setting is not actually saved (i assume it is only saved if i actually print something)

  1. seems like the z offset is saved between object prints and power cycles (i have see folks claiming it is not, so i guess this is fixed in latest firmware?)
  2. can I force the z offset to 0 from the screen, or do i have to it from gcode?

I am wary of using M851 to do this as it reports the probe offset not the nozzle offset. So i don’t think that’s the right thing to play with…

Send: M851
Recv: echo:Probe Z Offset: 1.00
Recv: ok

2

Ugh, you have found a kinda annoying quirk in the firmware.

In the firmware the variable associated with the Apply Z offset: -0.05 is called the live_z_offset and is associated with that touchscreen function in the middle of printing.

Unfortunately that live z offset is updated ONLY by the touchscreen, it is not mapped to any gcode, so there is no way to set it to a particular value easily.

Yes, it is stored in the EEPROM and loaded at startup.

The easiest way would probably be to start a dummy print and then reset it to 0 there.

The Live Z offset is also reset to 0 when you start a bed levelling from the touchscreen.

Don’t do that, that changes the model of the toolhead geometry and is not related to the Live Z Offset.

1 Like
3

thanks, thought i was being stupid, i could see how this could people into trouble (head crashes etc etc)
i will do a fake print and see if that’s enough
(this is to print you enclosure bushing :slight_smile: )

5

oh god the code path that controls this is totally wonky

  • I select file to print
  • I adjust the offset to 0.00 and back out of adjust settings
  • i start the print
  • I watch the output in terminal and the live offset is echoed out at -0.05
  • i swipe left to see settings and the display indeed shows -0.05

at this point i canceled job, did a home to see what it reports - it reports -0.05

  • do the same steps above again
  • this time I don’t swipe left to see what it says and…
  • …let the print job finish (luckily its 3min 45 sec job)

the finishing responses automatically output still say the z-offset is -0.05

  • i click complete on the touchscreen
  • navigate to control and click home

and guess what the z-offset is still

Recv: Apply Z offset: -0.05

¯(°_o)/¯

6

Oh no… yea I don’t know at this point. I’ve never used the live z offset and at this point I’m too afraid to try.

7

yeah all i can say is, don’t, at least not on this latest firmware

i have one more thing to try after this print - i will try setting it +0.05 to see if its a zero issue or once one has modified it once one is screwed. also i suspect a bed calibration from the touchscreen will override it…

8

Looking through the code more found something, the live_z_offset is written here indirectly via a macro: Snapmaker2-Controller/configuration_store.cpp at ee368b40949e334bd354314fd33356bfd7df1117 · Snapmaker/Snapmaker2-Controller · GitHub

So it definitely is stored and retrieve in the EEPROM.

All of the eeprom macros being used: Snapmaker2-Controller/bed_level.h at ee368b40949e334bd354314fd33356bfd7df1117 · Snapmaker/Snapmaker2-Controller · GitHub

Looks like one thing is for certain, an EEPROM reset will reset it to 0. An EEPROM dump, reset, then load and save would reset it.

9

Oh I understand how this live z offset works.

This is really insidious actually. This block is called when the touchscreen updates the offset.

  float cur_z = current_position[Z_AXIS];

  do_blocking_move_to_z(current_position[Z_AXIS] + (offset - live_z_offset_), 5);
  planner.synchronize();

  current_position[Z_AXIS] = cur_z;
  sync_plan_position();

It moves to a new z height including the new z offset, but then sets the “current position” to the previous value. That technique is used when homing the machine to set the machine’s position in space.

I don’t really want to go through a full proof of this algorithm, but this could have unintended consequences since the previous machine position is not remembered.

10

could it explain some of the weirdness folks have where they suddenly find they crash things into bed (if this is a compounding error)? i note many like to use the live offset to work around fundamental layering issues and seem to tweak it constantly…

11

M502 throws away the setting.
M502 + M501 keeps the setting.

I just ‘fixed’ using M502, didn’t have to change esteps, linear advance or backlash - that seems to be saved as factory defaults now!? (or i never really understood factory defaults / M500 / EEPROM relationship)

1 Like
12

Yea, it could be. The function computes the delta between the old and new commanded offsets, so as long as that’s maintained then there shouldn’t be issues.

So you’re at -.5, if you command 0 that would be a delta of .5, so it will move z by .5. It then stores the new offset as “0”.

The offset is also applied every time the machine homes with G28.

It looks like it would be possible to do a G28 X that would result in the Z offset being applied twice.

I’m not set up for 3DP, would you mind testing that?

The steps would be something like

  1. Home machine normally
  2. Apply a 2.0mm live z offset by some method
  3. Return to the touchscreen home screen
  4. Home just the X axis.

Then verify if Z is at the same height.

13

adjusting from -0.05 to +2.0 let me change the height
then adjusting that by a single -2.0 to get to 0 leaves me with as the print job starts

Recv: new live Z: -0.001, delta: -0.200

then doing a stop on the touchscreen gave me this

Recv: Apply Z offset: -0.00

one the stop was processed (which took ages) a home results in this

Recv: leveling ON
Recv: Apply Z offset: -0.00

i did try a G28 X in another go around, Z seemed to stay constant

this definitely funky, no idea why i couldn’t go from -0.05 to 0.00 - will try to repro at some point to see if it is an intermittent issue.

1 Like
14

heh, I thought I was the only one who thinks the live Z-offset handling was insane.

I now only use it mid-print (generally, first layer) to determine the ideal height for the nozzle , then I set it back to zero and apply the nozzle height change in Cura, or by re-running the calibration and applying the offset to what “feels right” according to the calibration card.

The whole “save it forever but don’t let the user observe or change the value” thing is pretty frightening.

15

i have seen you say this before, in general on the latest firmware if it saves it shows correctly on the screen when looking at ‘adjust settings’ for a model (yes i know you can’t see it anywhere esle and it should be basic info showed on every screen that shows z).

also i have only had one instance of it not saving, i am unclear how the machine gets into that state

tl;dr you are right, and its even more nuanced / wonky that you state, lol, ?:slight_smile:

16

yeh true, I am running on the firmware that came with the machine, so there are many improvements that I have not been exposed to.

I have set aside Sunday to do the update, so get your popcorn ready and settle into the armchair to enjoy a bunch of cranky posts!

1 Like
17

@edf well that explains a lot.

1 Like
18

heh. yeah, SM didn’t exactly win my confidence by breaking wifi connectivity with the very first firmware upgrade after I bought the thing.

had to mothball the A350 again because the missus complained about the noise it makes. going to work on better soundproofing for the enclosure, as small tight circles at slow speed are rather loud.

finally did the frmware upgrade today, all the toolheads too.