6th-order jerk-controlled motion planning
-
A controller CANNOT "Do what the gcode says". Gcode says "move along path to point x,y at feedrate f", and the next gcode says "now, point x2y2". This involves "turning a corner". Changing the mechanics to that path CANNOT happen at feedrate f.
The planner must accelerate, decelerate, etc. The amount that it does so is ALWAYS a compromise.
That compromise can be planned in dozens of ways. Sixth order is one of those many ways.
"Turn it on or off"? What you really mean is "Select this planning/accel/jerk algorithm over that one". Don't think for a second that the one currently embodied in any given firmware is perfect.
-
I know, but as you say, it is compromises. So, if one could choose one or the other, it is better. For example, reduce ringing but rounded corners, or sharp corners but ringing... Just an idea...
-
There seems to be a misinterpretation of the graphs shown in the page explaining higher order motion planning. Those have nothing to do with automatically replacing corners with arcs, on the contrary. With higher order motion planning the controllers try to reduce the motion related artifacts (missed steps, ringing etc.) as much as possible, while also indirectly reducing other problems (like cutting tool bending, especially on straights as the tool goes slow enough to bend less when getting close to the final position).
I don't have Danal's experience (never really used any large CNC or one with a gantry exceeding 15kg), but I still consider that purposely replacing corners with arcs is not good, at least now without the possibility of disabling it! My message was mostly about "path smoothing".
Another thing that the 3D printing world knows nothing about is the two separate passes when milling - roughing and finishing. Corners rounding might be OK when roughing with some left over material for the finishing pass, but most CAM tools used for milling already do that.
Now on the Mach3 vs TinyG comparison, I can't comment on that matter. But it would be interested to know overall results when using TinyG with and without "constant jerk" algorithm (if there is a way to disable it!). There might be many more differences making TinyG better than Mach3 for your specific situation. I have first hand experience with GRBL vs Duet. I have found out that G2/G3 should be limited on my current setup to 2100mm/min with Duet while with GRBL I can go up to 2500mm/min (maximum mechanically possible). If beyond 2100mm/min (like 2140mm/min, so just 2% faster) the machine sounds like breaking into pieces when executing some of the G2/G3 commands. Overall Duet is much better, but for this particular task GRBL beats it, for now! That is why I consider that pure Mach3 vs TinyG comparison is not correct as we are discussing motion planning algorithms, so we should rely more on comparisons done on the same controller.
-
The rounding of corners I proposed is on a very small scale just to counter the effect of flexibility and inertia. The distance nozzle overshoot on a 90 degree corners is usually between 0.05 to 0.1mm. So I won't only add a arc with that radius to just counter the overshoot, and while it does that it also proves a smoother motion. And the rounding compensation should be proportional to the acceleration experienced by the nozzle, so when you draw perimeter with a slower speed, the amount of compensation would be less.
-
Catalin_RO,
I completely agree that there are many more differences between MACH and TinyG than just the philosophy behind the motion algorithm.
At the same time... watch this video:
https://www.youtube.com/watch?v=Uq1Hawd6ONE&feature=youtu.be&t=6
Nothing special is being done to bring the weight to a stop at the end of each cycle... except "constant jerk".
-
I must admit it is pretty impressive, though it would have been even more impressive to see a side-by-side comparison with the same movement with simple, constant acceleration, solution.
But, again, it is all about higher order motion planning and not path smoothing. If path smoothing is just a side effect of motion planning, so be it. But doing it on purpose is still the thing I disagree with. In the end, if I want to machine sharp edges, I can go for something like 100mm/min and avoid all artifacts. With automatic replacing of corners with circles, those sharp edges are no longer possible.
Also, if TinyG does that only with 3rd order motion planning, why not implementing that first and only afterwards go for higher order algorithms?
-
+1 to S-Curve implementation. This video is the perfect demonstration for an enhanced quality (noticeably less ringing in the print). https://www.youtube.com/watch?v=C0XjXqO6Ji8
I have been looking at the implementation of the S-Curve motion control in Marlin and TinyG. It oly works on 32bit CPUs as AVR simply does not have enough processing power for this.
TinyG implementation is well explained nd has references to some papers with the maths behind the code: (https://github.com/synthetos/TinyG/blob/master/firmware/tinyg/plan_exec.c#L243).They're using 5th-order Bezier velocity curves to get 6th-order position planning. When planning each velocity change, the math assumes that acceleration and jerk start at zero, which allows to significantly simplify the math.
Note that both solutions are still using trapezoids to drive overall velocity changes, it's just that the velocity changes are smoothed using the 5th-order Bezier curves.
The logic is also very clearly explained at https://github.com/MarlinFirmware/Marlin/pull/10337.
-
I've been trying to avoid getting involved with this discussion on the grounds that it's bad for my blood pressure
, but anyway…..So aside from the technicalities, what is the big problem with the current motion system that this proposed variable rate of acceleration is going to cure? Where are all the real world prints that every FDM printer suffers from because of imperfections in the current motion system? I look on line and see some pretty amazing things that people are making so where is this problem that needs solving?
Also, where are the real world prints that have been produced with every parameter unchanged apart from implementing variable acceleration? Where are the back to back, real world tests? Where is there any scientific analysis of a) the problem as it manifests itself in FDM printing and b) the solution to this problem?
I see videos of moving glasses full of liquid in a straight line. So what? How does that relate to improved print quality with real prints? What happens when that same motion system is applied to short moves or segmented arcs? What happens to the extruded filament under those conditions? What happens to pressure inside the melt chamber? etc etc...
I see a picture of an imperfectly printed test cube, then a “reason” for the imperfection being some sort of overshoot which variable acceleration will correct. Come one…….I've printed much better test cubes than that, and just look on line and you'll see many other examples of test cubes without these defects. All of which have been printed with the current motion system.
I see statements like “the distance nozzle overshoot on a 90 degree corner is usually between 0.05 and 0.1mm”. Really? For every printer? For every speed? Where are the test results? How was that number derived? Where is the evidence to back up that statement?
Come on guys. Lets have some real world test results and some sort of proper analysis. All I hear is conjecture and hypothesis based on theory, YouTube videos of beer glasses, and pictures of imperfect prints which can in fact be printed without those imperfections. Show me real evidence that a problem exists and that variable acceleration on it's own with all other parameters unchanged, gives some improvement in 3D printing, then I'll start to believe.
The big thing that everyone forgets or chooses to ignore with these discussions is that we are using what is in effect a robot controlled glue gun. That is to say, we are squeezing hot sticky filament out of a nozzle. No matter how precisely we control the movement of the print head, the filament will to some extent “do it's own thing” and in general, it will always lag slightly behind the print head as it gets dragged across the bed or previously printed layer. If we accelerate the print head in X and or Y we need to accelerate the rate that we push filament into the hot end (and melt it) by the same proportion. The trouble is, it just acts like a sponge and damps out a great deal of that acceleration or deceleration. All we get is rapid pressure changes followed by much slower increases in feed rate. So the rate of change that we can extrude filament will never closely follow the rate of change that we can apply to the print head position. Coupled with other factors such as filament type, hot end temperature, layer height (and width), imperfect gcode and numerous other variables, this means that very fine control of the rate of change of the tool path position is largely a waste of time and effort IMO.
-
@deckingman Ian I agree with you about this not necessarily being something that is required for 3d printing. What is interesting is that for CNC firmware variations on this theme appear to be more common.
Now that David has migrated to an RTOS, it might be possible for someone to write an alternative motion planner based on one of these algorithms and then run true side by side tests. I would be very wary of switching permanently but having an alternative that could be selected via gcode might work, especially if this is a bigger issue for CNC machines.
-
Why heaving less vibrations should not be an advantage for 3d printing? The psychics behind it is simple. Maybe many users will not see a difference because they jerk and acl settings a quite low. But I like to push my printer to the limits.
-
@dragonn The point is that it has not been definitively shown to have less vibrations in 3d printing. We need to have some comparisons with everything else held equal.
-
A lot of this comes down to - "how fast do you want or need to print?" If you need accuracy over speed, and that's the position most people eventually come to rest at, then slow everything down, lower XY acceleration to the point where you are not making your mechanics follow anything but the true path the gcode contains.
If however you want to push a machine to the limits of speed then perhaps having some sort of compensation for the inertia of the print head and the axes supporting it makes sense. There is no doubt that good software, especially RRF, can create much better prints than less good software, using things we already have like pressure advance and non-linear extrusion which for all intents and purposes can be seen as either fudges which do yield better results, or compensations to allow the imperfect machinery to produce nearer the desired output.
How you go about tuning it and deciding how much "inertia-compensation" or whatever you end up calling it, to apply is something to be determined.
-
@t3p3tony I know without an video and rely on one opinion isn't an 100% confirmation but I will quote from first link with I posted (https://github.com/MarlinFirmware/Marlin/pull/10337) :
"The result is mostly incredible: There is no vibration of the machine itself while printing. You have to see in action to believe it! :D" -
@dragonn fair enough but were they using TMCs with 256 microstepping etc. I am not saying we should not do this, rather that we need to get some side by side comparisons on Duet. That requires someone to code a new motion planner into RRF.
-
Lots of good reading here for the technically inclined.
https://github.com/KevinOConnor/klipper/issues/57I think we need to keep from getting derailed by the talk of replacing sharp corners with arcs. That's not really what S-curve acceleration is about. Smoother accel and decel, less vibration, open the door to higher speeds with similar quality. Who doesn't want shorter print times and a quieter printer?
Now that we have 32bit cpus we have the opportunity to spend more cycles on potentially better path planning. It's something worth investigating, because the potential is certainly there. Real world tests can only come after there is an implementation available to test against.
closed S-Curve acceleration? #57
-
@deckingman
The point that video of mater make is that with the S curve acceleration, moving mass comes to a stop without oscillation. In 3d printer this would result in less ringing.
When I say “the distance nozzle overshoot on a 90 degree corner is usually between 0.05 and 0.1mm”. That is just referring to this particular print. If you print the perimeter slowly or have very low jerk acceleration, you may not see the overshot, but the overshot still happens. The print head along any an axis cannot go from 5mm/s to 0mm/s instantly, it will overshot more or less, it might just not be visible for you. This is backed up by physics. Just like you compensate the elasticity of filament by pressure advance, you can also compensate for the elasticity of xy motion.
I don't know why you are so against the idea of an different different motion system. You want to see real world test results before you believe but every time this is brought up you just strongly oppose the idea, and even an experiment build. This might work well, or it might not bring any improvement, but how do we know without testing? -
@deckingman said in 6th-order jerk-controlled motion planning:
So aside from the technicalities, what is the big problem with the current motion system that this proposed variable rate of acceleration is going to cure? Where are all the real world prints that every FDM printer suffers from because of imperfections in the current motion system? I look on line and see some pretty amazing things that people are making so where is this problem that needs solving?
I look online and see artifacts in MOST prints. Not all. Use extremely high quality mechanics, slow down print speeds, and amazing quality can result. But, again, most prints I see have very noticeable ringing after a corner or a hole. For many applications, these artifacts can be ignored. Or painted over. However, I'd rather not have them to begin with.
And... I won't quote the rest of your post about controlled testing, change one thing at a time. Because I agree with that! 100%!! Maybe more!!!
Unfortunately, it is almost impossible to achieve. The closest we could come would be a firmware that allows us to change algorithms while keeping as much else as possible equal. Given the real world way that firmware is developed, even open source firmware, this seems unlikely.
Therefore, "distant second" is to switch from one firmware to another, and see the results. I can only testify to such swaps that change MANY other things... such as MACH to TinyG on a machine who's specs I posted above. The results were remarkable.
3rd order? 6th order? Not sure. Let's try them all.
I also humbly submit: The "replace this path with that" debate??? ALL controllers approximate the path. To some extent or another. (Again, at anything above VERY SLOW speeds.) So the debate should be "What set of approximations result in the best physical print?". The "should the controller approximate" horse left the barn long ago.
-
And, since tone is hard to read on Forums: FUN DEBATE, let's keep going!
Delta / Kossel printer fanatic
-
@shen said in 6th-order jerk-controlled motion planning:
................> I don't know why you are so against the idea of an different different motion system. You want to see real world test results before you believe but every time this is brought up you just strongly oppose the idea, ..................
I'm not opposed to a different motion system. Like I said, show me some real evidence. However, as a mechanical engineer I do have difficulty in understanding how the implementation of jerk in the physics sense, (i.e changing the rate of change of the rate of change of velocity) can lead to better print quality. It comes from spending a great proportion of my working life combatting the effects of non linear acceleration. Variously referred to as "jerk", or in higher orders of magnitude terms such as "snap", "crackle" and "pop". These are maybe desirable characteristics for breakfast cereal but tend to have undesirable consequences in motion systems.
That aside, what I really do have a problem with is the unscientific way in which most of these "features" or firmware requests are presented. It's what I call "cat an dog logic". It goes like this. All dogs have 4 legs and fur. My cat has 4 legs and fur therefore it's a dog. So using the same logic we have a video of a glass of beer being moved smoothly, therefore we can say that if we use the same motion on my printer, it will print better. Huh? Maybe it will, but there are numerous reasons why it might not. That video of the beer glass\wine glass whatever, was made quite a while ago. How come the makers of it haven't released a new video showing that motion translates into improved print quality? I can't help being cynical - it comes with age.
-
@danal said in 6th-order jerk-controlled motion planning:
And, since tone is hard to read on Forums: FUN DEBATE, let's keep going!
Absolutely. We can agree, or agree to differ. All in a mature and adult way and hopefully neither feel aggrieved by other peoples comments nor cause others to feel so.
