[2.0.x, Question] S_CURVE_ACCELERATION and JUNCTION_DEVIATION seem to have no effect?

[marcio-ao]

Hello all,

I am a bit perplexed by something. I have been experimenting with S_CURVE_ACCELERATION and JUNCTION_DEVIATION with a Feedrate Percentage between 500% and 999% on SD prints and while my calibration cubes are coming out shockingly good for such high speeds, turning either of those two feature on or off does not seem to change much at all.

I am printing with the default acceleration set to 1600 mm/s^2, but the maximum acceleration for each axis is 9000 mm/s^2. The maximum feedrate capped at 300 mm/s.

I am curious as to whether anyone has any hints as to why I am not seeing any print quality differences with these new features? Could it have something to do with the fact I am using the Feedrate Percentage knob rather than increasing the speeds in the slicer?

Anyhow, I've heard great things about S_CURVE_ACCELERATION and JUNCTION_DEVIATION, so I'm a bit perplexed as to why they seem to be having no noticeable effect in my case.

-- Marcio

[marcio-ao]

I am reading up on motion control here and I am a bit confused. Here they talk about acceleration either being constant, or being jerk limited. I assume that when you enable S_CURVES, you are in fact doing what they call jerk-controlled motion, whereas the older versions of Marlin did what they call constant-acceleration. But in jerk-controlled motion, the "jerk" is right in the name and a limit must be specified.

But yet, when you enable JUNCTION_DEVIATION, the jerk settings in Marlin go away. So, my question is: When both S_CURVES and JUNCTION_DEVIATION are enabled, where do you set the maximum value for the jerk?

[AnHardt]

The key here is the different definition of jerk in Marlin and the rest of the world.
Physicists talk about jerk as the change of acceleration (m/s²) over time - having the unit m/s³.
Marlins jerk-speed is in m/s - the fastest speed we can begin a move with when starting from 0m/s. A difference in speed.
I hear you thinking - that's impossible. You can't have a jump in speed - that needs because of F=m*a an infinite force. It's the other way around. We don't move a mass. We do change the direction of a field. It's about like loading a spring. And the mass of the rotor is forced and accelerated by the spring to rotate.

Imagine a powered stepper motor with only 4 full steps per rotation. Now we mount a lever pointing to 12 o'clock. Now we take a finger and try to displace the lever up to 3 o'clock. We experience a increasing force/moment against our finger, reaching it's maximum at 3. Going further to 6 the moment decreases down to zero. Reaching 6 the lever is pulled away from the finger and increasingly accelerated to 9, then decreasingly accelerated to 12, where it reaches its maximum speed. Then because of the momentum of the mass it continues its move, now decelerated by the field until (on a low friction system) our finger is hit near 6 from the other side. We'll see some oscillations around 12 with decreasing amplitude. In summ we skipped 4 steps.

No displacement between field and rotor - No moment!

Now the other way around. Put away your finger. We apply a step. Logically this is an immediate proces. We tell the stepper driver to take a step. That's a nearly infinite fast thing, we just switch a pin to high. Locking at the field it takes somewhat longer to decrease the current in the one coil and rise it in the other. But compared to the now slowly starting to move rotor, changing the field is a fast process. The rotor follows the, now pointing to 3 o'clock, field and is accelerated up to there. If no further step follows in time the rotor is now decelerated, returns at a bit before 6, and oscillates around 3 for a while until all energy is converted to heat by the friction. Now we could repeat our first experiment - displacing the lever with the finger. Will get the same result turned 90°. We also will lose 4 full steps again.
Now let's see what happens when we don't take full steps, but microsteps. Let's assume 3 microsteps per full step, to stay with the picture of a clock. We readjusted the lever to 12 o'clock. Right, we applied a full step backwards. Pushing the lever to there will not work. Now we can apply the microstep. The field now points to 1 o'clock. The rotor, coming from 12 follows accelerating the field to 1, has its maximum speed there, swings over up to nealy 2, oscillates around 1 and finally points steadily to 1. All in all this microstep was much less violent than the full step. Overswing, speeds and duration of the oscillation have been much lower. The microstep was smoother than the full step. Repeating the experiment with manually displacing the lever shows increasing force up to 4, zero at 7, a return to 1. The needed forces and achieved speeds have been about the same as with full steps (depending on the exact currents the stepper-driver applied). We learn, even here the amount of lost full steps, when displacing manually was 4, or in microsteps 4*3= 12. We also can learn, we have to apply 3 microsteps, with unmoved rotor, until the moment can reach its maximum. Further follows, if we have a system with N microsteps per full step, we can apply 2*N-1 (in ouer 3 microstep system for example from 12 to 5) microsteps at once while holding the lever, and the lever will still go to the right place and in the right direction when released.

That has consequences for 'double-' and 'quad-stepping' at systems with full- or half-stepping when starting from zero speed. In 'double stepping we apply two steps as fast as we can. That means, on a full-step system, we get zero moment and the direction of the move, when it comes, is undefined (Butterfly effect). Applying a quad step makes the rotor think - nothing to do because field did not change. On a half step system we have the same situation with a quad-step - direction of rotation is undetermined. Nevertheless double- quad-stepping does work. We don't hold the the rotor, can't apply steps infinite fast and, provided jerk-speed or 'junction deviation' is set low enough, start with a speed below it takes double-stepps. When we reach the speed we begin with the double-steps the rotor does not stand still - its direction is determined.

Now let's add a very special (unreal) stick only brake to the 3 microsystem system. We adjust the brake to the point where, when the field points to 12, we can position the lever to every place between 11 and 1 (that also means between 5 and 7). Let's point with the field to 12 and also the lever. Now we apply a microstep, the field is pointing to 1 but we don't see any change. The moment applied to the rotor by turning the field by 1 hour is just not big enough to exceed the stikforce. When we apply a second micro-step, the field points to 2, the rotor breaks loose, accelerates up to 2, swings over to about 4, oscillates a bit around 2 until the amplitude is below 1h difference and finally stands still somewhere between 1 and 3, where 1 and 3 are the most likely places (because oscillations have zero speed at the point they change direction and stick forces can grab). What we will see when we apply the next micro-step, pointing the field to 3, depends on the position of the lever when we apply it. At 1 it will end at a place between 2 and 4. At 2 and 3 it will not move, because the stick-forces are not exceeded. However, the lever will always end at the place where the field points to, +- one hour. If we change to more microsteps this will stay the same - but an hour will be an other amount of microsteps.
If we take a look at the lever we can't say anymore where the field is pointing to. It's somewhere +-1 hoer before or after the lever. Think about what happens when we increase the stick forces. Right - the margin will grow - but how far can we increase? Right - Until the margin is one full step. Then we don't get any movement because the stick-force is greater than the moment the motor can develop.
When we (again) hold the lever and apply a bunch of steps we now have to calculate the max with 2*N-1-(stick-force in micro-steps), to get always a movement into the right direction.

Why can't we step infinitely fast? Because it takes some time to readjust the currents in the coils. If we switch off the current in the coil before it reached its maximum, maximum moment is not reached. Because the moment goes to zero when the time for a step goes to zero, somewhere we get to the point where the moment is not large enough to overcome and resistance. The angle between rotor and field increases and finally, when the distance is one full step, the motor will skip (at least 4 full steps).

Why can't we accelerate infinitely fast? The now the not that surprising answer is - We can! But before you want to give the Nobel-award to me I have to qualify this. We can, at the step level for a very little amount of microsteps. We can, safely jump 1 full step if field and rotor was pointing into the same direction, to get the full moment instantly. Thereafter F=m*a rules! We have to accelerate slow enough to never exceed the motors max moment at that speed.

Why do we want S-shape-acceleration? The upper part of the S is about the lower available moment at high speeds. You remember - when we do step slow the coils get the full current where we have the highest moment. When stepping fast we don't have that high currents - not that high moments. So when stepping slow we have a lot of moment available to realise high accelerations, but when stepping fast a lot less.
The lower part of the S is about smoothness of the move. When we apply high moments, we get high displacements between field and rotor. Do you remember the oscillations when we applied full steps?

Because of that (and some more elasticities in the system) we can apply Marlins jerk-speed. It describes the length of the break in between of the first two step pulses. How much the break shrinks is described by acceleration. The number of steps in time is speed, the sum of steps - way. Jerk (in the conventional sense) is variation in acceleration.

EDIT: Still not satisfied with the S-shape chapter - but too tired for tonight.

[workheart]

That was ... Pretty good explained,

[AnHardt]

Now we know what Marlins jerk-speed is and why it can work.

Marlins S_CURVE_ACCELERATION is entirely determined by the used algorithm. The shape of the curve is calculated from entry-speed, exit-speed and duration (what is predetermined by the acceleration vor that segment) No further parameter is used - especially no other jerk parameter and even more, not from Marlins jerk-speed.

JUNCTION_DEVIATION is a way to calculate the maximum speed we can have when the path changes direction. With jerk-speed (per axis) we determine the same; How fast can we move when the direction changes without exceeding the maximum immediate change in speed for any axis.
The parameters for JUNCTION_DEVIATION and jerk-speed are mathematically related to each other, but the relation is not trivial. However, the value for the max deviation has to be calculated from 'jerk-speed' of the worst axis. So if the 'jerk-speeds' differ a lot between the axes JUNCTION_DEVIATION will break down much more than 'jerk-speeds', depending on what axes are involved in the change of the path.

[marcio-ao]

@AnHardt: Your explanation makes perfect sense as it applies to the motor. But the X and Y carriages are a block of physical mass and you need to control the real jerk (m/s^3) it experiences accelerates so you can reduce the ringing artifacts on the print. It sounds like Marlin is lacking actual jerk-controlled motion as it relates to the hotend and print bed.

It appears to me as if the new S-Curve based acceleration smooths out the acceleration curve in some way, but it does not seem to be tied to a physically based factor such as real jerk factor (m/s^3). If that is the case, the reference in the code to the TinyG page is misleading, as TinyG appears to implement true jerk-controlled motion, whereas Marlin does not.

[AnHardt]

@marcio-ao
As far as i can see there is no way to adjust acceleration in TinyG. So they are adjusting that with jerk.
Marlin with S-Curves is adjusting jerk with acceleration.
That's about the same - just the other direction.

[marcio-ao]

@AnHardt: That somehow that seems backwards. If we are defining a maximum acceleration value in Marlin, we are defining the peak value for the acceleration curve, but there would need to be something that tells how the acceleration curve will look before and after that peak, i.e, how steep it is. That something is supposed to be the jerk.

Reading through comments in the code I see that S_CURVE_ACCELERATION fits a Bezier curve to the acceleration profile. The mathematics is way beyond my understanding, but one thing that makes me a bit curious is that I've only heard of Bezier curves in the context of computer graphics, never within a the context of motion systems.

I suspect what is being done is to apply a Bezier to the trapezoidal acceleration curve with the control points chosen to give the sides of the trapezoid an S shape. While this would most likely lead to smoother motion, I wonder whether this corresponds exactly to a jerk-limited scenario, or is just a clever approximation.

Alas, like I said, the code is well above anything I could understand, so even if it is just an approximation, it's a darn clever one for sure.

[marcio-ao]

@AnHardt : I see you expanded your explanation above. My conclusion is that it seems like there are two things going on in a 3D printer. 1) vibration due to the stepping action of the motor and 2) vibration due to the momentum of physical parts of the printer, such as the print head X motion and bed Y motion. These two things need to dealt with separately. My questions concerning motion control were related to 2 -- it had not even occurred to me to think about 1, so it is helpful that you brought that up.

[hexane360]

S-curve acceleration is a way to control real (d^3s/dt^3) jerk, separately from how Marlin handles its jerk-as-instantaneous-velocity-change. In non-S-curve Marlin, the velocity profile is a trapezoid, which means the acceleration profile is a piecewise constant function (+acceleration on the rising slope of the trapezoid, 0 for the plateau of the trapezoid, -acceleration on the falling slope). Taking a second derivative, you find that real jerk is undefined at four points: the start and end of the move, and the start and end of the plateau (it's 0 everywhere else). The s-curve is different. The 8-bit code makes some approximations, but mathematically the curve should be one with a constant 6th derivative of position (aka an order 6 polynomial). This makes the jerk a cubic function, meaning it's continuous and smooth throughout the move.

Obligatory marketing video: https://youtu.be/qYJpl7SNoww

Traditional jerk (or junction deviation) is still needed to avoid accelerating to a stop between every move. But the S-curve should make the acceleration profile smoother within each move.

Edit: here's a good description of TinyG's S-curve implementation. I found it helpful when trying to understand Marlin's version.

[italocjs]

Awesome explanation, thanks @AnHardt .
i was a bit curious about how this works

[AnHardt]

@marcio-ao

If we are defining a maximum acceleration value in Marlin, we are defining the peak value for the acceleration curve

Currently we do define, not the peak, but the maximum average of acceleration. We calculate the shape of the trapezoid with the configured acceleration and then replace the diagonals with S-shaped curves taking the same time. That means, peak acceleration, in the mid of the S is larger than the configured one. That does not really matter since all these values for accelerations, jerks, speeds are empiric - When you get skipped steps - lower them, or improve the other side of the equation - friction, mass, current, decay-mode, ...

Yes - it's a approximation. No processing power for the real stuff.

[AnHardt]

To come back to your first questions.
S_CURVE_ACCELERATION will not speed up your prints as sutch. Accelerations will take the same time as before. But maybe you can increase the one or the other of your acceleration values without getting too bad ringing. Or/and mayme you can configure increased your top speeds.
JUNCTION_DEVIATION will not directly increase or decrease print time. Depending on the relation to your former jerk-speed settings the speed at the corners may be slower or faster than before, but hopefully the calculation for the cornering speeds is done faster and more reliable than before.
Feedrate Percentage recalculates the feedrates received by g-code. If cut down by the max_feddrates, you may see no difference.

As always there is a lot of rumor on the roads. Keep cool and make your own thoughts and tests.

[marcio-ao]

As always there is a lot of rumor on the roads. Keep cool and make your own thoughts and tests.

It's often very difficult to make a judgement of whether a particular feature makes a difference in real life. While it's tempting to think, if it is new, it has to be better, it's often hard to actually prove it :)

Yes - it's a approximation. No processing power for the real stuff.

Will 32-bit boards be a turning point?

[thinkyhead]

@houseofbugs has been using S_CURVE_ACCELERATION on a bunch of (AVR) machines and finds that it makes a positive difference.

[marcio-ao]

@thinkyhead: I'm not denying that it does. It's just that nailing down the right set of circumstances under which it makes a difference seems challenging. Right now it seems like tuning 3D printers is more guesswork than a science. Maybe it's time to start sticking accelerometer chips on the toolhead and find a way to take some measurements!

[thinkyhead]

Certainly. Given the experience of @houseofbugs, I was hoping we could entice him to chat with us about his settings and what kinds of results he's getting in a variety of circumstances.

[workheart]

short question, does S_CURVE_ACCELERATION require 32bit or no tmc or something else?
if i compile with #define S_CURVE_ACCELERATION i dont get a compile error but a Board stuck in boot ~3sec loop and some harsh letters flying over the terminal Output (like if bandwith would be wrong but no bandwith matches)... im on mega2560 with Ramps and tmc2130spi. any Chance this is to much for the processing power?

[thinkyhead]

S_CURVE_ACCELERATION is known to work on AVR and should work with any stepper drivers. It might be that you have too many features enabled. Are you getting any warnings when you compile with the option enable?

[workheart]

There are no warnings and ther is space left after compiling, i dont have lcd and bedleveling so ther ahould be headroom. I will try with daily maybe something got corrupted.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.