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

Separate Accel / Decel Rates

Scheduled Pinned Locked Moved
Firmware wishlist
4
9
640
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.
  • undefined
    CCS86
    last edited by 23 Apr 2021, 22:36

    After doing a lot of testing to find ideal accel and jerk rates for each axis, I realized that even with ideal printing acceleration set, your travel acceleration can still impact your outer wall at the seam.

    Sometimes the travel move is short, when seams are aligned. But other times a longer travel move lands you right at the start of your external wall. This can cause ringing in your outer wall.

    The best thought I have had so far, is to be able to define a separate deceleration rate.

    undefined undefined 2 Replies Last reply 30 May 2021, 20:24 Reply Quote 4
    • undefined
      CCS86
      last edited by 30 May 2021, 19:29

      @dc42 Thoughts?

      1 Reply Last reply Reply Quote 0
      • undefined
        deckingman @CCS86
        last edited by 30 May 2021, 20:24

        @ccs86 said in Separate Accel / Decel Rates:

        After doing a lot of testing to find ideal accel and jerk rates for each axis, I realized that even with ideal printing acceleration set, your travel acceleration can still impact your outer wall at the seam.

        ............................

        Is M204 no good? https://duet3d.dozuki.com/Wiki/Gcode#Section_M204_Set_printing_and_travel_accelerations

        Although acceleration and deceleration rates are the same for each move type (print or travel), it would still give you the ability to set different values for printing vs travel. So for example, if you wanted to use a lower/higher travel deceleration than that use for printing, you could do it with M204. Admittedly, the travel acceleration would also be lower/higher but would that matter?

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

        1 Reply Last reply Reply Quote 0
        • undefined
          CCS86
          last edited by 30 May 2021, 21:42

          No, M204 doesn't provide the benefit I am asking for.

          Typically, you use higher travel acceleration than printing acceleration. This means that on the travel move that takes you to the external perimeter, you get full travel acceleration, which can cause ringing in the print head, just as you begin the outer wall.

          1 Reply Last reply Reply Quote 0
          • undefined
            bot
            last edited by 30 May 2021, 22:31

            Yes I agree completely. I suggested similar here.

            *not actually a robot

            undefined 1 Reply Last reply 30 May 2021, 22:45 Reply Quote 0
            • undefined
              CCS86 @bot
              last edited by 30 May 2021, 22:45

              @bot said in Separate Accel / Decel Rates:

              Yes I agree completely. I suggested similar here.

              Yup, you noticed the same thing that I did.

              I think that your suggestion could potentially work better than defining a mandatory deceleration rate: if a travel move is followed by a print move, apply either the print acceleration rate, or even a new decel rate. This would allow a string of back to back travel moves, to use the higher travel acceleration (like when "avoiding printed parts").

              It's kind of a tricky problem, of when / how to apply this. You could argue, that you only need slower decel when making the move to the external perimeter start point. But, you could also argue that a travel move to any wall needs it, since that ringing could still technically "print" through the external wall (though muted a bit). Then, you have the case of non-connected, solid infill; where you have travel moves connecting every infill line. Would a reduced decel rate cause slowdowns, or are these moves so short that it is a total non-issue?

              undefined 1 Reply Last reply 31 May 2021, 01:44 Reply Quote 1
              • undefined
                bot @CCS86
                last edited by bot 31 May 2021, 01:44

                Great thoughts. IIRC, if we significantly change any of the acceleration on a print it definitely has a surprising impact on print time.

                I've played with modifying PrusaSlicer to see how the seam can be improved. I think there is some room for improvement. I tested out my other zany ideas and they were not beneficial, but my current thinking on getting the best seam would be: decelerate gently into all of the perimeters, because of the 'print-through' of errors to the external, and also to align the perimeter seams, but offset them slightly for each subsequent perimeter going out from in. This way, we can minimize the effect of the "print through." This last part is something I had in mind to test.

                E.g. of the alignment of seams:
                seam.png

                [Edit: Jeez, sorry for the huuuge image and taking this topic off track. This was a long way of saying I think customizing deceleration for certain scenarios could help. We must also remember dc42 has a planned rework of the whole motion system in the mix. Perhaps this is a good time to bring this up, but also maybe it's too much to throw into the first iteration of the new system so it could be added after/with a refactor for a v1.1.]

                *not actually a robot

                1 Reply Last reply Reply Quote 1
                • undefined
                  dc42 administrators @CCS86
                  last edited by dc42 31 May 2021, 07:24

                  @ccs86 said in Separate Accel / Decel Rates:

                  After doing a lot of testing to find ideal accel and jerk rates for each axis, I realized that even with ideal printing acceleration set, your travel acceleration can still impact your outer wall at the seam.

                  Sometimes the travel move is short, when seams are aligned. But other times a longer travel move lands you right at the start of your external wall. This can cause ringing in your outer wall.

                  The best thought I have had so far, is to be able to define a separate deceleration rate.

                  The acceleration will also cause ringing, and some of that ringing will still be present after the deceleration. How much will depend on the length of the travel move and how damped the ringing is. For example, suppose in your print you can see significant ringing lasting for a distance of 5mm from a corner, when printing perimeters at 50mm/sec. Therefore the ringing persists for 0.1sec. If your travel moves are at 200mm/sec then after travel moves up to 20mm long you would still see an effect from ringing caused by acceleration. For longer travel moves, there would be some benefit to allowing higher acceleration. In practice most prints have both long and short travel moves. So the travel acceleration would need to be adjusted depending on the move length.

                  Input shaping will be effective at reducing ringing without having to reduce acceleration and deceleration as much.

                  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

                  undefined 1 Reply Last reply 31 May 2021, 13:03 Reply Quote 1
                  • undefined
                    CCS86 @dc42
                    last edited by 31 May 2021, 13:03

                    @dc42

                    Fair enough. Input shaping is probably the best first pass at all these resonance issues. I'm just worried my Maestro will miss the party.

                    Any ETA shaping up for the first beta?

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