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

    Progress on Path Smoothing / Lookahead?

    Scheduled Pinned Locked Moved
    Firmware wishlist
    7
    25
    1.5k
    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.
    • CCS86undefined
      CCS86
      last edited by

      Hi @dc42, you were working on some improvements to this aspect of the motion control, correct?

      Running through various tests and observations, I find that the jerk values (~15mm/s) required to smoothly print high'ish-speed arcs (very fine G1 segments) are a detriment to the finish on intentional corners in the model, which look better at 8.6mm/s.

      Using lookahead to smooth the stepper outputs, with allowable path/junction deviation, would be such a game changer to print quality (in my estimation). It may even eliminate VFA's.

      🤞

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

        @CCS86 although I agree in principle that path smoothing might be a good thing, It's fraught with difficulties. For example, there is already there is a problem with holes coming out smaller than requested. Path smoothing would make that worse.

        I do have in mind changing the curve that relates allowed jerk to angle. This would allow you to use low jerk (perhaps even zero) when printing square corners, while maintaining the speed of curves made up of line segments.

        Meanwhile, have you looked at whether using Arc Welder to preprocess your files might allow you to use lower jerk settings?

        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

        CCS86undefined 2 Replies Last reply Reply Quote 0
        • CCS86undefined
          CCS86 @dc42
          last edited by CCS86

          @dc42

          I picture it being able to improve small holes. You could force all path deviation to occur towards the outside of small loops, so they would be expanded. For small loops you could even allow a specific larger deviation than elsewhere.

          No arcwelder does me no good. I generate my own STLs, so I can make them very finely segmented, then let my slicer segment gcode at the max G1/sec my board can handle. Even if arcwelder fits good curves, RRF just decomposes the arcs with a fixed segment length, so I have even less control.

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

            @dc42 does that sound possible?

            1 Reply Last reply Reply Quote 1
            • CCS86undefined
              CCS86
              last edited by

              @dc42 ..?

              gloomyandyundefined 1 Reply Last reply Reply Quote 0
              • CCS86undefined CCS86 referenced this topic
              • gloomyandyundefined
                gloomyandy @CCS86
                last edited by

                @CCS86 Do you have any examples of controllers that implement or papers describing the sort of move smoothing you are asking for here? RRF already performs a fair degree of lookahead, but expecting it to be able to recognise "small loops" or other features seems like something better suited to a slicer or other preprosessor to me.

                CCS86undefined oliofundefined 2 Replies Last reply Reply Quote 0
                • CCS86undefined
                  CCS86 @gloomyandy
                  last edited by

                  @gloomyandy said in Progress on Path Smoothing / Lookahead?:

                  @CCS86 Do you have any examples of controllers that implement or papers describing the sort of move smoothing you are asking for here? RRF already performs a fair degree of lookahead, but expecting it to be able to recognise "small loops" or other features seems like something better suited to a slicer or other preprosessor to me.

                  This has nothing to do with "small loops". We are talking about locally smoothing the junctions of linear segments to allow smooth motion.

                  https://www.sciencedirect.com/science/article/abs/pii/S089069551630493X

                  droftartsundefined gloomyandyundefined 3 Replies Last reply Reply Quote 0
                  • droftartsundefined
                    droftarts administrators @CCS86
                    last edited by

                    @CCS86 this sounds like a slicer problem to me, and reading the paper you linked only reinforces that view to me, ie it’s time to ditch stl and use a proper geometry, eg step, for slicing, to produce G2/3/5 moves (though there is an issue with G5 and 3D printing). Then improve the firmware on those gcodes to the point where microstep-accurate arcs are drawn - I believe RRF splits arcs into 0.1mm straight line segments currently.

                    Ian

                    Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

                    CCS86undefined 1 Reply Last reply Reply Quote 1
                    • gloomyandyundefined
                      gloomyandy @CCS86
                      last edited by

                      @CCS86 The reference to "small loops" was from your earlier post:
                      "I picture it being able to improve small holes. You could force all path deviation to occur towards the outside of small loops, so they would be expanded. For small loops you could even allow a specific larger deviation than elsewhere."

                      1 Reply Last reply Reply Quote 0
                      • oliofundefined
                        oliof @gloomyandy
                        last edited by

                        @gloomyandy https://www.klipper3d.org/Kinematics.html#smoothed-look-ahead -- Cura 5.5 has an option to optimize slicing for this, so it's both firmware and slicer that come into play here.

                        <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

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

                          @CCS86 said in Progress on Path Smoothing / Lookahead?:

                          https://www.sciencedirect.com/science/article/abs/pii/S089069551630493X

                          @CCS86 @droftarts Do either of you have access (or a link) to the full paper?

                          oliofundefined 1 Reply Last reply Reply Quote 0
                          • oliofundefined
                            oliof @gloomyandy
                            last edited by

                            @gloomyandy sent you a copy.

                            <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

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

                              @droftarts said in Progress on Path Smoothing / Lookahead?:

                              @CCS86 this sounds like a slicer problem to me, and reading the paper you linked only reinforces that view to me, ie it’s time to ditch stl and use a proper geometry, eg step, for slicing, to produce G2/3/5 moves (though there is an issue with G5 and 3D printing). Then improve the firmware on those gcodes to the point where microstep-accurate arcs are drawn - I believe RRF splits arcs into 0.1mm straight line segments currently.

                              Ian

                              I disagree.

                              Even in the world of very expensive CAM software packages, "arc fitting" / "arc filtering", or the post processing of linear segmented g-code into arcs, is limited and not applicable to all paths. To expect all these freeware slicers to adopt something that such expensive and advanced software doesn't always do, and is computationally very demanding, is unrealistic.

                              What is very common and very reliable, as outlined in that paper, is for the NC motion controller to smooth junctions with allowable deviation, to create smooth, continuous motion. Many even have configurable settings to allow the balance between speed and accuracy to be tuned for the current operation.

                              For RRF arc support, the 0.1mm segment is only the minimum length. In this thread we discussed the formula and for a cylinder of 20mm in diameter, I was getting linear segments of 1.2mm, which is giant compared to what I can achieve with a fine STL and good slicer settings: https://forum.duet3d.com/topic/21825/duet-maestro-struggling-to-produce-smooth-curves/27

                              MJLewundefined 1 Reply Last reply Reply Quote 0
                              • MJLewundefined
                                MJLew @CCS86
                                last edited by

                                @CCS86 I disagree too, but it is with you I disagree. With modern computers there is no substantial penalty for things that used to be computationally demanding.

                                If the RepRap firmware uses segments of 1.2mm for an arc of diameter 20mm then the formula for segment lengths is faulty! I have a routine for changing arcs to G1 sequences that I made to accommodate my then new PrusaMK4 which ignored the Z parameter of G2 and G3 commands (now fixed). I found good results for a wide range of radii with the formula of 6*(r+1)^1.5 where r is the radius in mm. That formula gives a segment length of just under 0.3mm for a 20mm diameter. It is easily modified if that is too large.

                                I'll look at the thread that you linked.

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

                                  @MJLew said in Progress on Path Smoothing / Lookahead?:

                                  @CCS86 I disagree too, but it is with you I disagree. With modern computers there is no substantial penalty for things that used to be computationally demanding.

                                  If the RepRap firmware uses segments of 1.2mm for an arc of diameter 20mm then the formula for segment lengths is faulty! I have a routine for changing arcs to G1 sequences that I made to accommodate my then new PrusaMK4 which ignored the Z parameter of G2 and G3 commands (now fixed). I found good results for a wide range of radii with the formula of 6*(r+1)^1.5 where r is the radius in mm. That formula gives a segment length of just under 0.3mm for a 20mm diameter. It is easily modified if that is too large.

                                  I'll look at the thread that you linked.

                                  Disagree all you want but proper arc fitting can take a long time, even with powerful modern computers. That is a penalty to the user.

                                  I run a high tech CNC manufacturing facility. I have half million dollar machines that chew through linearly segmented code and produce super smooth motion. Arc filtering everything is not the answer on the highest end CNC machining, and it for sure is not the answer for 3D printers.

                                  MJLewundefined 1 Reply Last reply Reply Quote 0
                                  • MJLewundefined
                                    MJLew @CCS86
                                    last edited by

                                    @CCS86 Well, all I can say is that the latest PrusaSlicer has arc fitting and it seems to slice as fast with it active as it does without on my Mac M1.

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

                                      @MJLew said in Progress on Path Smoothing / Lookahead?:

                                      @CCS86 Well, all I can say is that the latest PrusaSlicer has arc fitting and it seems to slice as fast with it active as it does without on my Mac M1.

                                      Have you looked at the code?

                                      It's easy to go fast when you don't actually fit arcs.

                                      d0d9e2eb-d416-40df-940b-c5bb182417f1-image.png

                                      Plus, even when successfully fitting arcs, they inject some variability into the wall surface. You can see something similar if you make the slicing resolution more coarse.

                                      MJLewundefined droftartsundefined 2 Replies Last reply Reply Quote 0
                                      • MJLewundefined
                                        MJLew
                                        last edited by

                                        Yes, I did look at the code.Screen Shot 2023-12-01 at 3.21.33 pm.png

                                        1 Reply Last reply Reply Quote 0
                                        • MJLewundefined
                                          MJLew @CCS86
                                          last edited by

                                          @CCS86 We do not need to argue about this. Fitting arcs will take longer than not fitting arcs, but there are some (many, probably) use-cases and examples where the time difference is trivial. Your experience is vast and your opinion is valid, but it is quite likely that I also have relevant experience.

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

                                            @MJLew said in Progress on Path Smoothing / Lookahead?:

                                            @CCS86 We do not need to argue about this. Fitting arcs will take longer than not fitting arcs, but there are some (many, probably) use-cases and examples where the time difference is trivial. Your experience is vast and your opinion is valid, but it is quite likely that I also have relevant experience.

                                            It's called a discussion, not an argument. That's the whole purpose of this forum.

                                            If you have relevant experience that leads you to a different conclusion, let's hear it. Just saying that you "likely... Have relevant experience" isn't very compelling.

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