Duet3D Logo

    Duet3D

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

    Would separate jerk setting for printing/travel be a good thing?

    General Discussion
    8
    27
    1464
    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.
    • burtoogle
      burtoogle last edited by

      On request, I have been adding some more accel/jerk settings into Cura and I am wondering if it would be beneficial to have jerk specified separately for printing and travel moves (i.e. have the jerk equivalent of M204 which can set acceleration separately for print and travel moves)? As it is now, the slicer has to generate a lot of M566 commands when travel and print moves are interleaved. This bloats the gcode and probably has a performance impact also. Any thoughts?

      deckingman 1 Reply Last reply Reply Quote 0
      • Veti
        Veti last edited by

        the duet cant really differentiate between printing and travel moves in all cases.

        the performance impact should not be a problem since the duet print from sd card.
        this can become an issue when printing over serial which has limited throughput.

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

          @burtoogle I'd have thought that it might be difficult to implement in practice. From my (limited) understanding that "jerk" is the instantaneous speed threshold. So for a single travel move, if "jerk" is applied at the start of that travel move, then it must of necessity be applied to the end of the preceding print move. Conversely, to apply a different "jerk" speed to the end of a travel move, then it must of necessity be applied to the beginning of the next print move. So in that scenario, I can't off hand see how "jerk" could be applied differentially between print and non-print moves. I guess what I'm trying to say that there is only one cut off point between print and non-print moves, so one can't apply two different thresholds to that single event.

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

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

            The way Slic3r runs at the moment it would be easy to inject lines to change jerk for moves after slic3r changes to the acceleration speeds set for the travel and or print moves.

            I've got it on my radar to try this so infill is high jerk, but perimeter lower. There is also hints that ideal jerk settings are related to acceleration, so if like me you lower the acceleration for perimeter then the ideal jerk would also change.

            Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

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

              cura already has the ability to set different jerk an acceleration for printing an travel moves.

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

                The point I am making is that RRF already has M204 to set separate accel for print and travel moves so would it make sense to have a similar command for setting the jerk rather than having to have very many M566 commands as you do now when the jerk is being changed due to different jerk being requested for printing and travel moves.

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

                  Wouldn't you effectively get separate jerk settings for printing and moving if you set the jerk for E to the print jerk and X,Y,Z to the move jerk?

                  The firmware would be smart enough to never jerk the move axes faster than the extruder can keep up, so during printing wouldn't this effectively limit the jerk on the move axes to the E axis value?

                  burtoogle 1 Reply Last reply Reply Quote 1
                  • burtoogle
                    burtoogle @SteveYYC last edited by

                    @steveyyc said in Would separate jerk setting for printing/travel be a good thing?:

                    Wouldn't you effectively get separate jerk settings for printing and moving if you set the jerk for E to the print jerk and X,Y,Z to the move jerk?

                    The firmware would be smart enough to never jerk the move axes faster than the extruder can keep up, so during printing wouldn't this effectively limit the jerk on the move axes to the E axis value?

                    Maybe, but I think people would just get confused with two different kinds of jerk.

                    SteveYYC 1 Reply Last reply Reply Quote 0
                    • SteveYYC
                      SteveYYC @burtoogle last edited by SteveYYC

                      @burtoogle

                      It would just be one line in the GCODE:

                      M566 X2000 Y2000 Z2000 E1200

                      where 2000 is the movement jerk in mm/min and 1200 is the extruder jerk in mm/min.

                      I already use a command like this so I'm interested if I'm making an error in my assumptions about whether it's using the higher jerk setting for movement-only and the lower for printing.

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

                        @steveyyc

                        E jerk isn't applied in the way it seems you think it is. The E axis is a linear axis just like X Y Z, etc. For any given feedrate (the speed at which the nozzle travels through physical space) and layer height/extrusion width/filament diameter combination, there is an E axis speed that corresponds. In the case of most typical 3d printer setups, the E axis speeds are much lower than the feedrate when extruding at standard layer heights and extrusion widths.

                        For example, the printing feedrate might be 100 mm/s, but during those printing moves the E axis might be moving 10 mm/s. Note these are not volumetric measurements.

                        What this has to do with what you're saying is that the E jerk (and accel, max speed, etc.) refer to the E axis speed itself. The speeds of the axes are all coordinated to respect the lowest max speed, acceleration, jerk value etc.

                        Basically, the command you showed sets the E jerk at 20 mm/s, which is way higher than is needed to restrict the jerk of the X/Y axes.

                        If, for example, the XY axes instantly change speed to 10 mm/s, the E axis will only need to instantly change speed to about 1 mm/s. Therefore, if you want to restrict the jerk of the X/Y axes, you need to have an E jerk value at least an order of magnitude lower than the XY jerk values.

                        This depends on the individual setup and printing parameters, but generally this is true.

                        That said, there could be downsides to having an E jerk value too low. @deckingman has, I think, experienced some issues in relation to pressure advance and also rounding segmented arcs, as we do when we export meshes into gcode.

                        TL;DR: lower that E jerk value if you wanna try out what you're talking about.

                        *not actually a robot

                        1 Reply Last reply Reply Quote 1
                        • DocTrucker
                          DocTrucker last edited by

                          I'm in favour of a second command but for different reasons.

                          My issues with using 566 are:

                          • There needs to be a command that defines a safe limit for the hardware, and another that allows variations.
                          • Current implementations based on 566 specify jerk limits relative to axis whereas the print and travel limits are relative to the dorection of travel. This results in the jerk changing dependant on angle of the vector.

                          Yes, I have seen ultimaker destined gcode with variations in jerk (M205 I think), but I personally prefer my slicer to not be aligned too closely with any single manufacturer.

                          Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

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

                            @doctrucker I would just like to refer people back to my earlier post because I think it's important. Jerk or more correctly instantaneous speed change is a threshold which gets applied at the boundary between two moves. Therefore, when transitioning between a print and a non print move, there is only one boundary so one can only apply one "jerk" speed to that boundary. So if a different jerk value is used for a single non print move, then it must be applied to the end of the previous print move and to the beginning of the next print move. So it's impossible to have a different jerk value for a single non print move without changing the jerk value for the print moves which are either side of it. Or conversely, if we maintain the integrity of the jerk value for print moves, then it is impossible to apply a separate jerk value for single non print moves.

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

                            DocTrucker 1 Reply Last reply Reply Quote 0
                            • dc42
                              dc42 administrators last edited by

                              RRF doesn't use jerk for travel moves, because it isn't necessary. The only reason for jerk is so that the tool head can follow a gentle curve made up of straight line segments without slowing down whenever the direction changes.

                              That said, I've just realised that jerk is probably not being applied to cutting moves on laser cutters, and I should change that.

                              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

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

                                @dc42 said in Would separate jerk setting for printing/travel be a good thing?:

                                RRF doesn't use jerk for travel moves, because it isn't necessary. The only reason for jerk is so that the tool head can follow a gentle curve made up of straight line segments without slowing down whenever the direction changes.

                                That said, I've just realised that jerk is probably not being applied to cutting moves on laser cutters, and I should change that.

                                Hi @dc42 , thanks for that info.

                                So, if I understand correctly, changing the jerk using M566 for a travel move imbetween two extrusion moves, is, essentially, a no-op? If that is true, I will change Cura so that when generating RRF flavour g-code it doesn't bother trying to change the jerk for travel moves.

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

                                  @deckingman I'm not fussed about the travel moves. They can default to the highest values as defined in the config. I'd like infill some where in the middle and perimeter lower still. It's not as easy to apply as variable acceleration due to the event happening between two vectors but there is already look ahead in the code so this shouldn't be too difficult to work around.

                                  Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

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

                                    @burtoogle said in Would separate jerk setting for printing/travel be a good thing?:

                                    So, if I understand correctly, changing the jerk using M566 for a travel move imbetween two extrusion moves, is, essentially, a no-op? If that is true, I will change Cura so that when generating RRF flavour g-code it doesn't bother trying to change the jerk for travel moves.

                                    Correct. I can't see any advantage to using jerk in travel moves, except that it would make the moves slightly faster. But it would also be more likely to excite ringing.

                                    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

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

                                      @dc42 said in Would separate jerk setting for printing/travel be a good thing?:

                                      @burtoogle said in Would separate jerk setting for printing/travel be a good thing?:

                                      So, if I understand correctly, changing the jerk using M566 for a travel move imbetween two extrusion moves, is, essentially, a no-op? If that is true, I will change Cura so that when generating RRF flavour g-code it doesn't bother trying to change the jerk for travel moves.

                                      Correct. I can't see any advantage to using jerk in travel moves, except that it would make the moves slightly faster. But it would also be more likely to excite ringing.

                                      Thanks, I shall remove the M566 for travel moves in Cura.

                                      Phaedrux 2 Replies Last reply Reply Quote 0
                                      • Phaedrux
                                        Phaedrux Moderator @burtoogle last edited by

                                        @burtoogle Does that mean jerk is being applied to travel moves in the ultimaker firmware?

                                        Z-Bot CoreXY Build | Thingiverse Profile

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

                                          @phaedrux said in Would separate jerk setting for printing/travel be a good thing?:

                                          @burtoogle Does that mean jerk is being applied to travel moves in the ultimaker firmware?

                                          Sorry, I don't know the answer but I would guess, yes. The ultimaker firmware is based on Marlin (I believe).

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

                                            @burtoogle said in Would separate jerk setting for printing/travel be a good thing?:

                                            Thanks, I shall remove the M566 for travel moves in Cura.

                                            @dc42 @burtoogle
                                            How will this change affect the combing travel moves that have direction changes in them? Such as those to avoid crossing perimeters, or to only travel within infill. Wouldn't you want jerk to apply to these moves since they aren't traditional point to point travel moves?

                                            Z-Bot CoreXY Build | Thingiverse Profile

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

                                              @dc42, having just removed the setting of jerk for travel moves in Cura, I took a look at the RRF source. To my horror, it looks like it does do lookahead (and hence uses the instantDv values) between two non-printing moves as the test that controls the call to DoLookahead() simply requires that this and the previous move both involve xy movement and both are either printing or non-printing moves.

                                              Please check the code and tell me that I am wrong so I don't have to go back to the Cura devs and ask for the PR to be reverted!

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

                                                @burtoogle, I am sorry to have misinformed you. You are right, RRF does apply jerk between two non-printing moves. I can see now that there would be a number of issues if it didn't.

                                                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 0
                                                • burtoogle
                                                  burtoogle last edited by

                                                  Hi @dc42. Understood, no problem.

                                                  So a separate setting for travel jerk could be implemented if it was considered worth doing? However, I think the only real benefit would be that it would cut down on the number of M566 commands required when printing areas like skin where you often have very many printing and non-printing moves in sequence. I'm sure you have enough to do though without this. Let's forget this thread.

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

                                                    @burtoogle

                                                    IIRC, jerk and accel settings are not acted upon immediately in RRF. I think it can take a few moves until they kick in.

                                                    I have been advised in the past to avoid dynamically changing accel and jerk within gcode of a print.

                                                    Has anything changed in that regard?

                                                    *not actually a robot

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

                                                      @bot said in Would separate jerk setting for printing/travel be a good thing?:

                                                      IIRC, jerk and accel settings are not acted upon immediately in RRF. I think it can take a few moves until they kick in.

                                                      The jerk value is used in the lookahead queue. As new moves are added to the queue, the latest value of jerk is used to join them to moves already in the queue. Depending on the state of the queue, the firmware may have to look at other moves already in the queue; so the latest jerk valuet might be applied to moves already in the queue too. This is likely to apply to other firmwares as well as RRF.

                                                      What is the purpose of changing jerk in the middle of a print?

                                                      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

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