Z offset to 0.04

[IAGITH]

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [..so my machine will not work if i set offset from pronterface. I have tried multiple times and 0.01 just takes forever and also doesn’t register some of them and i want to join your new features :( Also recently learnt that 1 step from the motor equals 0.04 height]

Describe the solution you'd like A clear and concise description of what you want to happen. Since i have no issues setting offset at 0.05 steps i would like it to be 0.04 steps instead since it’s supposed to be the magic number :)

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

[synman]

I'm not sure if I follow... there is a bug in babysteppping currently related to making live changes when printing from SD, but the scenario you describe does not match that.

Offsets are set via mm increments and Marlin does the conversion between mm and actual microsteps.

There is a condition I'm researching via Touchscreen changes that does manipulate the underlying marlin probe module directly, but this too does so using the marlin babystep.add_mm() api.

For reference, in case I'm missing something in your message:

M290 - increments / decrements baby steps in MM - https://marlinfw.org/docs/gcode/M290.html

It is then subsequently retrieved using:

M851 - retrieve current offsets - https://marlinfw.org/docs/gcode/M851.html

[synman]

Should also note, in my own testing, M290 changes are near real-time. It is M851 Z-X.XX that requires a reprobe for it to take effect.

[synman]

See #34 so we can be clear on the actual issue occurring here.

[synman]

I've been thinking a bit more about this and I think I understand the issue you are having a bit better. I had to read your description a couple times for it to truly sink in.

I believe what you're describing is going to be more prevalent the bigger your planer buffer is. This is a great example of why NOT to increase the buffer size :)

What you need is a mechanism to jump the queue, so to speak. I'll look into this a bit more as it relates to M290. With EMERGENCY_PARSER enabled, we may be able to configure M290 as a command that gets executed the moment it hits the Marlin buffer rather than have to wait behind all the gcode that entered the buffer before it.

There's hint here workaround wise. It is likely configurable too if you are also using pronterface to send the actual gcode to your machine. Somewhere within its settings should be an option to change its own buffer size. Here's a similar option available in Octoprint (NOTE -- this is the default value in OctoPrint):

See how it is set to 1? I believe this forces OctoPrint to basically not maintain a send queue of its own. When you couple that with adding M290 to this next setting, you are basically creating an "immediate" command. Octoprint will send these commands immediately, jumping over any gcode that it has in its own buffer.

Now, you still have to wait for the actual Marlin planer buffer to clear, or we figure out how to treat M290 as an emergency command within Marlin too.

This is a great issue. You've got me thinking.

[IAGITH]

yeah i was talking about m851. when i use that my printer decides that it doesn't care about it. it works for the bed leveling, but once it is time to print it just prints on the air(50% of the time). have not tried to use command m290 to adjust the offset since most of the time I do leveling from the touchscreen. when it comes to Z accuracy... S1 pro is only 0.05 "accurate" so i was wondering what happens when you tell the system to do a 0.01 and how repeatable it is. last time i tried a 0.01 firmware i got one failed print on air and the next destroyed my textured bed, so i just gave up on the whole 0.01 xD. never had an issue setting offset at 0.05, but according to people 0.04 is the actual minimum natural movement of the motor, so it could be more accurate.

[synman]

Check out M290 and minimize your gcode sender buffer size as much as possible. I think you'll like the results.

Here's how I do it in OctoPrint:

These are basic "Custom Controls" that I mange within config.yaml directly:

controls:
- children:
  - children:
    - additionalClasses: fas fa-arrow-up
      command: M290 Z0.01
      confirm: null
      default: 'Offset: ???'
      regex: .*Probe Offset.* Z(-?[\d\.]+)
      template: 'Offset: {0}mm'
    - additionalClasses: fas fa-arrow-down
      command: M290 Z-0.01
    - default: ''
      defaultValue: ''
      regex: ''
      template: ''
    - default: ''
      defaultValue: ''
      regex: ''
      template: ''
    - default: ''
      defaultValue: ''
      regex: ''
      template: ''
    - default: ''
      defaultValue: ''
      regex: ''
      template: ''
    - command: M851
      name: Refresh
    - default: ''
      defaultValue: ''
      regex: ''
      template: ''
    - default: ''
      defaultValue: ''
      regex: ''
      template: ''
    - command: M500
      name: Save to EEPROM
    layout: horizontal
  - children: []
    layout: horizontal
  layout: vertical
  name: Z-Probe

[synman]

and the reason why M851 works while leveling is because you are constantly triggering the probe. For obvious reasons, we can't trigger a probe in the middle of a print so the command you really want to use is M290.