Baby Stepping.. can it, or can it not be permanent?

[bot]

@zapta Hahaha. I concur.

In all seriousness, the issue LeckieTech mentions is because dc42 changed the behaviour for people who complained that the babystepping was reset on homing.

Now, the babystepping value is retained through homing, but the babystepping amount is also added to the M208 homing location for the Z axis. So, the offset indeed does add up if you don't manually cancel the babystepping offset before homing.

So, the current behaviour is problematic, but the way to fix it is to revert it to the previous behaviour, where it is completely reset after homing, and all set offsets and M208 values are respected exactly as they are in the configuration.

[OwenD]

Based on further reading of this thread I have revised my code to suit all sides of the argument

;save_babystep.g
if move.axes[2].babystep !=0
      while(true)
            M291 P"Save baby stepping?"  S2
            echo "Shouldn't you edit config G instead?"
            echo "no, I want the firmware re-written"
            echo "but why?, just use a macro"
            echo "because I want it!"
            echo "fine... go ahead"
       

[bot]

@OwenD omg I totally missed that before! Great! hahah. I guess mine is the RRF2 version.

[deckingman]

@PuterPro said in Baby Stepping.. can it, or can it not be permanent?:

@deckingman said in Baby Stepping.. can it, or can it not be permanent?:

You listed several things you'd like implemented, does that mean the OP doesn't have the right to request his? Someone elses' needs and wants should be honored too, eh? It's OK for people to request a feature change that you don't use or need.

Woah, hold on my friend. There is a world of difference between adding something that makes life slightly easier than editing one line of gcode, and restoring basic printer functionality to the firmware, which are the things that I'd like to see implemented.

The current state of firmware is that nobody who has a heater connected to expansion board can PID tune that heater. That's what I call basic functionality. Nobody who uses a mixing hot end with Duet 3 can utilise it fully because the step pulse frequency has been reduced, which limits the extruder micro-stepping. Again, that's not a case of making something a little more convenient, it's basic functionality which used to exist but now does not.

I changed over to Duet 3 last August to help the Duet guys by having my machine in their stand at the TCT show and I spent hundreds of hours testing pre-beta firmware for them. But I haven't been able to PID a hot end heater connected to an expansion board since then. It will be 3.02 at some time in the future before I ever will be able to do it. But I'm not whining about it. It's the price one has to pay (although if I'd known the full price, it's fair to say that I would not have made the conversion but it's too late now to go back to Duet 2).

I'm working on new hot end and I've had to tune heaters dozens of times. To do so, I have to disconnect the heater and thermistor from the expansion board, connect it to the main board, edit my configuration, run the heater tune, put my configuration back to what it was, disconnect the heater and thermistor from the main board and re-connect them to the expansion. And people think that editing one line of gcode is inconvenient!

The point I tried to make is that the more time the developers spend making life a little more convenient than editing one line of gcode, is time that could be spent restoring existing features that used to work but now don't. But I guess this will all fall on deaf ears and it'll be another year before I can get my printer working as it used to with Duet 2 because the developers are busy implementing "feature" to make life a little easier than editing one line of gcode now and then.

[DeltaCon]

@deckingman said in Baby Stepping.. can it, or can it not be permanent?:

Let's go the whole hog. Why stop with having a button to make baby stepping permanent instead of editing one value in config.g? Let's have another button that will set the steps per mm for extruders after we've calibrated them - one button for each extruder ideally. Then another button when we tune firmware retraction to save us editing config.g for that. The same for pressure advance and all the other things we have to tune.

Most things you mention are set and forget type of settings. Nozzle offset is not, it needs to be tuned from roll to roll, or evan after many other changes.

With enough buttons, we need never open config.g at all.

That's basically the idea of having a GUI, isn't it?

Look people, it is just not worth any more fuzz. It is certainly no dealbreaker for me. I did not invent the subject. I just think it is a plausible feature that got fired down with not enough valid arguments.

[A Former User]

I find myself wondering why does the thread go on - I thought Owen put a fork in it with his macro?

I completely support the notion that "trivial" conveniences are best left to the community when the developer resources are limited, and such it has been solved? Or if its too much to ask to use the macro I guess daemon.g can check for baby stepping and persist it as needed?

[dc42]

@bearer said in Baby Stepping.. can it, or can it not be permanent?:

I find myself wondering why does the thread go on - I thought Owen put a fork in it with his macro?

Exactly. That's why I haven't posted to this thread until now.

[PuterPro]

We do need to put a fork in this whole thing, a few comments for clarity -

@deckingman said in Baby Stepping.. can it, or can it not be permanent?:

Woah, hold on my friend. There is a world of difference between adding something that makes life slightly easier than editing one line of gcode, and restoring basic printer functionality to the firmware, which are the things that I'd like to see implemented.

I could not agree more! I absolutely agree that the things you're pushing for should have priority over such a silly thing as Baby steps being optionally persistent. I was just commenting on it being dismissed out of hand by someone who doesn't use it, and offering a case scenario where I could see it's validity ... if you get my drift. (And I AM drifty ... LOL!)

@bot said in Baby Stepping.. can it, or can it not be permanent?:

This request, beaten to death, is already achievable with the current behaviour .... add a line at the end of your config.g that runs a macro with M98 .... Done. It will save your magic sequence of babystepping settings to load every time you boot.

Thank you for getting I wasn't berating you, it's sometimes hard with just text and an emoji or two ...
THAT's a simple way to accomplish this, thanks for that, now we have a couple solutions. Personally I rarely use Baby Steps but I have found it handy at times.

@OwenD Hilarious!! Love it. And thanks for the solutions, I confess to a misread of your earlier posts ALSO being in humor. Working on my halo ...

@DeltaCon said in Baby Stepping.. can it, or can it not be permanent?:

It is certainly no dealbreaker for me. I did not invent the subject.

@ ALL - This sums up my involvement as well. I apologize for extending this so long when obviously there are multiple ways to solve this without changing the firmware. Many thanks to all that participated!!

[bot]

@PuterPro My dude, tone is difficult even in real life. Sorry if I come across as belligerent sometimes. I'm only intending on being a tiny bit belligerent.

[PuterPro]

@bot said in Baby Stepping.. can it, or can it not be permanent?:

@PuterPro My dude, tone is difficult even in real life. Sorry if I come across as belligerent sometimes. I'm only intending on being a tiny bit belligerent.

Especially for Engineer / Tech types who tend towards awkwardness in all social situations! LOL

Peace out!

[A Former User]

@PuterPro said in Baby Stepping.. can it, or can it not be permanent?:

@bot said in Baby Stepping.. can it, or can it not be permanent?:

@PuterPro My dude, tone is difficult even in real life. Sorry if I come across as belligerent sometimes. I'm only intending on being a tiny bit belligerent.

Especially for Engineer / Tech types who tend towards awkwardness in all social situations! LOL

Peace out!

As a mechanical engineer, no social awkwardness, I just get accused of being a cu** because I very bluntly tell the truth.....

[yufanyufan]

@OwenD

This script is very useful!
It is possible to improve it, so the baby step can be reset?

To tune the babystep, I usually reset it to zero, home z, and insert a piece of paper under hotend. Be able to reset babystep to zero is important to me.

[OwenD]

@yufanyufan

M290 R0 S0 ; clear babystepping

[Baenwort]

Cross post wrong me

[yufanyufan]

@OwenD

M290 R0 S0 does not work with your save script, because the script changed G31.

[OwenD]

@yufanyufan said in Baby Stepping.. can it, or can it not be permanent?:

@OwenD

M290 R0 S0 does not work with your save script, because the script changed G31.

Define "does not work"
M290 R0 S0 will set baby steps to zero.
This will stop it being added again if the macro is run again before a restart, but won't restore your original G31 value.
If you want your old values back, don't run the macro.
I can't see a reason for running it twice in any print session either. If you have that much variation then I'd suggest fixing it rather than embarking on endless adjustments to offsets.
If your usage requirements are different to what the code does, then change the macro to suit yourself.

[jens55]

@OwenD said in Baby Stepping.. can it, or can it not be permanent?:

@yufanyufan said in Baby Stepping.. can it, or can it not be permanent?:

@OwenD

M290 R0 S0 does not work with your save script, because the script changed G31.

Define "does not work"

Not the original poster but I can confirm that weird shit happens
LOL ... how is that for a definition?

M290 R0 S0 will set baby steps to zero.

Yes

This will stop it being added again if the macro is run again before a restart, but won't restore your original G31 value.
If you want your old values back, don't run the macro.
I can't see a reason for running it twice in any print session either.

This can (and did) happen to me because my printer stays on 24/7 and sometimes you forget that the script was run or you hit it twice by accident or a myriad of other things that can go wrong.

The updated macro I am now using is

; 0:/macros/Save-Z
; This macro adds the current babystep offset to the Z trigger height and saves it to config-overide.g
; ! M501 needs to be in config.g to automatically be recalled on reset. If using multiple filament settings,
; and this is for a specific filament type, recommend placing this yielded information in the filament's config.g.

if move.axes[2].babystep !=0                                ; If no babysteps are currently adjusted - exit routine
   echo {"OLD: " ^ sensors.probes[0].triggerHeight ^ " NEW: " ^ sensors.probes[0].triggerHeight + (move.axes[2].babystep * -1)}
   G31 Z{sensors.probes[0].triggerHeight - move.axes[2].babystep}
   echo {"Place either M501 -or- G31 Z" ^ sensors.probes[0].triggerHeight^ " in your config.g"}
   M500 P10:31                                              ; save settings to config-overide.g - G31 P31 saves trigger height, 
                                                            ; trigger value, and X and Y offsets for each possible Z probe type 
                                                            ; P10 parameter saves the G10 tool offsets.
   M290 R0 S0 												; clear babystepping 

else
   echo "Baby stepping is not currently employed, exiting."

Which has the babystep clearing at the end and also fixed an error in line 9

Note that have NOT fixed the 'weird shit' yet because I haven't quite wrapped my mind around it yet. It likely happens because of the change in G31 and the z position that the Duet printer thinks it is at (or something in that neighborhood). I believe that a reboot of the Duet after saving the new Z offset will get everything in sync and prevent the 'weird shit' (no guarantees though)

[jens55]

This is an example of the weirdness encountered:

Note that I did a save.z (the above macro) and it did it just fine.
I did not reboot as far as I remember.
Later on I tweaked baby steps some more and the system reported the old and new Z settings just fine but then it somehow screwed up the Z offset by a huge amount. The Z offset saved to config-override.g is the crazy high amount.

If I did a 'home z' now by accident, the nozzle would probably bury itself in the build plate. Tried that earlier, was not a happy camper ... but thankfully nothing broke!

Edit:

Could it be that it is not safe to run the macro while the printer is doing it's thing ? I was running a print job, adjusted the babystep value as the printer was printing and then executed the save z macro. This may be what causes the bad Z offset value (not thoroughly tested yet)

I do not know the object model well enough to figure out why the crazy Z value would show up. Is there a possibility that the given parameters are not valid in the middle of a print ?

[OwenD]

@jens55
I was able to replicate your experience by running the macro multiple times.
i.e. I put the whole thing in a loop by putting

while iterations < 9
M290 S-0.1
at the start and indenting accordingly.

The problem seems to be that if there is any mesh compensation active it is added when you do the G31.
In fact it seems to be a compounding error.

I don't see why you would want to run it more than once (and I definitely can't see a case for doing it during a print), but in the interests of preventing accidental errors, I suggest you try this.
Add
G29 S2

;save_babystep.g
; Add babystep to Z offset and make "persistant"

; If the printer hasn't been homed, home it
if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
  G28


if move.axes[2].babystep !=0
	G29 S2 ; clear bed mesh compensation
	echo {"Z trigger height altered by " ^ move.axes[2].babystep ^  "mm"}
	echo {"Old: " ^ sensors.probes[0].triggerHeight ^ " New: " ^ sensors.probes[0].triggerHeight - move.axes[2].babystep}
	G31 Z{(sensors.probes[0].triggerHeight) - (move.axes[2].babystep)}
	M500 P31:10
	M290 R0 S0 ; clear baby-stepping
else
	echo "No baby-stepping set.  Nothing to save"

Without clearing the mesh, this was the result of the loop with -0.1mm baby step being set each iteration.

After clearing the mesh, the result was as expected.

[jens55]

Interesting .... this appears to be another , different , problem though.
Note that in my example the Z compensation jumped from 4.150 mm to 162.85 mm which has likely nothing to do with the bed mesh compensation (way too large). Also, in your example it seems to happen consistently and in my example it does not.
Does G29 S2 disable (as in temporarily) the mesh compensation or does it toss the bed mesh map (that takes me around 3 hours to run) completely?
In your modified macro, is mesh bed compensation turned back on anywhere else as it doesn't appear to be turned on in the macro?

I will not have time to dig into this today ... possibly tomorrow.

As for doing it multiple times - in my case I adjusted Z offset, saved it and later determined that I needed to tweak it a bit and saved it again.
Saving during a print comes naturally just as you tweak the babysteps during a print (well for me it does)