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

    Automatic Bed Leveling with Conditional Gcode Iterations

    Scheduled Pinned Locked Moved
    Gcode meta commands
    5
    79
    6.5k
    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.
    • A Former User?
      A Former User @Kolbi
      last edited by

      @Kolbi said in Automatic Bed Leveling with Conditional Gcode Iterations:

      meaning that no M90 command was needed as M121 sorted that out?

      yes - but more importantly if you for reasons unknown already were in relative mode you would not return to absolute in error.

      Kolbiundefined 1 Reply Last reply Reply Quote 1
      • Kolbiundefined
        Kolbi
        last edited by

        @bearer Ah ok - thanks! Besides rel/nonrel state changes - what would be an additional use case?

        A Former User? 1 Reply Last reply Reply Quote 0
        • A Former User?
          A Former User @Kolbi
          last edited by

          @Kolbi ref M120 docs; i only used for absolute/relative and feedrate

          Kolbiundefined 1 Reply Last reply Reply Quote 0
          • Kolbiundefined
            Kolbi @A Former User
            last edited by

            @bearer Thanks! I'll read the docs again and go for a run to let it soak in.

            1 Reply Last reply Reply Quote 0
            • Kolbiundefined
              Kolbi @A Former User
              last edited by

              @bearer said in Automatic Bed Leveling with Conditional Gcode Iterations:

              already were in relative mode you would not return to absolute in error

              If I'm understanding correctly; If you are in currently in relative positioning and then you issue a G91 again - it would toggle, putting you in absolute positioning?

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

                @Kolbi said in Automatic Bed Leveling with Conditional Gcode Iterations:

                @bearer said in Automatic Bed Leveling with Conditional Gcode Iterations:

                already were in relative mode you would not return to absolute in error

                If I'm understanding correctly; If you are in currently in relative positioning and then you issue a G91 again - it would toggle, putting you in absolute positioning?

                G90 sets the mode to absolute. Sending it again changes nothing.

                G91 sets the mode to relative. Sending it again changes nothing.

                Frederick

                Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                Kolbiundefined 1 Reply Last reply Reply Quote 0
                • Kolbiundefined
                  Kolbi @fcwilt
                  last edited by Kolbi

                  Ok, rgr that. So given the following:

                  M120: Push
                  Example
                  
                      M120
                  Push the state of the machine onto a stack. Called automatically when a macro file is run. It pushes the following values on the stack:
                      Current feedrate
                      Extruder positions
                      Whether moves (and separately extrusion) are relative or absolute
                  
                  
                  M121: Pop
                  Example
                  
                      M121
                  Recover the last state pushed onto the stack.
                  

                  Could use M120 before issuing any homing related current/sensing changes and then instead of changing them all back via individual commands - just use M121? I'm thinking no, but figure it doesn't hurt to ask.

                  I guess what I'm trying to figure out and ask is, what exactly is saved in the 'stack'? Also, the documentation states that M120 is called automatically when a macro file is run - I assume this means any gcode file that resides in the macros directory and that this would not apply to files in the sys directory?

                  BTW, @fcwilt & @bearer Thanks for helping me understand this.

                  fcwiltundefined 1 Reply Last reply Reply Quote 0
                  • Kolbiundefined
                    Kolbi
                    last edited by

                    pushpop.jpg
                    ...Maybe if I get one of these, all will be clear 😂

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

                      @Kolbi

                      Hi,

                      I've never used Push & Pop.

                      Yes there are places where I switch to relative (G91) and shortly thereafter switch back to absolute (G90) but not that many places, primarily in the homing macros.

                      If you were to look at all of the .g files in my sys directory the numbers of G90s or G91s would be small in comparison with all the other code.

                      I've simply never worried about it - I use them as needed.

                      Frederick

                      Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                      Kolbiundefined 1 Reply Last reply Reply Quote 0
                      • Kolbiundefined
                        Kolbi @fcwilt
                        last edited by

                        Thanks @fcwilt, much like what you have stated - I have never used M120/1 and haven't had any issues.

                        But on the other side of the coin, it makes me wonder if I could/should be doing things better by employing it's use? It seems to me, with my limited duet experience, that such command would be most usefully employed by a macro being called while performing an actual print, so that the desired settings set by the slicer would 'pick up where the macro leaves off' & not so important while performing homing evolutions before a print is started.

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

                          @Kolbi

                          I don't rely on the commands my slicer sets at the beginning of a print.

                          Here is my "print begin" macro called by the slicer at the beginning of a print.

                          None of those slicer commands matter because my code overrides them all.

                          ; S3D inserts the following 5 lines of code just before calling this file
                          ;G90                                            ; absolute XYZ moves
                          ;M83                                            ; relative E moves
                          ;M106 S0                                        ; fan off
                          ;M140 S60                                       ; bed temp to 60
                          ;M104 S190 T0                                   ; extruder temp to 190
                          
                          M98 P"test_if_homed.g"				; aborts print if not homed
                          
                          T0                                              ; select tool 0 so extruder commands below will work
                          M703                                            ; configure selected filament (sets bed/extruder temps)
                          
                          M106 P2 S255                                    ; lights on
                          M106 P3 S255                                    ; lights on
                          M106 P4 S255                                    ; lights on
                          
                          G90                                             ; absolute moves
                          G1 Z75      F1200                               ; position for cleaning
                          G1 X0 Y-145 F6000                               ; position for cleaning
                          
                          M291 R"Heating Extruder/Bed" P"Please wait..." T0
                          
                          M116                                            ; wait for temps to reach set points
                          
                          M291 R"Priming Extruder" P"Please wait..." T0
                          
                          G92 E0                                          ; reset the extruder logical position
                          M83                                             ; extruder relative mode
                          G1  E10 F120                                    ; prime the extruder
                          M400                                            ; wait for extruding to finish
                          G92 E0                                          ; reset the extruder logical position
                          
                          M291 R"Clean Nozzle and Bed" P"Click OK to begin printing" S3
                          
                          M98 P"mesh_comp_map_load.g"                     ; load height map based on height map mode
                          
                          
                          

                          Frederick

                          Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                          Kolbiundefined 1 Reply Last reply Reply Quote 0
                          • Kolbiundefined
                            Kolbi @fcwilt
                            last edited by

                            @fcwilt Thanks for that info. Could you achieve the same thing by use of start.g? If not the same because timing with regards of being called by the slicer, what does your start.g contain?

                            Many thanks,
                            Kolbi

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

                              @Kolbi said in Automatic Bed Leveling with Conditional Gcode Iterations:

                              @fcwilt Thanks for that info. Could you achieve the same thing by use of start.g? If not the same because timing with regards of being called by the slicer, what does your start.g contain?

                              Many thanks,
                              Kolbi

                              I haven't gotten around to determining exactly when start.g executes, just too many things on my plate.

                              My current system works but I imagine converting it to rely on start.g would not be a problem.

                              Frederick

                              Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                              Kolbiundefined 1 Reply Last reply Reply Quote 0
                              • Kolbiundefined
                                Kolbi @fcwilt
                                last edited by

                                @fcwilt said in Automatic Bed Leveling with Conditional Gcode Iterations:

                                too many things on my plate

                                I totally understand that. Thanks again for sharing all the info.

                                Cheers,
                                Kolbi

                                fcwiltundefined 1 Reply Last reply Reply Quote 0
                                • Kolbiundefined
                                  Kolbi
                                  last edited by

                                  I updated the first initial post to give a 'bottom line up front', the two efficient ways that were created to level the gantry, for ease of use.

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

                                    @Kolbi

                                    Hi,

                                    Normally I invoke PRINT_BEGIN.g and PRINT_END.g from within the slicer using whatever feature the slicer provides.

                                    START.g was called before the call to PRINT_BEGIN.g. That seems to happen automatically without any action on part of Simply3D (S3D).

                                    PRINT_BEGIN.g was called because I invoked it within S3D in the "Starting Script" option on the "Scripts" tab.

                                    STOP.g was not called at all. It seems the slicer must insert a M0 command at the end of the print to invoke STOP.g.

                                    PRINT_END.g was called because I invoked it within S3D in the "Ending Script" option on the "Scripts" tab.

                                    Since I want a "end of print" macro to execute, without a way to force the slicer to include M0 at the end I will stick with the "Script" options and invoke PRINT_BEGIN.g and PRINT_END.g

                                    If would be nice if START.g and STOP.g would execute without any action on the part of the slicer. Then I could dispense with insuring the slicer invokes PRINT_BEGIN.g and PRINT_END.g

                                    Frederick

                                    Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                                    1 Reply Last reply Reply Quote 0
                                    • Kolbiundefined
                                      Kolbi
                                      last edited by

                                      @fcwilt I understand, thanks!

                                      1 Reply Last reply Reply Quote 0
                                      • A Former User?
                                        A Former User
                                        last edited by

                                        there is also this overview https://duet3d.dozuki.com/Wiki/Macros#Section_System_Macros

                                        fcwiltundefined 1 Reply Last reply Reply Quote 0
                                        • fcwiltundefined
                                          fcwilt @A Former User
                                          last edited by

                                          @bearer said in Automatic Bed Leveling with Conditional Gcode Iterations:

                                          there is also this overview https://duet3d.dozuki.com/Wiki/Macros#Section_System_Macros

                                          Thanks - I had not seen that.

                                          Frederick

                                          Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

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

                                            I use start.g for general print prep. Homing, preheat. Then it passes off to the slicer for setting the temps for the print. Then in the slicer start gcode section it calls a macro to print a prime line and then start the print. I do it this way so that the prime line is printed at the right temp for the material being used.

                                            The slicer end gcode just contains M0 and then stop.g has all of the actual end of print commands.

                                            I kind of wish there was just an end.g that could take the place of M0 -> stop.g

                                            Z-Bot CoreXY Build | Thingiverse Profile

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