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

    Issues with pressure advance since RRF 3.4

    Scheduled Pinned Locked Moved
    General Discussion
    46
    308
    38.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.
    • gloomyandyundefined
      gloomyandy @Heartleander81
      last edited by

      @Heartleander81 Yes please start a new thread and provide details of what you think the change is, though honestly if there was a change in something like this I would have expected to see lots of comments about it already....

      jay_s_ukundefined 1 Reply Last reply Reply Quote 0
      • jay_s_ukundefined
        jay_s_uk @gloomyandy
        last edited by

        @gloomyandy its probably the change between stealthchop being default to spreadcycle being default...

        and I better run some more tests. @Argo do we have a consensus on the test piece? your one with curves and a square in the middle or just a 40 x 40 x 2 cube?

        Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

        Argoundefined 1 Reply Last reply Reply Quote 0
        • Argoundefined
          Argo @jay_s_uk
          last edited by

          @jay_s_uk

          I've made a more efficient version of the model to save time and filament:

          bulgecheckV2.stl

          I would set the seam to rear. Otherwise it'll be at one of the corners.

          @gloomyandy
          Yep it's a total pain as I would need to rewire all the chains. My Klipper test was just a dirty hang all wires along the frame to the top and to the tool head method. And during the test I held the wires to they don't get caught lol.

          gloomyandyundefined 1 Reply Last reply Reply Quote 0
          • gloomyandyundefined
            gloomyandy @Argo
            last edited by

            @Argo Does that mean you can't easily run any further Klipper tests?

            Argoundefined 1 Reply Last reply Reply Quote 0
            • Argoundefined
              Argo @gloomyandy
              last edited by

              @gloomyandy

              I can but not for weeks as it’s quite the mess here and not really safe to print unattended. 😄
              I can print the test again with adjustments to flow and PA. I’ll post the results soon.
              Inputshaping does not decrease print quality with Klipper as long you stay within the recommended acceleration settings.

              gloomyandyundefined 1 Reply Last reply Reply Quote 0
              • gloomyandyundefined
                gloomyandy @Argo
                last edited by

                @Argo I'd rather you keep input shaping off with Klipper (and with RRF) as that just simplifies things (as it does seem to have an impact on RRF).

                Argoundefined 1 Reply Last reply Reply Quote 0
                • Argoundefined
                  Argo @gloomyandy
                  last edited by

                  @gloomyandy

                  Bumped PA up from 0.05 to 0.052. I think maybe 0.054 could be the optimal value.
                  Decreased flow a tiny bit to improve top layer quality.

                  image2.jpg
                  (Klipper)

                  The result is quite comparable to what I get with RRF with "dynamic PA" (0.05 -> 0.08).
                  Sorry that I had to switch color. The bright green is empty after tons of testing.

                  gloomyandyundefined 1 Reply Last reply Reply Quote 0
                  • gloomyandyundefined
                    gloomyandy @Argo
                    last edited by

                    @Argo No problem, could you post your klipper and slicer settings (maybe post the gcode file you used with Klipper as that will have a lot of the details in it).

                    Argoundefined 1 Reply Last reply Reply Quote 0
                    • Argoundefined
                      Argo @gloomyandy
                      last edited by

                      @gloomyandy

                      BulgeCheck.gcode

                      For Klipper itself nothing fancy.
                      square corner velocity = 5 mm/s
                      max feedrate = 350 mm/s
                      max acceleration = 5000 mm/s

                      Slicer speed settings:
                      9bd79d70-e1af-4b57-bedb-6a01d69502b7-image.png

                      1 Reply Last reply Reply Quote 0
                      • gnydickundefined
                        gnydick
                        last edited by

                        Been following this thread for a while now, 🎧 , and wondering if there's been any concrete, official update?

                        Argoundefined 1 Reply Last reply Reply Quote 0
                        • Argoundefined
                          Argo @gnydick
                          last edited by Argo

                          @gnydick

                          Latest official statement is that the Duet team can't reproduce the issue so I assume there won't be a fix. That's why I'm glad I found a partial fix by using Super Slicer extrusion roles:
                          https://forum.duet3d.com/post/298231
                          At the moment I'm using 0.052 PA for every role except perimeter which use 0.075 PA (PLA filament).

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

                            @Argo said in Issues with pressure advance since RRF 3.4:

                            @gnydick

                            Latest official statement is that the Duet team can't reproduce the issue so I assume there won't be a fix. That's why I'm glad I found a partial fix by using Super Slicer extrusion roles:
                            https://forum.duet3d.com/post/298231
                            At the moment I'm using 0.052 PA for every role except perimeter which use 0.075 PA (PLA filament).

                            As you found, that isn't great though, since the change in PA causes the printer to dwell.

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

                              From my own testing a while ago I had noticed a difference in extruder jerk when I was getting some bulging corners. After retuning E jerk and PA it improved.

                              Has anyone noticed a difference in E jerk?

                              Z-Bot CoreXY Build | Thingiverse Profile

                              gnydickundefined Heartleander81undefined 2 Replies Last reply Reply Quote 0
                              • gnydickundefined
                                gnydick @Phaedrux
                                last edited by

                                @Phaedrux possibly. It at least seems to be very sensitive to it. Right now, with even just a low poly curved surface, each segment is ~1.5mm long, I get a bulge at every direction change.

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

                                  @Phaedrux

                                  Yes, definitely.
                                  If I increase or decrease the extruder pressure, I can influence whether there is more or less overshoot. But I can't get rid of it completely.

                                  1 Reply Last reply Reply Quote 0
                                  • Argoundefined
                                    Argo @CCS86
                                    last edited by

                                    @CCS86

                                    Yes it’s far from optimal. But at least parts are usable again. Though I had Klipper flashed and it hasn’t the flaws I’m not really into using Klipper. Just a personal preference. But wouldn’t wonder if someone switches because of that.

                                    Heartleander81undefined 1 Reply Last reply Reply Quote 0
                                    • Heartleander81undefined
                                      Heartleander81 @Argo
                                      last edited by

                                      @Argo

                                      I will only use it as an emergency backup. Sure if RRF fits again I'll switch back, I think. I'm already a fan of Duet.
                                      But to test whether my hardware fits, I'll try Klippers. The last parts will arrive in the days for the test with me.

                                      1 Reply Last reply Reply Quote 0
                                      • jens55undefined
                                        jens55
                                        last edited by

                                        I don't know if this helps but I decided to run some tests. Two printers were used to compare the output. One is a CR10-S5 and one is a Jubilee printer. The CR10 is running a Duet2wifi and a Duex5 expansion card, the Jubilee is running a Duet3-6HC with the extruder being run off a tool board.
                                        In both cases the extruder is a direct drive extruder. Both use firmware 3.4.0.
                                        I used a pressure advance python script that I plugged the correct data into in order for it to generate a gcode file. The file prints a single line with fast and slow segments. Slow segment was 5 mm/sec, fast segment was 100 mm/sec.
                                        The same filament (same roll) was used in both cases.
                                        It probably has been well over a year since I last ran this pressure advance test but it used to show very clearly what the pressure advance should be set to.
                                        I can report that the result was absolutely useless - there was no discernible difference in the layer lines. I ran pressure advance from 0.000 to 1.000 just to cover my bases but did more in-detail testing in the 0.000 to 0.080 range which is the expected range for a direct drive extruder.
                                        There was an occasional abnormality here and there but it was not consistent and certainly was not repeatable.
                                        I have set config.g on both printers to 0.01 as a wild guess. I could have chosen pretty much any figure between 0.00 to 0.08 as the test print showed no difference in the output.
                                        When I was getting close to 1.0, I was seeing some issues but again, there was no clear 'this is good' and 'this is bad'.
                                        I am left with two possible alternative explanations: 1) I don't know what I am doing or 2) PA is completely and utterly borked.
                                        Since these tests have been a good indicator for PA before, I am leaning towards #2.
                                        In all fairness, it did take me some time to tweak the python script to work with a multi extruder printer which initially also caused no change in the printed output. That was caused by me printing with extruder 1 but setting the pressure advance for extruder 0 ... doooohhhh ..... but I did correct that and feel that I have valid gcode files and pressure advance is simply not working. I have run M572 on the active extruder and as far as I can tell, the printer thinks it is set to the right pressure advance.

                                        gloomyandyundefined Adrian52undefined 2 Replies Last reply Reply Quote 2
                                        • gloomyandyundefined
                                          gloomyandy @jens55
                                          last edited by

                                          @jens55 What was the version of firmware you were using when this test worked? Has anything else changed in your printer setup (hardware or configuration) since then?

                                          If you think this is a problem with 3.4 that did not exist on an earlier version please switch back to that earlier version and publish the results from both. So far I do not think we have any examples that show this is a change between versions of the firmware (when using the same settings and hardware for both new and old versions). If you are using any 3.4 features (like input shaping), you may want to try disabling them and re-run the 3.4 test again before switching back to the older version.

                                          jens55undefined 1 Reply Last reply Reply Quote 0
                                          • jens55undefined
                                            jens55 @gloomyandy
                                            last edited by

                                            @gloomyandy, I do not use input shaping. It's been likely a year or more since I last ran these tests. I can not reasonably claim that nothing else has changed. Heck, I wouldn't even know where to start the recreating of old config.g files. I am not in a position to start reverting to old versions. I have neither the time nor the energy to go through that process in a thorough manner. I will likely continue my experimenting for a while but it isn't an exhaustive investigation (and is not meant as such). I am simply throwing my observations into the mix of things.

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