Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order

    Question about transition from travel to print acceleration

    General Discussion
    3
    10
    227
    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.
    • bot
      bot last edited by bot

      If M204 T is set high, like 3000, and M204 P is set low, to say 300, when the toolhead does a travel move, it accelerates at 3000... but does it decelerate at the P setting or the T setting? I feel like it should decelerate at the P setting, so that there isn't vibration in the tool head when the print move starts. Thoughts?

      *not actually a robot

      deckingman 1 Reply Last reply Reply Quote 1
      • deckingman
        deckingman @bot last edited by

        @bot I'd have thought that it needs to decelerate at the higher rate, otherwise the deceleration phase would have to start much earlier, which might mean that faster non-print moves might never attain the desired target speed. If particular users have problems with their print heads "vibrating", they can always use lower non-print speeds or accelerations, whereras if the behaviour is changed, then all users will be stuck with slower non-print moves. That's my twopence worth seeing as how you asked for thoughts.

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

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

          @deckingman of course the move would be slower if it adhered to lower acceleration values. I just think, if the print acceleration is already lower we're losing a bunch of time there already. You're not saving a lot of time decelerating the travel moves faster (compared to the amount of time you're giving up by accelerating and decelerating all print moves slower).

          I haven't done extensive testing, but during initial observations it seems that there is a direct relation to ringing on that first print move after travel and the travel acceleration value.

          *not actually a robot

          Phaedrux 1 Reply Last reply Reply Quote 0
          • bot
            bot last edited by

            And now, come to think of it, if we're worried about losing time... couldn't we decelerate the last print move before a travel at the travel acceleration value? I think yes, yes we could.

            Acceleration or jerk seem to only disturb the next print move, since a change of direction is implied by accelerating and/or "jerking." Yes/No/Abort?

            *not actually a robot

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

              @bot If your aren't bothered about time, then why bother using a higher non-print acceleration? Just set it all the same for both print and non-print moves. That seems to me to be the simplest solution and won't take up any of DC42's valuable time.

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

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

                @deckingman I'm not asking dc42 to implement this. I'm just asking for a discussion about ideal behaviour.

                Beyond saving time, fast accelerations for travel moves help with stringing.

                *not actually a robot

                deckingman 1 Reply Last reply Reply Quote 1
                • deckingman
                  deckingman @bot last edited by

                  @bot said in Question about transition from travel to print acceleration:

                  @deckingman I'm not asking dc42 to implement this. I'm just asking for a discussion about ideal behaviour............

                  Fair enough. As a (retired) mechanical engineer, I tend to look for mechanical solutions. So my thoughts are that the ideal behaviour you mention would be that there is no tool tool head vibration when decelerating at a faster rate, which carries on into the next move. That's easy to do once you move away from the current preoccupation with reducing mass far beyond the point where that mass itself is a limiting factor. Once you address the mechanical fundamentals of vibration, then you can do pretty much what you want. But I understand that many people aren't interested in that approach so I'll politely duck out now.

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

                  1 Reply Last reply Reply Quote 0
                  • bot
                    bot last edited by

                    If my printer is one thing, it's massive. No matter how massive all parts of a printer are, there is some amount of excitation due to acceleration that will occur, at any acceleration value. This value is usually within the stepper motors' ability to move.

                    I've noticed that with smaller extrusion widths, ringing (vibration) are more noticeable in the prints than at larger extrusion widths. This may merely be due to the smaller trace being a larger proportion of the amplitude of the vibration, which makes the ripples more noticeable.

                    Either way, conceptually speaking, I think the proper way to apply varied acceleration settings for different moves would consider what the purpose of varying the acceleration was in the first place: to optimize print quality. To do this, we must consider what part of the acceleration is affecting the print quality.

                    I've given my observations. I'm wondering if anybody has any observations that counter this idea that the acceleration of the PRECEDING move dictates the ringing in a given print move.

                    *not actually a robot

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

                      @bot said in Question about transition from travel to print acceleration:

                      during initial observations it seems that there is a direct relation to ringing on that first print move after travel and the travel acceleration value.

                      I think I've noticed this as well. In response I've reduced my travel speed and acceleration a bit to a point that I don't notice it. I think I was pushing too hard anyway since I seemed to be getting a lot of layer shifts from curled edges catching during a travel move. A Titan Aero on a Dbot isn't exactly the lightest print head around. My travels are 175mm/s with 2500mm/s2 acceleration 900mm/s jerk for travels set in cura and jerk policy 1. Plenty fast enough for travels still and a bit smoother. Print speeds are typically 50-60mm/s with 800 acceleration and 600 jerk. No ringing to speak of anymore.

                      Z-Bot CoreXY Build | Thingiverse Profile

                      bot 1 Reply Last reply Reply Quote 1
                      • bot
                        bot @Phaedrux last edited by

                        @Phaedrux Thanks for sharing your values! They are similar to mine, except my gantry is obviously much heavier because I don't think I could quite get away with your values and still not see ringing.

                        The way I kind of rooted the problem out is by inserting a tiny but slow move in both x and y at the end of every travel move, which helped the problem but added a lot of unnecessary movement.

                        It's crazy to think about... but some of these long prints have the print axes travelling in the order of multiple kilometers over the course of a day or two. I digress.

                        *not actually a robot

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