LinuxCNC S-Curve Accelerations

Just to inject my 2 cents, I always felt that the old parabolic blending planner actually sort of added a bit of rudimentary jerk limiting by it's self. And I think a good jerk limiting planner will need to incorporate a form of that type of blending (but with the multi line look-ahead added.)

PS: I will gladly volunteer to help anyone willing to work on this with testing on real machines. Unfortunately I do not have the programming skills to tackle it myself.

An easy work could be to add S-curve accelerations only to G0 movements, that is a partial solution, but i usually see machine oscillations due to lack of rigidity only on rapids movements. Just my 2 cents.
Victor

Todd Zuercher wrote: Just to inject my 2 cents, I always felt that the old parabolic blending planner actually sort of added a bit of rudimentary jerk limiting by it's self. And I think a good jerk limiting planner will need to incorporate a form of that type of blending (but with the multi line look-ahead added.)
.

It had arc blending, which certainly helped.
The problem with the two tries at S curve was that they never worked out the problems for all forms of motion (eg threading).

If someone attempted again, I would suggest rather then removing the planner we now have, build a new motion component with S curve planner. Motion was built so it was load-time swappable.
In this way if someone built a planner with S curve that was not suitable for eg threading then it still could be used for routers etc.
This would expose it to more testers and developers. Leaving it in a experimental branch just lets it rot.
Same thing with reverse running planner etc....

Chris M

Hi,
Full jerk limitation with multi-axis look ahead has been the holy grail of trajectory planners for a while.
An easier route to implementing jerk control is to use jerk percentage method. More elaboration is given here:
support.motioneng.com/Software-MPI_04_00...s/diff_mtn_types.htm

Fanuc does something similar. They specify a time for jerk limitation. There is a parameter #1772 which specifies acceleration change time. They also have a similar parameter for jerk change time (parameter #1790). There is a single parameter (#1772) for the trajectory, implying that the jerk is limited for the trajectory and not each individual axes (or joints). No jerk guarantee is provided for jerk limitation for each axis or joint.

While Motion Engineering specifies a percentage for jerk, Fanuc uses a time parameter to limit the jerk.

It should be noted that, the time to execute the acceleration/deceleration part of the motion segment will not change. Hence the overall trapezoidal trajectory planner need not be changed. Only the playout part of the acceleration and deceleration sections need to incorporate the jerk limitation parts.

To implement in linuxcnc, we could find the point where the acceleration/ deceleration is computed and break that segment it into 3 parts. If an acceleration/deceleration segment is represented by a second order polynomial, we can break that polynomial into 3 parts. Two of third order polynimials and one second order polynomial. The formula to compute the 3 polynomials from the original second order polynomial should be straight forward given the boundary conditions.

Point to note for this method is that the acceleration limit for the trajectory will be violation can be computed in case we set jerk percent to 100% using the formula given in the motion engg website ( support.motioneng.com/Software-MPI_04_00...s/diff_mtn_types.htm ).

On freeing up some time, I plan to take this up. All help is appreciated.

-automata

It should be noted that, the time to execute the acceleration/deceleration part of the motion segment will not change. Hence the overall trapezoidal trajectory planner need not be changed. Only the playout part of the acceleration and deceleration sections need to incorporate the jerk limitation parts.

To implement in linuxcnc, we could find the point where the acceleration/ deceleration is computed and break that segment it into 3 parts. If an acceleration/deceleration segment is represented by a second order polynomial, we can break that polynomial into 3 parts. Two of third order polynimials and one second order polynomial. The formula to compute the 3 polynomials from the original second order polynomial should be straight forward given the boundary conditions.

It sounds interesting.
The question is: Have you estimate the effort to do this implementation? How many hours of coding/testing?
Available time is the constraint.

Hi,

It should take about 2 man months for implementation and another few for testing and bug removal.

Just found this interesting site that has a standalone trajectory generator.
www.atwillys.de/content/cc/trajectory-generator-in-c/

The code here is a good starting point for testing the logic for a new trajectory planner. The good thing is it will make the trajectory planner simulator easier to integrate into linuxcnc. We need to integrate Robs new look ahead planner into this code.

What has always thrown me off is the cubic joint interpolators used in the linuxcnc planner. These should not have much effect if the rate of calculation of the new point from the planner is equal to the rate of application of the point. I am going to try out this theory with a few concrete examples to see if the joint cubic interpolators could be removed.

-automata