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

    Tuning Jerk/Accel/Speed settings

    Scheduled Pinned Locked Moved
    Tuning and tweaking
    9
    43
    11.7k
    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.
    • Phaedruxundefined
      Phaedrux Moderator @wcj97
      last edited by Phaedrux

      @wcj97 said in Tuning Jerk/Accel/Speed settings:

      if my max speed for my extruder is 6mm/s

      That may be the max for extrusion, but not the max for retraction. So don't set your extruder M203 that low.

      You'll want to set your extruder jerk higher than that as well so that your retractions can be faster and so that pressure advance can quickly change direction.

      The extrusion speed is so low that it doesn't really matter, but retraction and pressure advance can be much quicker.

      The extruder doesn't have a lot of mass to throw around like the other axis do, it's just rotation, so your jerk/accel can be quite high without issue (without skipping of course). Basically you can set the max speed and jerk/accel high enough that they ever really come into play. That allows pressure advance and retraction and the acceleration and jerk of the XY axis to dictate.

      Z-Bot CoreXY Build | Thingiverse Profile

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

        @wcj97 No. "Jerk" doesn't work like that in RRF firmware. Jerk is never applied at the start of a move. (True instantaneous speed change is actually impossible in any case). Think of it as a speed change threshold which gets applied when a the object is in motion and there is a change of direction. So instead of one move slowing down to a complete standstill before the next move starts, the move will slow down to the instantaneous speed change threshold (jerk) instead, and the next move commences at that speed. Given that any print move will be a combination of XY and E, and the speed will be the lowest of any of those axes at any point in time, then the only time that extruder jerk would be applied to a print move is if it is set to give a lower speed than X or Y, in which case it would slow down the entire print move. There are only two (I think) instances where extruder jerk is applied. One is when using pressure advance, and I can't remember the other. But in both cases, setting extruder high rather than low is the way to go.

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

        arhiundefined dc42undefined 2 Replies Last reply Reply Quote 1
        • arhiundefined
          arhi @deckingman
          last edited by

          @deckingman said in Tuning Jerk/Accel/Speed settings:

          Jerk is never applied at the start of a move.

          How does the start of the move look like? I had an assumption that start of the move, since going from 0, will always use acceleration from 0 but I had issues with new Orion sensor triggering falsely and the guy's from precise piezo asked me to set the Z jerk to 0 as Z move would "jump to jerk speed" and that triggers the Orion. I made the change and solved the problem so looks like that jerk value do affect the start of the move.

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

            @deckingman said in Tuning Jerk/Accel/Speed settings:

            "Jerk" doesn't work like that in RRF firmware. Jerk is never applied at the start of a move.

            It does in recent versions of RRF if you set the jerk policy to 1 in M566.

            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

            arhiundefined deckingmanundefined 2 Replies Last reply Reply Quote 0
            • arhiundefined
              arhi @dc42
              last edited by

              @dc42 this is interesting. why would

              M566 X500.00 Y500.00 Z0.00 E6.00

              not trigger my piezo on G30 while

              M566 X1500.00 Y1500.00 Z50.00 E6.00

              will trigger G30 when the bed starts to rise?

              that's the only M566 in all the files, I never set P to 1 ?

              It is confusing me. I kept the M566Z0 as I didn't notice any difference in print behavior between Z0 and Z50 and with Z0 piezo sensor works ok. Why I would like to know how it actually behaves is I was thinking about adding support of RRF to the gcodestat so that I can calculate precise print time from a g-code, but I'm waiting for the few more 3.x versions as I see you are still changing things 🙂

              botundefined Phaedruxundefined 2 Replies Last reply Reply Quote 1
              • deckingmanundefined
                deckingman @dc42
                last edited by

                @dc42 said in Tuning Jerk/Accel/Speed settings:

                @deckingman said in Tuning Jerk/Accel/Speed settings:

                "Jerk" doesn't work like that in RRF firmware. Jerk is never applied at the start of a move.

                It does in recent versions of RRF if you set the jerk policy to 1 in M566.

                I missed that - thanks (and thank goodness its optional)

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

                Phaedruxundefined 1 Reply Last reply Reply Quote 0
                • botundefined
                  bot @arhi
                  last edited by

                  I seem to recall having similar behavior displayed on my machine when commissioning the Z axis. It wasn't related to a piezo probe, but merely the fact that jerk was "being applied" from a stand still. I'm not certain of this, but it rang a bell for sure. I even remember making a thread about my Z axis making noises at one point.

                  *not actually a robot

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

                    @arhi said in Tuning Jerk/Accel/Speed settings:

                    @dc42 this is interesting. why would

                    M566 X500.00 Y500.00 Z0.00 E6.00

                    not trigger my piezo on G30 while

                    M566 X1500.00 Y1500.00 Z50.00 E6.00

                    will trigger G30 when the bed starts to rise?

                    that's the only M566 in all the files, I never set P to 1 ?

                    It is confusing me. I kept the M566Z0 as I didn't notice any difference in print behavior between Z0 and Z50 and with Z0 piezo sensor works ok. Why I would like to know how it actually behaves is I was thinking about adding support of RRF to the gcodestat so that I can calculate precise print time from a g-code, but I'm waiting for the few more 3.x versions as I see you are still changing things 🙂

                    Having Z jerk set to 0 would cause stuttering in X and Y when using mesh bed compensation since it would be trying to slow down to nothing in X and Y while it waited for the Z axis to adjust position.

                    The gcode wiki entry for M566 is instructional here.

                    https://duet3d.dozuki.com/Wiki/Gcode#Section_M566_Set_allowable_instantaneous_speed_change

                    When mesh bed compensation is used, movement may be jerky if the allowed Z jerk is too low, because the Z speed needs to change abruptly as the head moves between squares in the mesh.

                    The default jerk policy is 0, which replicates the behaviour of earlier versions of RRF (jerk is only applied between two printing moves, or between two travel moves, and only if they both involve XY movement or neither does). Changing the jerk policy to 1 allows jerk to be applied between any pair of moves.

                    Z-Bot CoreXY Build | Thingiverse Profile

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

                      @deckingman said in Tuning Jerk/Accel/Speed settings:

                      I missed that - thanks (and thank goodness its optional)

                      I've had good results with jerk policy 1, I think mainly because it reduces the pause time between the end of a print move and the start of a travel move. Since before jerk was only being applied between two consecutive print moves or travel moves, but not between print moves and travel moves.

                      Z-Bot CoreXY Build | Thingiverse Profile

                      botundefined deckingmanundefined 2 Replies Last reply Reply Quote 1
                      • botundefined
                        bot @Phaedrux
                        last edited by

                        @Phaedrux I agree. I could see how it could help alleviate bulging at termination points. I might try it out and see how it goes. If anything, it just makes every move consistent. The beginning and end of every print move would be the same.

                        *not actually a robot

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

                          @Phaedrux said in Tuning Jerk/Accel/Speed settings:

                          @deckingman said in Tuning Jerk/Accel/Speed settings:

                          I missed that - thanks (and thank goodness its optional)

                          I've had good results with jerk policy 1, I think mainly because it reduces the pause time between the end of a print move and the start of a travel move. Since before jerk was only being applied between two consecutive print moves or travel moves, but not between print moves and travel moves.

                          Interesting. But I don't think I'd want to attempt an instantaneous speed change from rest with the 3Kgs of mass that I have to shift. ☺

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

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

                            @deckingman said in Tuning Jerk/Accel/Speed settings:

                            @Phaedrux said in Tuning Jerk/Accel/Speed settings:

                            @deckingman said in Tuning Jerk/Accel/Speed settings:

                            I missed that - thanks (and thank goodness its optional)

                            I've had good results with jerk policy 1, I think mainly because it reduces the pause time between the end of a print move and the start of a travel move. Since before jerk was only being applied between two consecutive print moves or travel moves, but not between print moves and travel moves.

                            Interesting. But I don't think I'd want to attempt an instantaneous speed change from rest with the 3Kgs of mass that I have to shift. ☺

                            Yes, my understanding of it was only between moves. I wasn't aware of it being applied from a resting start. @dc42 would have to clarify.

                            Z-Bot CoreXY Build | Thingiverse Profile

                            botundefined deckingmanundefined 2 Replies Last reply Reply Quote 0
                            • botundefined
                              bot @Phaedrux
                              last edited by bot

                              @Phaedrux AFAIK, in marlin et al, jerk is applied all the time no matter what. Those firmwares are (for some reason, last time I checked) unable to drive the steppers SLOW ENOUGH to start from an actual stop.

                              *not actually a robot

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

                                @bot can't say really, visually and sound to me seem 100% identical between M566Z0 and M566Z50. I cannot differentiate them. What I can say is that Orion does differentiate them as it reads 775-779 when idling and trigger is set to 850. I move to 0,0 wait 5 seconds and do G30 so the bed starts going up if the M566Z50 the second bed starts to go up I get trigger and if M566Z0 the trigger happens only when the bed hits the nozzle. Looking at the movement, listening to a motor, no difference between the two, but there definitely is something different.

                                1 Reply Last reply Reply Quote 1
                                • arhiundefined
                                  arhi @Phaedrux
                                  last edited by

                                  @Phaedrux I did read the manual, but the behavior I'm seeing does not verify what I read there. During first few layers I don't notice any stuttering with M566Z0 but in any case I did change my script to setup M566Z50 normally and I do M566Z0 only during homing and probing. But again, audio/visuals do not show difference between M566Z50 and M566Z0. I never set P to 1 so whatever is default (0 by documentation).

                                  I run now the M566 without parameters and I set Z0 again and looks like I cannot set zero ?! Maybe it has to do with point that it's printing now but again, nothing set M566 to any value but 0 since the machine was turned on today.

                                  2/20/2020, 8:42:50 PM 	M566Z0
                                  2/20/2020, 8:42:52 PM 	M566
                                  Maximum jerk rates (mm/min): X: 500.0, Y: 500.0, Z: 6.0, E: 6.0, jerk policy: 0
                                  

                                  Seems that lowest value for Z is 6.0 ?

                                  Phaedruxundefined botundefined 2 Replies Last reply Reply Quote 0
                                  • Phaedruxundefined
                                    Phaedrux Moderator @arhi
                                    last edited by

                                    @arhi yes. Right below the section I quoted from the wiki it states the minimum as 0.6mm/s

                                    Z-Bot CoreXY Build | Thingiverse Profile

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

                                      @Phaedrux said in Tuning Jerk/Accel/Speed settings:

                                      .................. Yes, my understanding of it was only between moves. I wasn't aware of it being applied from a resting start. @dc42 would have to clarify.

                                      That's two of us then ☺ I wrote "Jerk" doesn't work like that in RRF firmware. Jerk is never applied at the start of a move." To which DC replied "It does in recent versions of RRF if you set the jerk policy to 1 in M566."

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

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

                                        @arhi are you positive the Z axis is only moving in one direction when it triggers the piezo? Is the probe command moving the z axis a tiny bit in one direction first? Is any other type of Z compensation enabled when this occurs?

                                        *not actually a robot

                                        arhiundefined 1 Reply Last reply Reply Quote 1
                                        • arhiundefined
                                          arhi @bot
                                          last edited by

                                          @bot I'm not sure of anything 😞 not easy to see things clearly with all this glass and acrylic. It does look like the bed is put into position and then sits still 3sec as configured and then goes up towards the nozzle. If I set jerk to 0 it works ok, if I set jerk to 60 the start of the movement triggers the piezo.

                                          In any case, none of this is a problem for me, I made it work with analog output and I'm happy with it. It's just confusion about what I'm reading and what I'm seeing first hand. It would be cool to properly understand the behavior that's all.

                                          botundefined 1 Reply Last reply Reply Quote 1
                                          • botundefined
                                            bot @arhi
                                            last edited by

                                            @arhi I'm glad you got it sorted out!

                                            It's still puzzling that the Jerk value would affect anything in that scenario.

                                            I wish I myself was capable of understanding the source code. I would love to check things over myself but I'm not able to. Not that I don't trust or love the firmware, but there have been a few instances where errant behaviour has gone undetected so I like to highlight problems, no matter how small, when they arise, so they can get attention if they need it.

                                            *not actually a robot

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