6th-order jerk-controlled motion planning
-
@msquared I couldn't agree with you more. My short answers probably made it seem like I wanted the hobbyists to just leave or something (quite the opposite!! Like you said, we wouldn't be here without them/us).
I also have too limited a knowledge of programming in general to be a main coder on any RRF LTS project, but I will certainly volunteer time and resources to it. As you say, also, only with the support/blessing of dc42 et al. (not because it would be wrong to fork the firmware, legally, but because I want LTS to remain as close as possible to the latest and greatest, so it doesn't confuse people going from one to another)
I think a LTS project would be more documentation-heavy than coding-intensive. The features in the LTS version should/could be much better defined in documentation, because they will be less prone to changing.
-
@dragonn I wasn't trying to offend anyone. The scapegoat is hypothetical -- I'm not trying to ricidule anyone. I just disagree with firmware development being driven by the type of person who comes from a coding background, has the worst printer mechanics possible, and tries to "code their way" out of a problem.
-
@bot said in 6th-order jerk-controlled motion planning:
(not because it would be wrong to fork the firmware, legally, but because I want LTS to remain as close as possible to the latest and greatest, so it doesn't confuse people going from one to another)
100% or at least have a known / viable transition path between them.
I didn’t mean to insinuate that you meant for hobbiest to go away either lol. Mostly was just taking the opportunity to jump on what you suggested and ended up writing a manifesto hahaha
EDIT:
It could also include making sure that bug fixes were added to the LTS version since they would likely be fixed initially on the Latest version. -
@dragonn said in 6th-order jerk-controlled motion planning:
@bot If we would aim for a theoretically perfect printer we wouldn't have:
- axis compensation
- auto bed leveling
- pressure advance!
- thermal runaway protection!
....................
Please don't take this personally but Just for info, I'm with @bot on this. I don't use axis compensation or auto bed levelling or mesh bed compensation. That's because my bed is inherently flat and level, all axes run true, parallel and "tram". This isn't a brag as I'm by no means alone and it really isn't difficult to achieve. It's just a matter of applying sound engineering principles to the design. It isn't much more costly either - basically make a frame that is rigid, use thick flat metal for the bed and support it correctly. There really isn't much more too it than that.
Of the other things you mention. I'd like to use pressure advance because all hot ends suffer the same problems with pressure build up but for various reasons (multiple extruders, less than perfect gcode etc) I've never been able to get it to work well. Even then, I do believe that that there is an engineering solution to the pressure problem by employing an expansion chamber or similar technique as is already used in other engineering scenarios.
I'm not too bothered about thermal runaway protection either. The reason for that is that I've sized my heater correctly so that if a fault developed and the heater was permanently on at full power, it would not reach dangerous temperature levels.
Now my printer is by no means perfect - there is always room for improvement but I don't need any of the software tools you listed. The reason those tools exist is that many printers are built to a price - a very low price. They have to be in order to sell because competition is very high. So to get the cost down to an absolute minimum and save every last cent, they cut corners and use the very cheapest components and materials. Why do you think sensor less homing was introduced? It can never be as reliable or accurate as using a sensor. But it can be made to work "well enough" and it saves the cost of a micro switch and a bit of wire, so that's a few more cents off the cost.
Also these "features" help to sell printers. Joseph Prusa is very good at this type of marketing. Faced with two similar priced printers, most people will pick the one with the most "features" (such as auto bed levelling, mesh compensation, etc etc). So the other printer which has no need for the "features" because it was designed and built properly, won't sell even though it's a better printer. It's just marketing hype.
-
@bot said in 6th-order jerk-controlled motion planning:
@dragonn I wasn't trying to offend anyone. The scapegoat is hypothetical -- I'm not trying to ricidule anyone. I just disagree with firmware development being driven by the type of person who comes from a coding background, has the worst printer mechanics possible, and tries to "code their way" out of a problem.
I agree with you - coding the way when having worst printer mechanics possible isn't the right way. But I disagree that 6th-order motion falls under this. And is not that I have a crap printer, my Hypercube Evolution is build almost like a tank. Only possible improvement would be to move to linear rails.
@deckingman I don't use axis compensation or auto bed leveling too. But this was just an example for solutions with are already implement. About thermal runaway I disagree - even if you have proper heaters power it is better to have it then not. You never know what can happen, what you heater gets a short and it power goes up? This is possible. A proper designed machine have several levels of safety:
- designed safety by proper heaters power
- software faulty detection
- pure electrical or mechanical protection like a thermal fuse
Using proper heaters doesn't mean you can leave other safety functions out of the way.
But I suggest to stop here. This is getting a big off-topic and shit-storm about ideology and others. @dc42 said it is on his list to look at. And if it will get implemented I am sure it will be an option and you all can just not using it, like axis compensation, auto bed leveling and others. No point wrangle about it.
-
https://github.com/KevinOConnor/klipper/issues/57#issuecomment-381355998
this post is a nice exploitation what does Marlin do and why:
Probably there are better approaches to this, but ensuring acceleration is 0 at the start and end of a movement, and that acceleration changes are smooth over time means applied forces do not change suddenly in magnitude or direction, and that means no vibrations and excitations of mechanical resonances of the machine.
And really don't try to tell my that you printer "professional" doesn't generate any vibrations unless you a running it slow and turn down the acl and jerk. I don't buy that, every sudden force change makes vibrations unless you printer brakes the rules of psychic -_-. When you don't have vibrations you are just not pushing you printer hard enough and they are not 'visible' but they are still there.
-
Well that sums it up nicely "every sudden force change makes vibrations ".
Which is why we use linear acceleration - to avoid sudden force changes. Rather than higher derivatives of position with respect to time which are referred to as jerk, snap, jounce, crackle, pop etc (because of the behaviour that they induce into motion systems).
But this is probably the wisest comment
"But I suggest to stop here. "
Good plan.
-
@deckingman said in 6th-order jerk-controlled motion planning:
Which is why we use linear acceleration - to avoid sudden force changes. Rather than higher derivatives of position with respect to time which are referred to as jerk, snap, jounce, crackle, pop etc (because of the behaviour that they induce into motion systems).
Correct my if I am wrong, but I think I understand this right. Let's take an ideal situation - now resistance in movement. In this situation when only need to apply force when doing acceleration or declaration. In linear acceleration when the acceleration stops it's stop immediately. And this is the point when we are having an sudden force changes. In real world sure we need to apply force when moving too, but this doesn't change that in a linear acceleration motion when the acceleration phases ends they is always a sudden force change.
-
@bot said in 6th-order jerk-controlled motion planning:
Speed improvements and "vibration reduction" has thus far only been proposed for mechanical systems which are less than adequate.
Perhaps I'm misreading what you are saying. Personally, I want more speed, and I want it on my VERY GOOD mechanics. Mechanics that were custom designed for quality, and are at a price/performance point where the next few percent of mechanical perfection will double price, etc. Duet 1.21 and these mechanics produce excellent results at 100 to 120 mm/sec.
If a different motion planner gives shorter print times, with the same or improved quality, I'm all for trying it.
"vibration reduction" I agree should be in quotes, it is a very loosely defined goal. So lets just ignore it completely.
Speed with quality? I'm all in.
-
@danal and everyone else: Yes, I agree. If this (or any) different motion planning system gives improved speed on systems that are already at peak performance, I welcome that addition. I'm just worried that this is being driven (in the marlin community) by people with mostly inadequate hardware. Some of the first "academic" examples of these algorithms used obviously problematic mechanics to demonstrate the "usefulness" of the feature.
I'm not against exploring ideas, but we need to pick and choose which ideas we explore. Because the "we" is really only David at this point (though, I believe a Chris is helping a lot, too -- credit where it is due).
I would vote for not even exploring the implementation of "6th-order jerk controlled motion planning" until 100% of bugs are worked out of the the current firmware, and we can see demonstrable benefits from other firmware.
-
Yeah, I'm a lot more excited about RTOS than a different motion planner. At least for now.
At the same time, I'm using a TinyG on my big CNC because of its superior motion. It has plenty of other flaws and frustrations... the motion wins.
-
Yeah, I mead some graphs. And please - fell free to correct my if I am wrong because I am not a psychics, but as far my knowledge goes this is exactly how the force behaves in out current monition planning system.
-
My fiend, you should have taken your own advice and stopped there.
Force vs time is completely irrelevant to motion.
Starting with an object at rest, we start with zero velocity and apply a force in order to accelerate it to a higher velocity. For sure, too high a force would lead to a near instantaneous speed change resulting in jerk (in the physics sense) but linear acceleration doesn't do that. However, if there is a high level of static friction to be overcome, them we would need a high force to overcome that, but no amount of tuning of the motion system is going to to alleviate that inherent mechanical problem. You just have to keep applying more force until the static friction is overcome and something suddenly gives. It doesn't matter how quickly or slowly that force is applied. There will be no motion until the force is greater than that required to overcome the static friction.
So now we have the object accelerating at a constant rate of change. When we reach the desired velocity the force needs be reduced to maintain that constant velocity. It doesn't drop to zero as there are still friction factors to be overcome. Too little force and the object will decelerate, too much force and it will continue to accelerate. Therefore it follows that the change in force to go from acceleration to constant speed must be instant. This does not mean that there will be any vibration or jerk. You don't feel a sudden jerk when you drive your car. When you join a motorway, you accelerate up to speed then maintain that speed. There isn't any jerk or unpleasant behaviour when you change from acceleration to constant speed, even though you back off the throttle peddle and instantly change the force.
Let me give you an example of how jerk (in the physics sense) happens. Imagine a train consisting a locomotive with carriages attached and imagine that this is an old fashioned train which some slack in the couplings. When pulling away from the station, the engine starts to accelerate in a linear manner. For the first few cms, the first carriage remains stationary because of the slack in the coupling. When this slack has been taken up, the engine is already doing say 1km/hr, so first carriage has to have an instantaneous speed change to catch up with the engine, at which point all the passengers experience "jerk" after which this first carriage continues to accelerate at the same rate as the engine. This is an example of non-linear acceleration. Now look at what happens to the second carriage which has slack in the coupling between it and the first carriage. By the time that slack has been taken up the engine is now doing 2km/hr so this second carriage now has to "jerk" up to 2km/hr before it can then continue at the same rate of acceleration as the engine. And so on, down the length of the train. All the passengers experience non-linear acceleration and physical "jerks" but the engine driver is nice and comfortable because he is experiencing linear acceleration.
So the cause of vibration is mechanical (slack in the couplings) and so it is in badly designed or badly built printers (slack in the belts, loose parts, flex in the system, whatever..). The jerk or vibration doesn't come from the motion system (the locomotive engine had linear acceleration so was nice and smooth).
So what do we do? My take on it is that we should eliminate the mechanical causes of the jerks and vibrations, rather than alter the software to compensate. It isn't difficult or expensive to do.
Going back to our train analogy, lets assume that the engine driver is our software. What he can do is accelerate up to say 0.5km/hr then maintain that speed until the last carriage starts to move and from that point on accelerate as normal. (That would be like taking up all the slack and flex in a cheap and flimsy printer). This would be akin to "S" curve acceleration. For sure this would reduce the jerk felt by the passengers in the carriages (or the vibration of the cheap and flimsy printer) but it won't eliminate it, and it will slow down the time it takes to for the entire train to reach the desired speed (or in our case the time for the print head). So if you think that S curve acceleration will lead to faster printing - forget it. All it will do is increase the time for the acceleration and deceleration phases. Actually, it's quite easy to simulate S curve acceleration - change the belts from rigid ones to elastic ones .
Finally, forget the graphs and internet search results and all that theoretical pseudo scientific BS and look at some of the following real world, real printing examples using the current motion system.
https://somei3deas.wordpress.com/2017/06/22/exploration-of-print-speeds-with-a-diamond-hot-end/
https://www.youtube.com/watch?v=NAFd3Hj9Wmc&t=185s
https://somei3deas.wordpress.com/2017/06/25/duet-pressure-advance-experiments/
https://www.youtube.com/watch?v=lnYYNfVoxmQ&t=21s
https://somei3deas.wordpress.com/2018/01/15/an-attempt-to-investigate-pressure-in-the-extrusion-system-with-a-diamond-hot-end/
https://www.youtube.com/watch?v=-HhxSiv5ajs&t=58sThat's real world printing at up to 300mm/sec with the current motion system. For information, the earlier test with the 3 colour hot end the moving mass was around 2.7 kgs, and for the latter tests with the 5 extruders, the moving mass was around 4kg. The limiting factor is how fast we can melt and extrude filament, not the motion system.
-
@deckingman said in 6th-order jerk-controlled motion planning:
So now we have the object accelerating at a constant rate of change. When we reach the desired velocity the force needs be reduced to maintain that constant velocity. It doesn't drop to zero as there are still friction factors to be overcome. Too little force and the object will decelerate, too much force and it will continue to accelerate. Therefore it follows that the change in force to go from acceleration to constant speed must be instant. This does not mean that there will be any vibration or jerk. You don't feel a sudden jerk when you drive your car. When you join a motorway, you accelerate up to speed then maintain that speed. There isn't any jerk or unpleasant behaviour when you change from acceleration to constant speed, even though you back off the throttle peddle and instantly change the force.
Your example is because of inertia in the car itself, the IC engine, and the drive train of the car. And most drivers back smoothly off the peddle. For a similar example, try cutting the current to an electric motor that is direct drive to the wheels of an accelerating vehicle. There will be plenty of jerk.
Literally try it. Go test drive an electric car, preferably one of the performance Teslas, as they can accelerate very strongly (very close to 1G). Slide your foot downwards off the accelerator pedal while under hard acceleration.
Another way of phrasing this same idea: Jerk = rate of change of acceleration. If the force causing accel "changes instantly" then the rate of change of the accel will change equally abruptly. By definition.
Oh, and this is just humor, right?
Force vs time is completely irrelevant to motion.
Force vs time is the only factor in motion of a free body, and when friction, gravity, or other forces applied to that same body are also considered, it remains the major factor in motion of a body.
-
I was referring to the graphs but should have used velocity, not motion.
As for the rest, yes if you like.
We can talk about theory all day and if we tried to print at speeds and accelerations of an F1 car, we might have problems with the motion. The reality is that we can never melt and extrude filament at anything like those speeds or accelerations so we're never going to get those problems.
But I give in - you've worn me down. Whatever you say. You've won the argument. Everything I did and learnt in my 40 years of automotive engineering was and is wrong.
Personally I'm happy that my printer is capable of printing at speeds higher than I can melt filament, even when I get up to 300mm/sec by employing multiple melt chambers and using 5 extruders concurrently to push it into the hot end, without any apparent defects or artefacts that are a result of poor motion control. I've done the real world tests and I'm happy.
Edit. My final word. If you want to do this in a reliable and scientific way, fit accelerometers and vibration sensors and use high speed cameras and lasers to take measurements. These are some of the tools that I used during my career. I can pretty well guarantee that the measurements will reveal results that none of the theory predicted. This why every vehicle manufacture has an NVH department. N=Noise, V=Vibration, H=Harshness. If everything could be explained by theory, none of these departments would need to exist saving the automotive industry £millions a year.
After you've eliminated all the mechanical causes of errant motion behaviour, and you can show that there is still a problem which needs 6th order jerk to rectify, then you have a case for altering the software.
-
I'm all for trying new motion systems to see if they help, though I am not unhappy with the current one.
In the spirit of being conciliatory a lot of this comes down to the age-old debate that was had when auto bed-levelling first came about. We seem to be in two camps, those with stiff, precise machines which don't need it, and those with less solid machines (or less experience or resources) who do need it. Often the ideological divide can be seen between those who want quality but don't care how long it takes, and those who want speed (true they want speed and quality but when its impossible to achieve they settle for speed).
I've been in both camps. I design, make and sell sensors to do bed levelling (or tramming or compensation or whatever you want to call it), but I don't actually use them all that often, on some of my machines as they don't need them. Including my CR10 which has a flat bed, and can be physically levelled by turning screws in a few minutes, and stays in-tram quite well. And it's not an expensive machine. But this isn't an argument for having no software compensation, I've spent quite a bit of time making a piezo sensor system, firmware, and a bootloader flashing setup for this machine as people do want auto-bed-levelling.
Its a tough job for David and T3P3 who have to cater for both groups, but they are managing to do so very well. There is room for both approaches, precise hardware and versatile software.
-
I don't usually post, just lurk and read because it is always interesting.
However, this thread is a mirror of where the machine tool industry found itself in the 80's. Trajectory planning, ball screw compensation tables, etc. were the new and bleeding edge, and the same arguments were had. Long story short, we take these things for granted now. While @deckingman is 100% correct (and I really like/appreciate his systematic approach), he has exposed the next hiccup in the "need for speed". This also happened in the machining world which led to advances in tool materials and geometry, and in particular cutting strategy.
Someone, on another forum, at this moment could be figuring out how to extrude the volume required to travel at warp speed, which would put the ball back in motion controls court.
I also get the argument about build quality, but, while everyone wants a Dixie, most have Haas'es and it is a bit unrealistic to expect otherwise, particularly in the DIY space.
Also we are up against the reality that one very bright man who seems to live a 36 hour day is creating and maintaining the software we are using. Trajectory planning will eventually be a requirement to any 3d printer firmware, but right now, for practical reasons, it will fall into the "nice to have" category.
-
@djdemond said in 6th-order jerk-controlled motion planning:
In the spirit of being conciliatory a lot of this comes down to the age-old debate that was had when auto bed-levelling first came about. We seem to be in two camps, those with stiff, precise machines which don't need it, and those with less solid machines (or less experience or resources) who do need it.
And the third set: Those who have nice, stiff, precise machines that know that their bed is not in the EXACT same place after it has been removed and replaced (delta), or who have verticals long enough for room temperature to have at least some effect (XL to XXL delta), and who therefore run a basic G32 at the beginning of every print.
Yeah, there is a FANTASTIC parallel here with auto-bed-level. Much of the 'meat' of that parallel being those who state that Auto-Level it is for those with imprecise mechanics ONLY... phrasing that contains more than a little snobbery.
-
@acmeanvil said in 6th-order jerk-controlled motion planning:
However, this thread is a mirror of where the machine tool industry found itself in the 80's. Trajectory planning, ball screw compensation tables, etc. were the new and bleeding edge, and the same arguments were had. Long story short, we take these things for granted now.
YES YES YES
-
@danal said in 6th-order jerk-controlled motion planning:
@djdemond said in 6th-order jerk-controlled motion planning:
In the spirit of being conciliatory a lot of this comes down to the age-old debate that was had when auto bed-levelling first came about. We seem to be in two camps, those with stiff, precise machines which don't need it, and those with less solid machines (or less experience or resources) who do need it.
And the third set: Those who have nice, stiff, precise machines that know that their bed is not in the EXACT same place after it has been removed and replaced (delta), or who have verticals long enough for room temperature to have at least some effect (XL to XXL delta), and who therefore run a basic G32 at the beginning of every print.
Yeah, there is a FANTASTIC parallel here with auto-bed-level. Much of the 'meat' of that parallel being those who state that Auto-Level it is for those with imprecise mechanics ONLY... phrasing that contains more than a little snobbery.
Agreed. I did (shamefully) not also mention that there are many cases (deltas and large machines where flat beds are not achieveable) where probing is an extremely useful tool and not a compensation for a lack of precision or rigidity.
But the comparison still stands.