Progress on Path Smoothing / Lookahead?
-
@gloomyandy sent you a copy.
-
@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
-
@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.
-
@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.
-
@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.
-
@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.
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.
-
Yes, I did look at the code.
-
@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.
-
@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.
-
TronXY X5S with Duet 3 MB6HC and Roto toolboard : Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : Polargraph with Duet 2 WiFi
-
This post is deleted! -
I put my g-code resolution back to the default value and it started generating arcs. It only does it on external perimeters though. So artifacts from linear segmented inner walls can still print through.
But again, for the sake of our discussion, until RRF allows true arc support, the quality with G2/G3 is worse than without.
-
@dc42 is this just not going to be explored?
-
@CCS86 I think the main focus right now is getting 3.5 out the door.
