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
Comments
|
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. |
|
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... |
|
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. |
|
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. |
|
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). |
|
Thanks for the tip Kevin! |
|
Thank you, didnt know that either ! |
|
Just tried M206 with Klipper issuing: |
|
On Mon, Feb 26, 2018 at 12:54:09PM -0800, Simo Apell wrote:
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?
I've never used M290, but if I understand it correctly, if you issued
"M290 Z.05", "M290 Z.05", and "M290 Z.05" then you'd have a total lift
of .15. However, if you did the same thing three times with "M206
Z-.05", you'd have a total lift of .05 as each command doesn't add to
the offset - it sets the absolute offset on each invocation. Perhaps
absolute/relative was a poor wording choice, and absolute/addtive
would have been better?
Again, I could be wrong about M290.
…-Kevin
|
|
Thanks! Makes perfect sense now. |
|
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. |
|
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? |
|
On Sat, Apr 21, 2018 at 12:03:37PM -0700, Simo Apell wrote:
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?
There is the M114 and the GET_POSITION commands.
…-Kevin
|
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.
The text was updated successfully, but these errors were encountered: