Saving Baby stepping value
-
@deckingman The baby stepping feature could be disabled by default, but it would be nice if we had the option to enable it.
Live z-adjust on the Prusa's works this way and for certain situations and setups like what I have, it is more desirable.
I want the users of the printer I am developing to be able to calibrate their z-offset when they receive their printer and then have that value be saved. As I mentioned in my initial post, this printer also has the ability to change out hotends, which may require slight adjustments to the z-offset. It would be nice if when a hotend is changed, the z-offset could be adjusted and then that value would be saved, so the user would not have to use adjust it again until the switched hotends again.
I know all this can be done through the config files, but that is not very user-friendly for the end user. I would like to have them be able to do all of this from the panel on the printer.
If baby steeping needs to stay the way it is, maybe the ability to change the z-offset from the panel could be introduced?
-
@jckray That's one for DC42 then - but I know he's busy at the TCT show right now. Duet does have the functionality to do things like heater tuning and have the results saved to a config-overide.g file which kind of emulates writing to EEPROM. I guess doing the same for Z offset ought to be possible but only David could answer that.
-
@deckingman Okay, if you could pass this along to David, I would really appreciate it.
Thanks for your quick response!
-
@jckray I'm just an end user like yourself so I don't have a direct line to DC42. He's very good at monitoring these forums so I'm sure he'll comment and/or add it to his "todo" list if he thinks it worth while and when he gets time.
-
@deckingman Oh for sure, something about the way you were responding made me think you might work with/for David.
Yes, he has been great about responding to my post in the past!
-
@jckray said in Saving Baby stepping value:
@deckingman Oh for sure, something about the way you were responding made me think you might work with/for David.
Yes, he has been great about responding to my post in the past!
I'm just an early adopter who had one of the first boards and who has been keeping the firmware up to date ever since. So I know the history of the firmware and the reasons why things were added or changed but that's all. Apologies if my post made you think otherwise.
-
@deckingman No worries! I appreciate your input/willingness to help.
-
@jckray Actually, something like what you are asking may already exist with mesh bed compensation. I don't use it myself so can't say for sure.
-
@deckingman Mesh compensation saves the topography of the bed and adjusts for it to keep z=0 consistent across the bed surface. Baby stepping is just another offset applied in addition.
I think the best way to achieve what you're after might be a macro that could automate measuring the Z probe offset with G30 S-1 after a nozzle change and saving it to the config-override.g. I believe M500 already saves changes to G31 probe offset values. https://duet3d.dozuki.com/Wiki/GCode#Section_M500_Store_parameters
So it may already be possible, though I don't normally use M500, so I'm not really sure.
The bonus for this is that Z=0 is still Z=0 and any baby stepping applied after is still applied to that absolute value, which is more consistent. If you were to use baby stepping to set your new Z=0 it would actually be Z=0.2 or whatever for the nozzle to be touching the bed, which could be a bit confusing I think.
Also, i'm not sure how relying on baby stepping would affect other processes like generating a new mesh grid. The real solution is to use G31 to set the real nozzle offset. Baby stepping is intended to be a minor temporary adjustment, using it as a cludge to set the Z offset permanently is just asking for unintended consequences down the road.
-
@phaedrux said in Saving Baby stepping value:
I believe M500 already saves changes to G31 probe offset values.
In later firmware versions the G31 parameters are not written to config-override.g unless you use M500 P31 instead of just M500.
-
Is there a way for the user the set the z offset from the panel? If not would it be possible to add such a feature in the future?
-
@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)
-
@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.
-
@phaedrux yes something along those lines is what I'm looking for
-
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.
-
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.
-
@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.
-
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
-
@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.
-
@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.