APIs, concepts, guides, and more
S-Curve Jerk Algorithm

Table of Contents

Opt for the S-Curve Jerk algorithm in custom firmware for precise control over acceleration and jerk during moves, allowing for smoother transitions and specific adjustments during the deceleration phase of motion.

🔹 Algorithm

The move type, S_CURVE_JERK supports a jerk-specified S-Curve accel/decel profile. This algorithm is only available with custom firmware. In the custom firmware, the Trapezoidal and S-Curve algorithm is replaced with the S-Curve Jerk algorithm. In the standard firmware, the S-Curve Jerk motion type is not supported and if specified, the RapidCode API will return a "profile not supported" error. The S-Curve Jerk algorithm is ideal for making final adjustments to a move during the deceleration portion of the move and for making smoother transitions from one motion to the next. Also, the S-Curve Jerk algorithm makes it possible to exactly specify the maximum accel and decel and jerk values.

The standard S-Curve algorithm first calculates the trapezoidal profile move from the specified velocity, accel, and decel values. Then the algorithm re-calculates the profile, deriving the accel, decel, and jerk values from the specified jerk percent. Since the algorithm always uses an initial Accel = 0, the start profiles and the modify profiles are calculated the same. The algorithm achieves identical move times for the Trapezoidal and S-Curve profiles by increasing the maximum acceleration, depending on the specified jerk percent. This algorithm is very efficient and easy to understand.

The custom S-Curve Jerk algorithm calculates the move profile based on the specified velocity, accel, decel, and jerk values. It is a complex algorithm, which iteratively solves for the profile based on the initial and final conditions for velocity and acceleration. The resultant trajectory is limited by the specified velocity, acceleration, and jerk. The S-Curve Jerk algorithm does not support a specified jerk percent and is computationally intensive.

Note: If your application does not require modifying S-Curve move profiles during execution, use the standard Trapezoidal or S-Curve algorithm. If your application requires motion profile modifications during acceleration or deceleration, and the acceleration rates are high, contact RSI to discuss a custom S-Curve Jerk algorithm.

Below is a comparison of a modified motion with both algorithms.


S-Curve Algorithm: Notice the Modify calculations assume the initial acceleration value is zero, which causes an abrupt change in the acceleration profile.


S-Curve Jerk Algorithm: Notice that the Modify calculations use the initial acceleration value, which causes a much smoother transition in the acceleration profile.

Parameters for jerk values should range from a minimum of amax* amax / vmax (amax is just reached when accelerating from 0 to vmax) and a maximum of amax / sample period (amax is reached in one sample period). In the S-Curve Jerk algorithm, changes to the jerk will also change the time needed to complete a motion. For example, a large value of jerk will have a shorter time, but increase the "jerkiness" of the motion (see fig 1). Conversely, a small value of jerk will have a longer time, but a much smoother motion (see fig 2).



The S-Curve Jerk parameters, accelerationJerk and decelerationJerk are located in the MPITrajectory{.} structure. When these are non-zero, the acceleration profile uses the specified jerk and acceleration to ramp an axis(es) to constant velocity and then decelerate to a stop. If accelerationJerk or decelerationJerk is zero, the RapidCode API will return a "parameter invalid" error.

Custom S-Curve Jerk Limitations: The S-Curve Jerk algorithm has the following limitations:

Multi-axis moves must use the coordination type START. Do not use FINISH. Do not use SYNC_END. \ For moves that specify a non-zero Final Velocity, the Final Velocity must be < = Maximum Velocity. \ The ratio of distances traveled for multi-axis moves should not exceed 50,000. \ Multi-axis move modify should not be called within the first 2 samples of a move start.