[BUG] S-Curve Acceleration - Velocity Jumps when changing direction

[xenovacivus]

Hi,

The S-Curve Acceleration seems to work pretty well, but there's a velocity jump when an axis changes direction (or when an axis stops and starts again, but that's less likely to cause a resonance/missed step problem).

Zooming in shows a significant instantaneous spike in step time (from -2700 steps per second to +250 steps per second).

I see this with a clean build of the bugfix-2.0.x branch (Nov. 20), and my configuration is a stock Teensy++2.0 target with the following changes:
#define DEFAULT_MAX_ACCELERATION { 100, 100, 100, 100 }
#define DEFAULT_MAX_FEEDRATE { 300, 300, 300, 25 }
#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 80, 500 }
#define S_CURVE_ACCELERATION

[ejtagle]

The strange thing is that on the position trace, no discontinuity is shown. Make sure it is not a numeric instability (finite precision) on the either capture process or differenciation process...

[xenovacivus]

The data is captured with a logic analyzer watching the step and direction pins. The position is incremented on step with dir=1 and decremented on step with dir=0. So we wouldn't expect a discontinuity. The velocity curve is created from the difference in position, then applying a low-pass filter.

The number of steps is correct; it's the dramatic change in step period that's the problem.

[thinkyhead]

Is this an unexpected interaction between s-curve acceleration and adaptive step smoothing?

[ejtagle]

No, i really doubt it @thinkyhead . The logic analyzer does not capture Stepper ISR rate - It captures the step and dir pulses created by that ISR. Step smoothing improves positioning, but does not increase speed of step/dir pulses.

The strange thing about this graph is that the discontinuities on velocity and acceleration happen when there is essentially no movement. That is what calls my attention, Such huge jump in speed.
This could be caused by the JERK setting, that allows discontinuities in speed when transitioning of movements, or by the fact that this is plotting just one axis, and this could be a compound movement, where what matters is the vectorial velocity and acceleration changes (module of speed and acceleration) and not the change in its components...

[xenovacivus]

Also I don't have step smoothing defined.
//#define ADAPTIVE_STEP_SMOOTHING
Here's another example:

(Also good news - no steps are lost while changing direction)

The jumps in velocity in this test are +-800 (and +-80 for Z), which correlates with the "DEFAULT_*JERK" settings in Configuration.h. So this looks (almost) like expected behavior - except that "DEFAULT_*JERK" is defined as the maximum instantaneous speed change - and here, when going from a negative velocity to positive velocity, there are two back-to-back instantaneous changes (one from -800 to 0, then another from 0 to 800). So it's twice "DEFAULT_*JERK".

Here's a zoom of the velocity graph (unfiltered):

It's running this gcode:

M17 ; Enable Steppers
M121 ; Disable endstop checking
G92 X0 Y0 Z0 E0 ; Set Position
G1 F6000 ; Speed 100mm/sec

G1 X1
G1 X0
G1 X1
G1 X0
G1 X1
G1 X0
G1 X1 Y.1 Z.2
G1 X0 Y.2 Z.4
G1 X1 Y.3 Z.6
G1 X0 Y.4 Z.8
G1 X1 Y.7 Z.9
G1 X0 Y1 Z1
G1 X1 Y1.4 Z.9
G1 X0 Y.6 Z.8
G1 X1 Y.4 Z.7
G1 X0 Y0 Z0
G1 X1
G1 X0
G1 Y1
G1 Y0
G1 Z1
G1 Z0
G1 Y1
G1 X0 Y0

[johanmanuelle]

I have the creality cr10 printer and print a model with Marlin 1.1.9 and after 3 hours of printing that model the print starts to shows layers mismatched, change a little the position and print in different part, I do the same print three times and the same problem, I rollback to the original firmware that came with the printer and print again and no problem, maybe a problem with the s-curve? Please help me

[xenovacivus]

@johanmga, I've discovered the velocity jumps here come from using "classic jerk" computations, and happen whether or not s-curve acceleration is enabled.

Try uncommenting //#define JUNCTION_DEVIATION in Configuration_adv.h; that will disable classic jerk and use the junction deviation math instead.

Also for reference, issue #12403 is actively tracking the layer shift issue (please comment there too if you have more information on problems/solutions), and #12540 is has more information on classic jerk vs. junction deviation.

[johanmanuelle]

@johanmga, I've discovered the velocity jumps here come from using "classic jerk" computations, and happen whether or not s-curve acceleration is enabled.

Try uncommenting //#define JUNCTION_DEVIATION in Configuration_adv.h; that will disable classic jerk and use the junction deviation math instead.

Also for reference, issue #12403 is actively tracking the layer shift issue (please comment there too if you have more information on problems/solutions), and #12540 is has more information on classic jerk vs. junction deviation.
thanks a lot!! i will try and comment in the near future the results, have a nice day :)

[johanmanuelle]

@xenovacivus I replaced the traditional jerk for junction deviation and the problem was solved!! , Additionally I put a little Pieces of foam on each corner of the printer in order to reduce the vibration :)

[fiveangle]

@xenovacivus, my morbid curiosity wonders what your captures look like with JUNCTION_DEVIATION defined :)

[xenovacivus]

They're pretty interesting, actually!

With the same configuration as the first post but JUNCTION_DEVIATION on and set to 0.02, I get this (S_CURVE_ACCELERATION on):

And here's the same input, but with S_CURVE_ACCELERATION turned off:

In the trapezoidal acceleration case, the first move (from 0 to 1600 steps) accelerates for roughly 1 second, coasts for a second, and then decelerates for a second. But in the s-curve acceleration case, it coasts for about 1.2 seconds and doesn't have enough time (travel length) to decelerate completely, resulting in the jump to 0 velocity. So either the s-curve is taking longer to accelerate/decelerate than the trapezoidal curve, or the time to begin decelerating is further into the block than with the trapezoidal profile.

Also gcode for reference:

M17 ; Enable Steppers
M121 ; Disable endstop checking
G92 X0 Y0 Z0 E0 ; Set Position
G1 F6000
G1 X-200
G1 Y50
G1 X200
G1 X-200
G1 Y50
G1 X0 Y0

[xenovacivus]

Here's a bit more!

I aligned the s-curve and trapezoidal profiles with the same time scale and used the ms-paint analytical tool to compare. It looks like the s-curve for deceleration begins a little late, meaning the extra length traveled (area underneath the velocity curve) needs to be chopped off of the end, or the axis will travel too far. Because of the whole area-under-the curve thing, a little time spent at high velocity translates into a LOT of time spent at a low velocity (especially because the tail end of the s-curve is very near to zero). The green color tries to highlight this (the two areas are roughly equal; in fact, the tall skinny one should probably be a little skinnier).

Note: if the s-curve begins a little early, it results in a profile which stops short of the intended location. This is even less ideal than a profile that must be cut off, because the axis decelerates to zero and must accelerate again to complete the move (and that would require a lot more logic than the current "We're at the end of the travel, shut 'er down!"). So, if there must be some error, it's probably better to bias it to starting the deceleration curve a bit late.

A more optimal solution might re-evaluate the tail end of the s-curve on the fly and dynamically adjust, or just replace the last portion of the curve with a constant acceleration portion. Or, ideally, the point at which deceleration begins is precise.

[gururise]

@xenovacivus
What I gather from your last two comments: this is an issue with S-CURVE acceleration that is NOT fixed by enabling Junction Deviation, correct? S-CURVE acceleration profile either accelerates too slowly or decelerates too slowly, leaving an abrupt deceleration at the tail end of the S-Curve.

Earlier in the thread, there was some indication this problem was due to traditional JERK and resolved by enabling Junction Deviation. Am I correct in assuming that theory is no longer valid?

[ejtagle]

It would give more insight if we could measure the timing of step pulses at the place where the discontinuity in acceleration happens... 👍