Suggestion for change to implementation of baby-steps

gnydick

@deckingman it's relevant because it helps understand your workflow.

If you needed baby stepping once and was to print again immediately after, you'd expect the subsequent homing to deliver a different Z position (accurate, rather than needing bs'ing) than the homing that happened as part of the previous print?

Phaedrux

Alright, here's my workflow.

Bltouch is calibrated and usually the first layer is perfect. Occasionally it might be a little too close or a little too far away. Not sure why, it could be temperature differences, or even extrusion factor for each spool. I use a skirt around the part as a judge of what the first layer looks like and use a few baby steps either way to tune it in.

I don't want them to persist, because the next time the printer homes before a print it could be slightly different trigger height again and I'd just have to baby step it anyway.

This is what I don't understand about your proposal, you argue that when a printer is under development you are constantly adjusting it so you want the baby steps to be permanent adjustments, but if it's constantly changing, don't you have to constantly adjust the baby steps anyway?

For me, 9 times out of 10 the first layer is fine with no adjustment, so why would I want to make that 1 out 10 time adjustment permanent? It would just throw off the other 9 times.

I get the live Z adjust appeal for tuning your trigger height once, but isn't it just as easy to do the one time trigger height calibration?

A Former User

To add to Phaedrux how much of a printers life is spent in heavy development for the average user? It simply doesn't make sense to default to persisting a feature to make development convenient when the proposed solution will work just fine. I suspect the actual implementation may not use z-probe offset, but what we call it doesn't really matter as long as there is a simple method for saving it to config-overide.g and it can be automated by simple means if needed.

gnydick

@phaedrux I see how my proposal seems self contradictory. When my printer is under active development, the z offset does change often, but not every print. It'd work fine for a little while, I'd change the printer, and stuff could move, so I'd adjust again. I would often not permanently affix certain parts and overnight something could shift or sag.

This approach allowed me to iterate very, very quickly. I'd use vhb tape to hold many things because of its incredible strength, but it is not perfect, things can settle over time. I'd definitely not trade that practice for having to design things that need screw holes or mounts and them having to be designed with enough strength AND clearance, etc. The mechanical design is much harder then creating something with flat surfaces that can just be slapped together.

deckingman

@gnydick said in Suggestion for change to implementation of baby-steps:

@deckingman it's relevant because it helps understand your workflow.

If you needed baby stepping once and was to print again immediately after, you'd expect the subsequent homing to deliver a different Z position (accurate, rather than needing bs'ing) than the homing that happened as part of the previous print?

I'm not sure that I fully understand your question so to clarify..... If, for whatever reason the first layer of a print wasn't going well, I have 2 options. Option 1 is to abort the print and start again. This will re-home the printer using the same Z offset that is in my configuration file and it will work. I never need to change the Z offset unless I change hot ends which of necessity means re-positioning the switch that is indirectly attached to the nozzle. Option 2 is to continue with the print but to use baby stepping to adjust that first layer as a one off adjustment for this print.

When baby stepping was first introduced, it did not persist in any way so I could start another print straight away and it would start by homing to the original Z offset as defined in my configuration file. Bear with me on this because I use baby stepping very rarely so I might be wrong, but I believe that now, once it has been applied baby stepping will persist until the power has been cycled. If that is the case (I'm fairly sure it is) then if I had used baby stepping and then if I want to do another print, I have to remember to remove the baby stepping that was used as a one-off change for the previous print, before I home the printer again and start another print. This is why it is so important to me to see what baby stepping (if any) has been applied and to have it visible on the UI. So that I can apply the opposite baby stepping to cancel it out before I start another print. Then I can get back to simply homing with the Z offset that is in my configuration file and which works for more than 99% of the time.

So my preferred option would be to have baby stepping reset at the end of every print and not persist in any way, but I accept that I seem too be in the minority so I'll live with it as it is.

However, I would not be at all happy if baby stepping was hidden or if it persisted by making permanent (or even temporary) changes to my configuration files, as you seem to be proposing. The only reason why the configured offset should ever need adjusting is if I physically disturb the switch and thus change the trigger height. I have developed a very good method for setting the offset in that eventuality, which works extremely well on my machine.

A Former User

@dc42 said in Suggestion for change to implementation of baby-steps:

Would the following satisfy most people?

Change it back so that homing Z or bed probing (i.e. any G30 or G1 S1 Z command) cancels the current babystepping.

Add a new command to add the current babystepping into the Z probe trigger height, save the new trigger height to config-override.g if it has changed, and cancel babystepping.

Then for users who don't want babystepping to persist past the current job, it won't. Users who do want it to persist can add the new command into their stop.g and cancel.g files.

For me all works fine, just read this to understand better, and in my head after using duet/RRF2.03 for ca. 3 months, my vote would be:

-> 1) -> Isn´t everybody able to do this by putting "M290 Z0 R0" in home-z & home-all (& maybe calibrate-z & so), or am I getting it still wrong?
If I got it right, maybe just highlight that big and fat in the g-code-wiki? And/or include it in the config.g-generator as standard? That way it stays optional? Come on people, it is one line of code... Just a suggestion for avoiding the wave that might come back here if it is changed...
So +-0 from me here

-> 2) -> remembering how much I struggeled the first weeks to get going with duet/RRF/hardware-issues etc. I assume it can help (even if I have the slight feeling this could be done with a macro?)!
So +1 here

dc42

@lb said in Suggestion for change to implementation of baby-steps:

-> 1) -> Isn´t everybody able to do this by putting "M290 Z0 R0" in home-z & home-all (& maybe calibrate-z & so), or am I getting it still wrong?

That is correct; although if you use a single G30 probe to reset the Z height instead if homing Z, then baby stepping won't be cancelled.

A Former User

I would say the single most important thing is whatever the outcome, there should be no difference between homing the printer and powering it on and homing it.

A Former User

@dc42 said in Suggestion for change to implementation of baby-steps:

@lb said in Suggestion for change to implementation of baby-steps:

-> 1) -> Isn´t everybody able to do this by putting "M290 Z0 R0" in home-z & home-all (& maybe calibrate-z & so), or am I getting it still wrong?

That is correct; although if you use a single G30 probe to reset the Z height instead if homing Z, then baby stepping won't be cancelled.

OOUUHHH O.K. that I can understand. If - for any reason - anybody would do an quick inbetween prints G30-probe update, this might confuse if babysteps are not cancelled?

AND +1 definetly for DWC and duet-display to maybe ALWAYS display somehow small or grey next to the main-screen/main-interface Z-val if e.g. ("incl "x.y mm babysteps" or so to have things clearer? (If I have understood correct some of the above posts?)

(O.K. no reason to answer my sentence here - I might not be able to fully think any more into this and all of the consequences it has, will leave this thread now)

gnydick

I would be happy if the behavior was a config toggle between 2 modes

baby steps never persist across resets of the system, it's up to the end user to manage them, they don't get reset by any command other than the baby step gcode - I believe this is the current behavior
baby steps are treated as a fixture of the calibration of the system, so they persist across resets of the system and all other activity and their display is only via modal windows and the console.

Basically a baby steps vs. live-z switch.