Better, finite-jerk acceleration?

I have a sincere need for non-infinite jerk(the actual acceleration derivative; not the firmware/acceleration algorithm setting). It seems like the acceleration methods used in reprapfirmware (I have 3 duet-based machines) and marlin (also 3 printrbots, 2 lulzbots, and a custom ramps machine) are still using infinite jerk.

2 of the duet-based machines I run are capable of 400mm/s with 4000mm/s^2 acceleration carrying a direct-drive extruder payload and cornering with 30mm/s instantaneous speed change. You can imagine these machines are quite the noisemakers with substantial amounts of mechanical resonance, despite some vibration dampening components.

Does anyone know of a firmware aside from G2 core that offers non-infinite jerk?

I'd love to discuss why this is important for the future of consumer FFF. Please consider this: TinyG/Synthetos is building Marlin-like g-code compatibility into their G2 Core, and they have at least hinted at a 3D printing-oriented pcb/firmware announcement this April/May. If they offer the only known jerk-controlled firmware/pcb for the everyman, then what does that say for the other firmwares? Moreover, it seems their implementation of 7th order motion control was much simpler/symmetric than most people imagine (and maybe portable to other firmwares?)

I hope I've missed something. Maybe there's already a non-infinite jerk firmware out there that isn't G2 core?

Edited 1 time(s). Last edit at 02/10/2017 04:03PM by tjhinton.

Why do you feel you need to limit the rate of change of acceleration? Have you any evidence or sound physics to support that view?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Given the speed capabilities you describe, you should actually be able to reduce jerk a little and increase your accels for less noise smoother motion? You clearly have some experience and know your way around so I am only making the comment. I am not quite sure I follow your finite/infinite jerk description though. Jerk is an instantaeous direction change. Are you suggesting a jerk/junction deviation with a steep ramping curve instead of instant?

A lightweight extruder will make a lot of difference to noise and moving mass, however I am not pimping anything here, you have options in this regard.

Given the topic of jerk and motion control perhaps consider this, (maybe a seperate thread required)...why do E axis and XY axis have seperate unlinked motion parameters that are only controlled by a final output comparator of some sort. There have been a couple of posts about this in the distant past, but to have seperate independent control of these axis, when they should be in synch, seems out of step to me (no pun). Something for the code wizards to consider as the extruder "travels" the same relative distance?

In my mind I would be looking at your query with a slightly larger scope to address issues elsewhere in the chain that may result in a resolution to your specific concern?

Just food for thought.

---

Flex3Drive.com

Quote
dc42
Why do you feel you need to limit the rate of change of acceleration? Have you any evidence or sound physics to support that view?

Correct me if I am wrong, but I believe much of the mechanical noise produced by 3d printers (and transferred to prints) is from their infinite jerk turnarounds, meaning they instantaneously chance acceleration (especially at corners). In hobby (and older) cnc, this is often treated by mechanical dampening mechanisms, but new stuff is fantastic at implementing higher order (such as constant jerk) motion control.

I would be thrilled at constant jerk implementation in any reprap firmware, but it's not really there, AFAIK. It was in TinyG, but they have since moved to the 7th order (Bang?) control found in G2 Core. (I believe they found it was easier/more symmetric than 4/5/6th order, but I could be wrong)

When it comes to physics, I would like to ask why you WOULDNT want to control jerk at corners? It's nothing but noise in the motion system, even if that motion system is incredibly rigid and precise. Obviously, it isn't "infinite" IRL. But the wobble associated with the machine's insane jump in acceleration is often the cause of artifacts like ringing and downright audible noise. Sure, there are ways around this, but most of us use belted systems and steppers, which are perfect for setting up oscillation along a given axis. For the speeds I have mentioned, "infinite" jerk is a very troubling phenomenon.

This kind of motion control would be the absolute top of my list for feature requests, but it's difficult to implement and perhaps unrealistic for me to expect it anytime soon.

dc42, it's amazing to have this exchange. Thank you for all you have contributed to the reprap firmware/ duet projects. My peers and I have benefited greatly from your efforts. Also, can't wait to get my duet wifi!

Quote
Mutley3D
Given the speed capabilities you describe, you should actually be able to reduce jerk a little and increase your accels for less noise smoother motion? You clearly have some experience and know your way around so I am only making the comment. I am not quite sure I follow your finite/infinite jerk description though. Jerk is an instantaeous direction change. Are you suggesting a jerk/junction deviation with a steep ramping curve instead of instant?

A lightweight extruder will make a lot of difference to noise and moving mass, however I am not pimping anything here, you have options in this regard.

Given the topic of jerk and motion control perhaps consider this, (maybe a seperate thread required)...why do E axis and XY axis have seperate unlinked motion parameters that are only controlled by a final output comparator of some sort. There have been a couple of posts about this in the distant past, but to have seperate independent control of these axis, when they should be in synch, seems out of step to me (no pun). Something for the code wizards to consider as the extruder "travels" the same relative distance?

In my mind I would be looking at your query with a slightly larger scope to address issues elsewhere in the chain that may result in a resolution to your specific concern?

Just food for thought.

Perhaps pertinent to this would be the idea of a curve segment with infinite radius and a curve segment with tiny radius. The segments may have the same length traveled in the XY plane, but the extrusion would differ due to the nature of the extrusion being “crowded” on the inside and “spread out” on the outside of the curve. The difference for extrusion between the two would be tiny, but it is still very much representative of why it’s necessary to de-couple the xy-e system during stepping.

Quote
tjhinton

Quote
Mutley3D
Given the topic of jerk and motion control perhaps consider this, (maybe a seperate thread required)...why do E axis and XY axis have seperate unlinked motion parameters that are only controlled by a final output comparator of some sort. There have been a couple of posts about this in the distant past, but to have seperate independent control of these axis, when they should be in synch, seems out of step to me (no pun). Something for the code wizards to consider as the extruder "travels" the same relative distance?

Just food for thought.

Perhaps pertinent to this would be the idea of a curve segment with infinite radius and a curve segment with tiny radius. The segments may have the same length traveled in the XY plane, but the extrusion would differ due to the nature of the extrusion being “crowded” on the inside and “spread out” on the outside of the curve. The difference for extrusion between the two would be tiny, but it is still very much representative of why it’s necessary to de-couple the xy-e system during stepping.

If you follow the center line of a single strand of filament around a curve, there is always going to be a differential between inner and outer edge radii regardless of being linked or not?

---

Flex3Drive.com

Quote
Mutley3D
If you follow the center line of a single strand of filament around a curve, there is always going to be a differential between inner and outer edge radii regardless of being linked or not?

If I understand what you mean by linked, then yes. Curvature will change the amount of extrusion though.

Quote
tjhinton

Quote
Mutley3D
If you follow the center line of a single strand of filament around a curve, there is always going to be a differential between inner and outer edge radii regardless of being linked or not?

If I understand what you mean by linked, then yes. Curvature will change the amount of extrusion though.

How would curvature extrusion when linked, be any different from existing unlinked curvature extrusion? I concede I may be missing something obvious or not so obvious but I dont see it yet, or my logic may already be compensating for the difficulty you are thinking of.

---

Flex3Drive.com

@Mutley3d

Curvature in general doesn't matter, yeah, although I'd argue that depends on a lot of small factors related to the extruder/extrusion settings.

I think it's mostly linked, but there are several occasions where it (ideally) isn't due to pather considerations for a given layer. What I am trying to convey (and doing a terrible job of) is that curves mated to each other often result in sub-optimal packing. Think of doing 100% concentric infill on the top surface of a part with a sharp corner in XY. The curves may need increased extrusion to horizontally fill regions that are otherwise going to be left blank (if the extruder is constantly linked to the XY for the entire path). Furthermore, sharp curves kind of need control over extrusion to avoid blobbing/oozing during inevitable slowdown when the printer corners.

For that reason and many others, I think it's imperative that acceleration with non-infinite jerk is implemented across all axes.

I don't know about the legitimacy of his claims since there is surprisingly little data out there to back it up, but Brook Drumm has said Printrbot is able to run their Play up to ~150mm/s (I think that's the correct value). If that's true, it'd be nice to see how long each axis is running that velocity. This is quite a feat for a little machine like this, but it makes sense given they are using their G2 printrboard to achieve this (which runs G2 Core).

Edited 2 time(s). Last edit at 02/13/2017 04:28PM by tjhinton.

I'm having a real hard time trying to understand what is meant by infinite jerk. In your OP you mention that it's not the firmware algorithm settings. So in basic physics we have the first derivative of position with respect to time being velocity. The second derivative is acceleration. The third derivative is the rate of change of acceleration also known variously known as jerk, jolt, lurch, or surge. But I don't see a firmware setting that uses jerk in this sense i.e. mm/sec^3 (thank goodness). There is an instantaneous speed setting which is referred to as jerk and is expressed as m/min (so really it's velocity). My understanding is that this is used when doing small segments such as our simulated curves to prevent the print head coming to a complete stop before commencing the next segment. But all these settings have finite parameters so what on earth is meant by "infinite jerk"?.

Quote
deckingman
I'm having a real hard time trying to understand what is meant by infinite jerk. In your OP you mention that it's not the firmware algorithm settings. So in basic physics we have the first derivative of position with respect to time being velocity. The second derivative is acceleration. The third derivative is the rate of change of acceleration also known variously known as jerk, jolt, lurch, or surge. But I don't see a firmware setting that uses jerk in this sense i.e. mm/sec^3 (thank goodness). There is an instantaneous speed setting which is referred to as jerk and is expressed as m/min (so really it's velocity). My understanding is that this is used when doing small segments such as our simulated curves to prevent the print head coming to a complete stop before commencing the next segment. But all these settings have finite parameters so what on earth is meant by "infinite jerk"?.

Based on my understanding, the machine tries to do an instantaneous turnaround in a move that theoretically implies infinite jerk since the rate of change in acceleration is very very high. This isn't the case IRL, but we can call this maneuver "infinite jerk" since we assume the machine is making that velocity change instantly.

Quote
tjhinton

Based on my understanding, the machine tries to do an instantaneous turnaround in a move that theoretically implies infinite jerk since the rate of change in acceleration is very very high. This isn't the case IRL, but we can call this maneuver "infinite jerk" since we assume the machine is making that velocity change instantly.

I stand to be corrected but I'm pretty sure that the machine never does an instantaneous turnaround within a move. Perhaps when transitioning between one move and another as would be the case with doing the very small segments that we have to use to simulate arcs. I'm not exactly sure how jerk is implemented in firmware (DC42 please step in here) but I assume that "normal" deceleration will take place unless the velocity is below the jerk setting threshold, at which point no further deceleration will take place and the head will change direction at whatever the jerk velocity is set to. Is that what we are talking about? If so, then I guess having non infinite jerk would mean using very fast deceleration below the (current) jerk setting threshold. However, this would then mean that the head would have to come to a complete standstill before it changed direction, then change direction and accelerate up to the new velocity. In which case, I can imagine that this behaviour would lead to just the sort of ringing problems that the current implementation of jerk is designed to cure ( by preventing the print head from coming to a complete stand still).

Quote
deckingman
I stand to be corrected but I'm pretty sure that the machine never does an instantaneous turnaround within a move. Perhaps when transitioning between one move and another as would be the case with doing the very small segments that we have to use to simulate arcs. I'm not exactly sure how jerk is implemented in firmware (DC42 please step in here) but I assume that "normal" deceleration will take place unless the velocity is below the jerk setting threshold, at which point no further deceleration will take place and the head will change direction at whatever the jerk velocity is set to. Is that what we are talking about?

Yeah, that's right.

Quote
deckingman
If so, then I guess having non infinite jerk would mean using very fast deceleration below the (current) jerk setting threshold. However, this would then mean that the head would have to come to a complete standstill before it changed direction, then change direction and accelerate up to the new velocity. In which case, I can imagine that this behaviour would lead to just the sort of ringing problems that the current implementation of jerk is designed to cure ( by preventing the print head from coming to a complete stand still).

I thought so too, but then I started looking up a bunch of "industrial automation" tech demos from various manufacturers, and it's pretty clear using spline curves for acceleration really reduces the forces applied on a system. I am relatively new to mechatronics, but I can tell it's a given in high speed actuation that non-constant acceleration is required for smooth operation. The following links may provide more info:

These seem to be a kind of standard demo for not using "trapezoidal" (constant) acceleration:
[www.youtube.com]
[www.youtube.com]

Obviously pro-g2/synthetos:
[github.com]

Edited 1 time(s). Last edit at 02/14/2017 01:33PM by tjhinton.

Yeah I kind of get where you are coming from and I can see how it might be necessary on large heavy tool heads to limit the initial rate of acceleration so that the motor lag doesn't cause missed steps. S curves and so forth are used in heavy machinery with a lot of mechanical inertia - basically to slow down the command signals so that they "line up" with what the mechanics are capable of. AFAIK, on 3d printers, jerk isn't used other than for the small segmented moves on corners, not the long linear moves similar to the video links you posted (but I stand to be corrected). I don't think we would see much benefit in 3D printers in any case because the inherent masses are very much smaller. There are a few problems too. Firstly, the extruded filament will not react fast enough to keep up with the variable rate of change of acceleration. It's just hot sticky plastic being forced through a small hole. So starting or ending a move slowly would likely lead to blobs. We could maybe control that by using pressure advance on the extruder. The other big problem I foresee is how it could be implemented on the very small segmented moves that we have to use on curves. These moves are just too short. Again, most industrial machines are capable of doing true curves but unfortunately to the best of my knowledge, there aren't any slicers that are capable of generating true curves using the G02 and G03 commands.

Now that would be something well worth doing. A slicer capable of generating true curve commands, then we wouldn't need to have jerk - infinite or otherwise.

Quote
deckingman
AFAIK, on 3d printers, jerk isn't used other than for the small segmented moves on corners, not the long linear moves similar to the video links you posted (but I stand to be corrected). I don't think we would see much benefit in 3D printers in any case because the inherent masses are very much smaller.

I believe you would be right if most 3d (FFF) printers were using similar actuation systems as heavy machinery. I would argue that 3D printers like a prusa or a printrbot would benefit MORE than most heavy machinery from this level of control. A direct drive extruder being pulled by a sizeable 400 step NEMA motor can only travel so fast due to that use of jerk. Otherwise, it skips. Controlling for jerk can allow a printer to accelerate even faster than current constant acceleration does.

Quote
deckingman
There are a few problems too. Firstly, the extruded filament will not react fast enough to keep up with the variable rate of change of acceleration. It's just hot sticky plastic being forced through a small hole. So starting or ending a move slowly would likely lead to blobs. We could maybe control that by using pressure advance on the extruder.

I could be wrong, but I think this will not be an issue for most, since there will still be a tradeoff in print quality vs. time unless we're dealing with a volcano or bowden system where extrusion can be a bit elastic. At 200mm/s extrusion on my experimental "fast" machine, I have no issues like this that I can tell, but I have plenty of mechanical noise from the jerks. It isn't validated yet, but I'm keen to believe e3d's hinted-at compact extruder will probably be fantastic in responsiveness, making it perfect for the variation in acceleration. I'm honestly salivating at the thought of using it maybe potentially.

I think pressure advance is going to be very useful for elastic drives like bowdens. Even more impressive would be real-time pressure regulation within the extruder... and then adding retraction/priming. heh... unrealistic?

Quote
deckingman
The other big problem I foresee is how it could be implemented on the very small segmented moves that we have to use on curves. These moves are just too short. Again, most industrial machines are capable of doing true curves but unfortunately to the best of my knowledge, there aren't any slicers that are capable of generating true curves using the G02 and G03 commands. Now that would be something well worth doing. A slicer capable of generating true curve commands, then we wouldn't need to have jerk - infinite or otherwise.

Seconded, creating arcs would be wonderful. Idk how it would be implemented though. I think arcs would benefit in much the same way that say... zigzags would from non-infinite jerks. Also, Slic3r is great. Can't praise it enough.

A couple of observations. You state that non-constant acceleration is essential for smooth motion where in fact the opposite is true. That is why varying the rate of change of acceleration is called "Jerk". The term is derived from the physical effect that the third derivative has on motion. Linear acceleration is essential to smooth motion. As an example, imagine a locomotive coupled to a carriage with some slack in the coupling. The locomotive starts at zero velocity and accelerates at a constant rate. The driver experiences smooth motion. However, because of the slack in the coupling, the carriage doesn't start to move at the same time as the locomotive so by the time the slack is taken up the locomotive is already moving faster. The carriage initially has to accelerate faster than the locomotive to catch up so the passengers in the carriage experience an initial jerk, after which the acceleration is linear and the passenger get a smooth ride. This would be akin to a 3d printer having slack in the belts but in reality, we don't have slack in our belts so our carriage is rigidly coupled to our locomotive and therefore experiences linear acceleration.

I grant you that if there was inherent mechanical jerk in the system, then reducing the initial rate of acceleration would help to mitigate it's effect but is the variable acceleration (i,e, jerk) that causes the problem, not linear acceleration. But then a better approach is to reduce or eliminate any causes of mechanical jerk. Of course, assuming we have eliminated any slack in our drive train, then the next thing would be the inertia. The higher this is, the more inherent jerk there will be in the system. Starting from zero velocity, the system has to first overcome the static inertia. This could lead to some stretching of belts or deformation of the frame or motor mounts which would then "spring back" and lead to (mechanically induced) jerk. So, the higher the inertia, the higher the mechanical jerk characteristics. Therefore the old adages of building a rigid machine with the lowest moving mass, are far more important than playing around with firmware to compensate for inherent problems with the mechanical systems. The more you reduce the mass, the less inertia there will be hence less mechanical jerk to compensate for. So contrary to what you are saying, the TBA compact lightweight extruder, will benefit less from "controlled jerk" than a "standard" extruder.

You say in your OP that you are experiencing noise and mechanical resonance. I would suggest that is is because you are using 30mm/s instantaneous speed change which is really high. My XY carriage weighs in at around 1,300 gms (big heavy Diamond hot end) yet I have my acceleration set to 45,000 but with instantaneous speed of 300mm/min which is 5mm/sec. Perhaps, you should just play around with the settings that are available. I think you'll be surprised at how good a finish you can get even with using "infinite jerk".

Delay in response aside,

Quote
deckingman
A couple of observations. You state that non-constant acceleration is essential for smooth motion where in fact the opposite is true.

I guess what I should have said was non-constant acceleration is perhaps the best way to mitigate turnarounds and potentially ludicrous jerks.

Quote
deckingman
But then a better approach is to reduce or eliminate any causes of mechanical jerk. Of course, assuming we have eliminated any slack in our drive train, then the next thing would be the inertia.

Amen. But once you've removed everything you can, you're still looking at a need for better motion control.

Quote
deckingman
So contrary to what you are saying, the TBA compact lightweight extruder, will benefit less from "controlled jerk" than a "standard" extruder.

If you compare the use of an aero to a... Greg Wade Geared extruder, yeah. But only at the speeds you're able to accomplish with the bigger extruder. If you start to accomplish much faster speeds and higher print acceleration with an aero, you're more likely to encounter the problem of infinite jerk on turnarounds. Otherwise, yeah - heavier will benefit a lot more.

Quote
deckingman
You say in your OP that you are experiencing noise and mechanical resonance. I would suggest that is is because you are using 30mm/s instantaneous speed change which is really high. My XY carriage weighs in at around 1,300 gms (big heavy Diamond hot end) yet I have my acceleration set to 45,000 but with instantaneous speed of 300mm/min which is 5mm/sec. Perhaps, you should just play around with the settings that are available. I think you'll be surprised at how good a finish you can get even with using "infinite jerk".

No doubt it's possible to get excellent results with current acceleration planning, but the machines I'm working on are purely experimental and designed for speed. An example of a machine with a suspension system to dampen jerks:

[youtu.be]

Right now, it looks like Marlin doesn't have s-curve acceleration planned. I have seen no mention of it in the duet wifi forums either. Where it has been discussed is for Klipper and of course g2core(they even have Marlin gcode syntax support, to some extent). It seems like an obvious upgrade to current 3d printer motion across the board, so I'm curious why it doesn't really seem to be discussed in these circles. About the closest I can find is experimental support for g2core on the Archim board by ultimachine. Oh, and also the g2 printrboard, which uses g2core.

Edited 2 time(s). Last edit at 03/09/2018 10:50PM by tjhinton.

Jerk (and often further derivatives of acceleration) are often implemented in higher quality servos/motion controllers. There is quite a bit of information on jerk contro applied to CNC machining.

If you have trouble conceptualizing jerk, imagine holding a 5lb weight in your hand and having someone slowly take it from you, versus having the weight disappear. In both cases the force has gone from 5lb to 0lb, but if it happens instantaneously you will be surprised and your hand will probably overshoot. Similarly, high jerk can excite resonances in the machine frame.

If you are interested in high speed motion you can use servos in place of stepper motors and apply your jerk and other filters in the drive, such as this sort of thing: [www.youtube.com]

I personally think that trajectory control in place of junction-deviation is a bigger win than jerk: [wiki.linuxcnc.org]

Edited 1 time(s). Last edit at 03/10/2018 01:08PM by 691175002.

Quote
691175002
I personally think that trajectory control in place of junction-deviation is a bigger win than jerk: [wiki.linuxcnc.org]

Could you elaborate?

It seems like the technology is already present, but not enough folks have hit the wall of jerk due to relatively low-performance machines (or vice-versa, machine design is constrained by the jerk). What confuses me is why g2core has marlin syntax and marlin doesn't have some degree of jerk controlled acceleration. Switching a million machines that run marlin over to g2core is a massive undertaking if we want to use better motion control; seems it should be native to marlin. Junction deviation and all. I'd love to see something as widespread as marlin become so capable, but using infinite jerk planning isn't future-proof, right?

Marlin doesn't even implement accurate step timing during constant speed moves, let alone during acceleration. So I think it has some way to go before S-curve acceleration could be considered. I very much doubt that the 8-bit processors that are the primary target for Marlin have sufficient processor resources to implement more advanced acceleration or trajectory algorithms.

S-curve acceleration has been discussed on the duet3d.com forum and will likely be implemented in RRF this year if it turns out to be practical.

Edited 2 time(s). Last edit at 03/10/2018 03:57PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Marlin doesn't even implement accurate step timing during constant speed moves, let alone during acceleration. So I think it has some way to go before S-curve acceleration could be considered. I very much doubt that the 8-bit processors that are the primary target for Marlin have sufficient processor resources to implement more advanced acceleration or trajectory algorithms.

This is a really important justification for things like klipper. And RTOS on duets, right? I completely agree, and I hope there's a way forward that doesn't split people into onboard processing vs pre-processing. I'm honestly not sure how to gauge the better solution there.

Quote
dc42
S-curve acceleration has been discussed on the duet3d.com forum and will likely be implemented in RRF this year if it turns out to be practical.

This would make my year. I'd die of happiness to see this happen. I wish there was something I could contribute. My colleages in AM research and I have really benefitted from duets and RRF (maybe outside of horrendous mdns support from various router manufacturers hah).

It looks like tinyg's implementation is here?
[github.com]
I'm still trying to understand it. I don't think it's quite as complex as g2core's version.

I'm also 95% sure ultimaker is going to implement this kind of control on a future platform. And it is possible to put g2core on some version of a modded Utimaker 2+ supported in the g2core repos. I imagine that's this machine:
[twitter.com]

How is S-curve acceleration coming along with RRF? Marlin 2 is currently using it and I swear it prints a lot more smoothly than it did before. (smoothieware -> marlin 2)

Smoothieware has s curve acceleration?

Marlin has seen a lot of changes recently, much improved step generation and both s-curve acceleration and junction deviation is now implemented and working well. There seems to be even more improvements in the loop.
As far as I can see Marlin is now superior to all the other firmwares in this regard, especially since it is soon getting s-curve based acceleration WITH pressure advance compensation.
For those interested there are relevant discussions in the Marlin repository issue tracker.

Quote
warbunniex
How is S-curve acceleration coming along with RRF? Marlin 2 is currently using it and I swear it prints a lot more smoothly than it did before. (smoothieware -> marlin 2)

S-curve acceleration is on the work list for the 2.01 release of RRF.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].