Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Saving Baby stepping value

    Scheduled Pinned Locked Moved
    Firmware wishlist
    12
    34
    4.7k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • com3undefined
      com3 @fcwilt
      last edited by 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.

      fcwiltundefined 1 Reply Last reply Reply Quote 0
      • fcwiltundefined
        fcwilt @com3
        last edited by

        @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

        Printers: a small Utilmaker style, a small CoreXY and a E3D MS/TC setup. Various hotends. Using Duet 3 hardware running 3.4.6

        1 Reply Last reply Reply Quote 0
        • com3undefined
          com3
          last edited by

          @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_ukundefined fcwiltundefined 2 Replies Last reply Reply Quote 0
          • jay_s_ukundefined
            jay_s_uk @com3
            last edited by

            @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

            Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

            1 Reply Last reply Reply Quote 0
            • deckingmanundefined
              deckingman
              last edited by

              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 .....

              Ian
              https://somei3deas.wordpress.com/
              https://www.youtube.com/@deckingman

              1 Reply Last reply Reply Quote 2
              • fcwiltundefined
                fcwilt @com3
                last edited by

                @com3

                Good luck.

                I'm sure you can find a satisfactory solution.

                Frederick

                Printers: a small Utilmaker style, a small CoreXY and a E3D MS/TC setup. Various hotends. Using Duet 3 hardware running 3.4.6

                1 Reply Last reply Reply Quote 0
                • zaptaundefined
                  zapta @com3
                  last edited by

                  @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.

                  1 Reply Last reply Reply Quote 0
                  • floblerundefined
                    flobler
                    last edited by 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.

                    1 Reply Last reply Reply Quote 2
                    • gloomyandyundefined gloomyandy referenced this topic
                    • wieman01undefined
                      wieman01
                      last edited by

                      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.

                      Phaedruxundefined 1 Reply Last reply Reply Quote 0
                      • Phaedruxundefined
                        Phaedrux Moderator @wieman01
                        last edited by

                        @wieman01 The post above yours describes a way to do it.

                        Z-Bot CoreXY Build | Thingiverse Profile

                        1 Reply Last reply Reply Quote 1
                        • First post
                          Last post
                        Unless otherwise noted, all forum content is licensed under CC-BY-SA