Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Z-offset adjustment/finetuning while printing (baby-stepping) #179

Closed
sapell opened this issue Feb 16, 2018 · 13 comments
Closed

Comments

@sapell
Copy link
Contributor

sapell commented Feb 16, 2018

Used to utilize this feature quite often when still using Repetier FW. Baby stepping helps especially when starting a print and you notice the first layer adhesion is less than ideal, by just telling the FW to add a given signed offset to the z-positions in the g-code. This would probably need to be implemented as a custom g-code. I'm not aware of an existing g-code for the feature, correct me if there is.

@lenne0815
Copy link

lenne0815 commented Feb 24, 2018

Theres an Request open for it over at octoprint aswell but it seems like it hasnt been implemented by foosel yet. OctoPrint/OctoPrint#2161 Just found another earlier request OctoPrint/OctoPrint#1686 Doesnt look to good either unfortunately.

@sapell
Copy link
Contributor Author

sapell commented Feb 24, 2018

Thanks lenne0815! OctoPrint lacking support is not the limiting factor here. If Klipper was to implement a custom G-Code for babystepping (akin to speed and extrusion multipliers) one can easily add custom buttons in OctoPrint for the babystepping. One issue is that perhaps Klipper cannot react to an injected G-Code command immediately or quick enough, unless the babystep offset flows down to the MCU and it handles the babystep offset for the Z-coordinates. Unsure though what is the impact on the CPU utilization, one float addition might just be the final straw for an 8-bit MCU...

@lenne0815
Copy link

lenne0815 commented Feb 24, 2018

Yes, that would be one way to do it, the other way would be to set the live offsets in octoprint and add / substract z levels from / to the gcode there without ever touching klipper. Its just another approach of doing it which i suspected already exists but unfortunately does not. I think both variants should work fine computationally as the overhead created is a lot less then delta splits f.e. and is done on the pi.

@sapell
Copy link
Contributor Author

sapell commented Feb 24, 2018

OctoPrint handling the offsets wouldn't unfortunately work when using the Klipper's virtual SD feature. I really like it as it takes one communication step out that could potentially fail.

@KevinOConnor
Copy link
Collaborator

FYI, there is a g-code command (M290) dedicated to "baby stepping" (what a poor name for a command to change the z offset). Klipper doesn't implement that, but it would not be difficult to add support - it just involves altering the g-code base_position (and possibly homing_add). That said, you can do this today with the M206 command. The only difference (that I can see) between M290 and M206 is that M206 takes an absolute offset while M290 takes a relative offset. Also, M206 will persist across homing operations (while it appears it is inconsistent what M290 does after a homing operation).

@sapell
Copy link
Contributor Author

sapell commented Feb 26, 2018

Thanks for the tip Kevin!

@lenne0815
Copy link

Thank you, didnt know that either !

@sapell
Copy link
Contributor Author

sapell commented Feb 26, 2018

Just tried M206 with Klipper issuing: M206 X0 Y0 Z-0.2 and the apparent zero level was lifted by 0.2mm as expected. Could you Kevin elaborate the relative and absolute offsets you referred to, as to me it seems I just used relative offset with M206 or am I missing something?

@KevinOConnor
Copy link
Collaborator

KevinOConnor commented Feb 26, 2018 via email

@sapell
Copy link
Contributor Author

sapell commented Feb 26, 2018

Thanks! Makes perfect sense now.

@KevinOConnor
Copy link
Collaborator

FYI, I added a new SET_GCODE_OFFSET command (commit 6d03dee). This new command is similar to M206, but provides more flexibility. In particular, it should be well suited for performing "baby stepping" and be a general replacement for M206.

@sapell
Copy link
Contributor Author

sapell commented Apr 21, 2018

Thanks for the info Kevin! I'll try this once I have a good spot. By the way, is it possible to query the currently set G-code offset?

@KevinOConnor
Copy link
Collaborator

KevinOConnor commented Apr 24, 2018 via email

@github-actions github-actions bot locked and limited conversation to collaborators Dec 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants