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

    What Defines Printing vs Travel Moves?

    Scheduled Pinned Locked Moved
    General Discussion
    5
    11
    496
    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.
    • deckingmanundefined
      deckingman @CCS86
      last edited by

      @CCS86 That's a simple question on the face of it, but on reflection, the answer comes from a conversation you have with yourself and or your slicer. Essentially any move command consists of a distance or distances and a feed rate (speed). If no feedrate is specified, then the previous feedrate is used. But all moves are synchronised. That is to say that any axis must start and end it's movement at the same time and in that regard, extruders are treated as axes. So for example a G1 Xn Ynn Ennn command, means move in the X direction a distance of n, in the Y direction a distance of nn while extruding nnn mm of filament. In that case, because the extruder must start and end it's move at the same times as the X and Y axes, then it is likely that the X and Y speeds would have to be reduced regardless of the specified feed rate. Does that constitute a print move? The answer is probably yes. But what if the G1 command was say G1 X200, Y200, Z1 F3000? In this instance we are saying move X and Y 200 mm but Z only 1 mm. Because the Z axis move is so small, and because it must start and end at the same time as the X and Y axes, then it is likely that the X and Y axes will run much slower than the specified feedrate, similar to the XYE move. Does that also mean that it's a print move? The answer might be no but in terms of the time it takes to complete the move or the overal feedrate, then the outcome would be similar to an XYE "print" move.

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

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

        @CCS86 a printing move is one that includes both forward extrusion and X and/or Y movement (before any remapping of X or Y to other axes occurs).

        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

        1 Reply Last reply Reply Quote 1
        • CCS86undefined
          CCS86 @deckingman
          last edited by

          @deckingman I appreciate the reply and realize now that I should have given the context that this question was specific to how RRF applies the M204 limits.

          I have a suspicion that SuperSlicer isn't applying accel limits correctly.

          deckingmanundefined 1 Reply Last reply Reply Quote 0
          • gumbyundefined
            gumby @CCS86
            last edited by

            @CCS86 I always think of travel moves as rapids. G0. But I would second that printing moves involve the extruder. G1

            Cheers,
            Gumby

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

              @CCS86 said in What Defines Printing vs Travel Moves?:

              @deckingman I appreciate the reply and realize now that I should have given the context that this question was specific to how RRF applies the M204 limits.

              I have a suspicion that SuperSlicer isn't applying accel limits correctly.

              Yes, I forgot that M204 allows for different accelerations. AFAIK, M204 sets the acceleration for moves as whole based on what DC said is the RRF definition of a print move vs a travel move, but that the limits set by M201 still apply. I guess you should search a sliced gcode file for any M201 and M204 commands in order to find out what the slicer is doing.

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

              1 Reply Last reply Reply Quote 0
              • CCS86undefined
                CCS86
                last edited by

                Professionally, I program 4 and 5 axis machine tools, so in general G00 are rapid travel moves, and G1 / G2 / G3 are cutting feed moves. Although, some paths use fast feed moves for positioning (to provide a more reliable path), so there are always exceptions.

                I just wanted to make sure I understood the M204 function before bugging the SS dev. He has a massive backlog right now, and I really hope he can eventually catch up.

                oliofundefined 1 Reply Last reply Reply Quote 0
                • oliofundefined
                  oliof @CCS86
                  last edited by

                  @CCS86 one of the main "shortcuts" most 3d printer firmwares take is treating G0 like G1, so beware (-;

                  <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

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

                    @oliof said in What Defines Printing vs Travel Moves?:

                    @CCS86 one of the main "shortcuts" most 3d printer firmwares take is treating G0 like G1, so beware (-;

                    Yes, RRF treats G0 moves and G1 moves the same in most respects when in FFF mode because that is what slicers that generate G0 moves expect. Whereas in CNC mode, G0 moves are executed at the maximum speed set by M203.

                    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

                    oliofundefined 1 Reply Last reply Reply Quote 2
                    • CCS86undefined
                      CCS86
                      last edited by

                      https://github.com/supermerill/SuperSlicer/issues/3821

                      CCS86 created this issue in supermerill/SuperSlicer

                      closed Acceleration Control: "Decel w/ Target" Broken [RRF] #3821

                      1 Reply Last reply Reply Quote 0
                      • oliofundefined
                        oliof @dc42
                        last edited by

                        @dc42 today I learnt!

                        <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

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