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

    Bed.g repeated execution based on deviation results

    Scheduled Pinned Locked Moved
    Gcode meta commands
    4
    7
    411
    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.
    • MikeSundefined
      MikeS
      last edited by

      Hi everyone!
      Finally i switched from my old wooden delta to a more solid printer (aka Voron 2.4). Right now it's working great with duet2 wifi + duex 5!
      Actually i'm doing the bed auto leveling (4 points with a motor for each point) with the current code in bed.g :

      M561
      
      G30 P0 X50 Y50 Z-99999
      G30 P1 X50 Y300 Z-99999 
      G30 P2 X300 Y300 Z-99999
      G30 P3 X300 Y50 Z-99999 S4
      

      Is it possible to repeat this procedure till deviation reaches a desider threshold? Usually i get 0.010 or less in 2 to 4 cycle...i would like to automate the manual process of calling bed.g manually.

      Thanks!

      OwenDundefined 1 Reply Last reply Reply Quote 0
      • OwenDundefined
        OwenD @MikeS
        last edited by

        @MikeS
        You can place the whole thing in a "while" loop
        There are numerous examples.
        Have a read here

        https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands

        https://forum.duet3d.com/topic/17872/automatic-bed-leveling-with-conditional-gcode-iterations

        1 Reply Last reply Reply Quote 0
        • Vetiundefined
          Veti
          last edited by

          be aware that conditional code need rrf3

          1 Reply Last reply Reply Quote 0
          • MikeSundefined
            MikeS
            last edited by

            Thank you for the suggestion. I did it quickly but right now is acting a little strange... i'll check the documentation better tomorrow and post the macro when it's finished.

            1 Reply Last reply Reply Quote 0
            • MikeSundefined
              MikeS
              last edited by MikeS

              Ok here it is my result files after some experiments:

              bed.g

              echo "---GANTRY LEVELING PROCEDURE---"
              echo "Old deviation was: " ^ move.calibration.initial.deviation
              M561
              echo "Bed transformation cleared."
              if !move.axes[0].homed || !move.axes[1].homed
                echo "Printer was not homed. Homing now."
                G28
              echo "Doing 1st pass"
              M98 P"gantry_level.g"
              while move.calibration.initial.deviation > 0.01
                echo "Current deviation: " ^ move.calibration.initial.deviation
                echo "Deviation over threshold. Executing another pass."
                M98 P"gantry_level.g"
                continue
              echo "Leveling complete. Current deviation: " ^ move.calibration.initial.deviation
              echo "Homing printer to get true z height."
              G28
              

              gantry_level.g

              G30 P0 X50 Y75 Z-99999
              G30 P1 X50 Y325 Z-99999
              G30 P2 X300 Y325 Z-99999
              G30 P3 X300 Y75 Z-99999 S4
              

              I didn't find a way to stop RRF to log to console the leveling data. Is it possible to hide it at start and then enable it at the end of the code?
              Here's an example of what i would like to get rid off:
              screen.png
              Thanks

              1 Reply Last reply Reply Quote 0
              • dc42undefined
                dc42 administrators
                last edited by

                There is currently no means to suppress console output.

                Duet WiFi hardware designer and firmware engineer
                Please do not ask me for Duet support via PM or email, use the forum
                http://www.escher3d.com, https://miscsolutions.wordpress.com

                MikeSundefined 1 Reply Last reply Reply Quote 0
                • MikeSundefined
                  MikeS @dc42
                  last edited by

                  @dc42 Thanks David this isn't a huge problem, only an aesthetic one. Also thanks on the development roadmap for RRF! I can't wait to try a future input shaper implementation!

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