LinuxCNC S-Curve Accelerations

So your acceleration at time t is a(0) + a_step * t with a_step constant? AFAIK that is called "constant jerk".

Its relatively straightforward to calculate for one axis. Tricky thing is a) figuring out how kinematics folds into it b) figure out path blending.

going from line segment to circle has a (large) step-change in acceleration perpendicular to velocity vector.

So your acceleration at time t is a(0) + a_step * t with a_step constant? AFAIK that is called "constant jerk".

For linear acc-dcc:
v=vo+a*t   

For scurve acc_dcc
v=vo+(ap+a_step)*t  

Where ap=acceleration previous.
Where a_step=acceleration increment/decrement value for each servo cycle, usually 0.001 sec.

In the concave part for each servo cycle : a=a_previous+a_step.
In the convex part for each servo cycle : a=a_previous-a_step.
Then update "a" each servo cycle : a=a_previous.

The jerk is then : jerk=acceleration_end-acceleration_start / time. This value is "constant" during the acc-dcc periods.

Its relatively straightforward to calculate for one axis.
Indeed straight forward, but get's more complicated if using acceleration end period's to resume movement's etc.

Until now this example is only tested for jogging one axis.
Path blending, kinematics, etc are not included in this test.





 

very cool project here!! How are things coming along @Grotius have you found a successful scenario for s curve? I do have some questions regarding your previous comment on challenges of handling changes such as changing max velocity during a program. does this refer to actually changing the max velocity slider or the feed override? I think that in some situations there would be a good use for even a s-curve that was limited on all of those features. something that could be used for production machines where proven programs are run for hours and days at a time with really not much user input or change. maybe have a setup where if any external influence such as override or max velocity changes etc were activated that it would revert back to trapezoidal. this way a user could fine tune a production program which could greatly benefit from this bang bang machine saver update. is this something you think is possible?

Speaking personally, for simpler machines such as 3 axis mills, is this component near capable to handling that type of situation? i would be more than happy to test if you would like as i am facing some pretty bad jerk issues that i would love to get rid of and it would appear this could certainly help!

thank you for all your hard work!

Lcvette wrote:

Speaking personally, for simpler machines such as 3 axis mills, is this component near capable to handling that type of situation? i would be more than happy to test if you would like as i am facing some pretty bad jerk issues that i would love to get rid of and it would appear this could certainly help!

thank you for all your hard work!

Sorry to crash the party, but there isn't really anything to test.

Generation of jerk limited trajectories is not that hard, there are even complete libraries available github.com/pantor/ruckig . Some types of curves like bezier curves of sufficient degree are inherently jerk limited.

Unfortunately the hard part is coming up with a concept that can be integrated into linuxcnc. The TP stuff isn't very hackable. 

Actually the TP is quite hackable, LinuxCNC allows you to supply a different TP using the "TPMOD" INI entry:
linuxcnc.org/docs/2.9/html/config/ini-co...tml#sub:ini:sec:traj

Hi,

How are things coming along @Grotius have you found a successful scenario for s curve?

To update from here. I made a conventional one axis motion controller code in c++ with some help of ai
for the used formula's. It's called SMP "simple motion planner".
The code is on github : github.com/grotius-cnc/motion_tryout

The above project took me quite a while, with up's and down's. Especially the live motion mode was
giving bug's during testing. This is when the motion is live performing during the servo-cycle.

It was a struggle, and i finally found out the problem, made a solution for it, It's now working.

The SMP is capable of planning a motion given a displacement "s" and some velocity values
for cruise speed "vm", initial speed "vo", final speed "ve", etc.

It can already be used for jogging, no problem.

The SMP can plan the curve or motion on forehand.
During the "live motion", user can modify the "cruise speed", controller will respect this value.
User can press stop, and motion will do a controlled stop.

If this SMP code is polished & accepted by the community, the transition or expansion to a-scurve lib is
easyer to do.

For above code i also made a sample for a 9 axis controller with axis synchronisation. All is quite nice.

This SMP library is header only and can be used in a hal component. This can result in a
multi axis motion component.

Perfomance is outstanding.