Saving Baby stepping value

jckray

@phaedrux said in Saving Baby stepping value:

G30 S-1

So I got around to taking a closer look at this, from what I can tell this would work if the z probe was attached to the removable cartridges and was a fixed distance from the tip of the nozzle.

However, the z probe is attached to the tool head gantry and the tool cartridges mount to this gantry. I want to be able to have the user change the z value in the following line from the panel.

G31 P500 X-25 Y25 Z.9

Basically, I want the "live Z-adjust" feature from the Prusa mk2/mk3. This way the user can print a calibration file and adjust the z-offset until a desirable first layer is reached. This z-offset would then be saved until the user changed again. The distance between the nozzle and the z probe trigger height will likely change by 25-200um between tool cartridges.

I hope I am explaining what I mean in a clear enough way. I attached a couple pictures of my set up to hopefully make what I'm trying to do more clear.

![alt text]( image url)

Phaedrux

@jckray Perhaps M500 could be modified to save the M290 babystepping value to config-override.g so it could be automatically applied at startup.

Then you could just have a test print macro with an M291 S3 at the end asking if you'd like to save the current Z offset permanently.

jckray

@phaedrux yes something along those lines is what I'm looking for

dc42

Suppose I add an option on the M290 command to shift the current babystep offset into the G31 Z parameter, clear babystepping and adjust the Z=0 position to compensate? Then you could set up a macro to run that command and then send M501 P31 to write the new G31 command to config-override.g.

TheLightSpeed

David did you ever implement this? This is my biggest issue with Duet. Prusa allows you to fine tune the Z Offset OT Babystep, then it stays until you change it again. In later firmware Prusa has managed to make profiles so depending on the filament you’re using you can have different offsets. Pretty clever that a Marlin function works so good when Duet requires you to adjust baby stepping every single print.

Arland

@TheLightSpeed said in Saving Baby stepping value:

David did you ever implement this? This is my biggest issue with Duet. Prusa allows you to fine tune the Z Offset OT Babystep, then it stays until you change it again. In later firmware Prusa has managed to make profiles so depending on the filament you’re using you can have different offsets. Pretty clever that a Marlin function works so good when Duet requires you to adjust baby stepping every single print.

Seconding this - really would be great to have this feature.

Phaedrux

@Arland @TheLightSpeed

You can already achieve this either per print or per filament with the start gcode or filaments gcode sections in PrusaSlicer.

If you want it to be per print, add M290 R0 Z0.05 ; set to absolute babystep height to the start gcode section after the printer has been homed. When you want to change it, edit the start gcode.

To then add a modification per filament, add another baby stepping command to the filaments gcode section which is applied after the printer start gcode, so you can now modify it for that filament. M290 R1 Z-0.02 ; modify baby stepping height by -0.02mm

https://duet3d.dozuki.com/Wiki/Gcode#Section_M290_Baby_stepping

com3

@phaedrux I really need to say that the reulctancy to implement this feature properly is really bugging me. The solution you are proposing is none because you still need to fuzz with the start Gcode and/or G31 to get a very very basic thing done. I mean seriously why the hesitancy to add a simple "save offset button" to the interface? (It could then write it as whatever gcode, doesn´t matter) but adding an offset to every print, or fuzzing with start g-code just to set this very simple value is a total nogo for productive use with several operators. I love Duet but it´s things like this which make me think of switching.

This feature has been requested so many times over the years and each time someone ends the discussion with use this or that g-code as if it would be the same OP, me and many others were askingfor, but it´s just not.

deckingman

@com3 said in Saving Baby stepping value:

@phaedrux I really need to say that the reulctancy to implement this feature properly is really bugging me. The solution you are proposing is none because you still need to fuzz with the start Gcode and/or G31 to get a very very basic thing done. I mean seriously why the hesitancy to add a simple "save offset button" to the interface? (It could then write it as whatever gcode, doesn´t matter) but adding an offset to every print, or fuzzing with start g-code just to set this very simple value is a total nogo for productive use with several operators. I love Duet but it´s things like this which make me think of switching.

This feature has been requested so many times over the years and each time someone ends the discussion with use this or that g-code as if it would be the same OP, me and many others were askingfor, but it´s just not.

As an end user (not affiliated with Duet in any way), perhaps the reason it has not been implemented in the way that you personally would like to see, is because it would cause all sorts of problems for other users with different machine configurations to you (e.g. tool changers, idex, or other designs which have multiple tools). In such instances, using baby stepping and then saving that offset as a "global" setting would screw things up for the other tools. So then we need to save the offset on a per tool basis (which we can already do by other means).

The duet hardware and firmware strives to be all things to all users, unlike say the Prusa ecosystem which can be "tuned" to a particular machine configuration. On the one hand, some users scream for features and flexibility, while on the other hand, users scream for less complexity and simpler ways of doing what they want. Whilst I'm not one to defend the Duet team when I think they need their feet holding to the fire, I do have some sympathy in situation like this where they are being required to satisfy all of the users, all of the time.

com3

@deckingman I understand that but anyone who uses their Duet for 3D Printing (which should be like 95% right?) would profit from this very simple feature every single day of usage.

fcwilt

@com3 said in Saving Baby stepping value:

@deckingman I understand that but anyone who uses their Duet for 3D Printing (which should be like 95% right?) would profit from this very simple feature every single day of usage.

For me that is simply not true.

If you find that you would benefit from a persistent baby-step setting it seems likely to me that something is wrong with your printer, your setup or the way you are using your printer.

The only time I need to use baby-stepping (don't like that name) is when I am trying to rush a print and heat related changes have not stabilized.

If I were to find that I needed to use baby-stepping most of the time I would suspect that something has affected by my Z probe readings and I would look for a problem there.

Frederick

com3

@fcwilt Every. Single. Time. someone asks here for a useful solution someone comes along and washes it away by saying the printer is trash.

"The only time I need to use baby-stepping (don't like that name) is when I am trying to rush a print and heat related changes have not stabilized."

That is great for you but I am printing 24/7 with eight toolchanging printer resulting in 32 Extruders which I need to set up and calibrate. I know this is an extreme but it really is a problem (especially after nozzle change) literally any other firmware has a simple solution for. But with duet it is not possible? Come on.

I will try to hack it toghether as a macro and will share it here if it works.

fcwilt

@com3 said in Saving Baby stepping value:

@fcwilt Every. Single. Time. someone asks here for a useful solution someone comes along and washes it away by saying the printer is trash.

"The only time I need to use baby-stepping (don't like that name) is when I am trying to rush a print and heat related changes have not stabilized."

That is great for you but I am printing 24/7 with eight toolchanging printer resulting in 32 Extruders which I need to set up and calibrate. I know this is an extreme but it really is a problem (especially after nozzle change) literally any other firmware has a simple solution for. But with duet it is not possible? Come on.

I will try to hack it toghether as a macro and will share it here if it works.

Nobody said your printer was trash. I merely mentioned areas that I would investigate.

There are relatively simple solutions but persisting baby-stepping is the wrong way to go.

I can think of two off the top of my head. The firmware already has adjustments for different tool characteristics via G10.

Frederick

com3

@fcwilt The biggest problem is the first tool which all the other offsets are applied relatively to. It would just be soooooo easy saving that damn zero point instead of fuzzing around with g-code. Just start a print, check if it´s fine, adjust it if not, save and forget it. And other people think the same about it:

https://forum.duet3d.com/topic/16328/baby-stepping-can-it-or-can-it-not-be-permanent

https://forum.duet3d.com/topic/1226/baby-steps-z-offset

https://www.reddit.com/r/ender3/comments/a4sx14/how_to_save_babystepping_z_values/

https://reprap.org/forum/read.php?415,879905

Also Klipper, Marlin and Repetier offer that feature since years. But as I said, i´ll try to script it.

jay_s_uk

@com3 on my toolchanger, I have the z probe on the tool holder a X0, Y0, Z0 and every other tool is offset from it. Much easier than referencing them all from the first tool

deckingman

The beauty of RRF 3 now that we have conditional gcode is that it's pretty easy to write macros that allow users to tailor the machine behaviour to their own particular needs/wants/desires. There are even examples of code in one or more of the other threads that have been referenced in this thread. So can we move on .....

fcwilt

@com3

Good luck.

I'm sure you can find a satisfactory solution.

Frederick

zapta

@com3, the desire for an out of the box auto saving of the babysteps value is understandable but it also impacts world peace.

One workaround is to save it in the slicer as z-offset.

flobler

@com3 here is how I have implemented it for the Bear Project. I am using Prusaslicer for this:

Everytime after a first layer finishes I am calling the system file "layer_change.g". This happens through the Before layer change G-code in Prusaslicer:

; Before layer change G-code
; called before the print advances to the next layer

G92 E0.0                                                                    ; reset extruder position to 0
{if layer_z == layer_height+first_layer_height}M98 P"layer_change.g"{endif} ; execute layer_change.g
;[layer_z]

So whenever a print switches from 1st to 2nd layer "layer_change.g" is being called:

; layer_change.g
; system file, called on first layer change during a print from Prusaslicer to save applied babysteps to config-override.g
; requires modifications to layer change G-Code in Prusaslicer

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)} ; displays old and new Z probe trigger height
   G31 Z{sensors.probes[0].triggerHeight - move.axes[2].babystep}                                                               ; measures and applies new Z probe trigger height
   M500 P31                                                                                                                     ; saves new Z probe trigger height to config-overide.g

This will add or substract any baby stepping adjustment to your current Z-Offset value and then stores it in "config-override.g" via M500 P31

Additionally I inlcuded the following in "cancel.g" and "stop.g":

M290 R0 S0                            ; reset babystepping to 0
M501                                  ; load saved parameters from non-volatile memory (config-override.g)

This assures that if a print is cancelled or finished, babystepping is reset to 0 and the new value from "config-override.g" is being called.

Now I know this is a workaround more than anything and I would love for this to be implemented in the firmware itself. Our goal is to make 3D printing as easy as possible for everyone and in our opinion this means keeping users away from system, config and macro files for printers where a "out of the box" configuration is published. Ideally users should only have to interact with either the printer display or the webUI. Prusa does a great job with that and this is why so many people can just get started with their printers even though they have no experience at all.

I hope this helps to find your own workaround.

wieman01

Hello,

I know this is an old topic, nevertheless I wanted to quickly see if M500 can by any chance save baby steps (M290) by now. I saw nothing in the documentation, so I don't think this is available, but I thought I'd try my luck.

Thank you.