c2 smooth velocity profile

Need Sam on this - he loves testing this stuff!

rmu wrote: Just a warning, it does exceed acceleration limits while it should not, and the linuxcnc version it is based on is outdated. Do not run on something that moves..

I had thought it might be possible to do something similar to the way external offsets is managed. That is allocate a portion of max acceleration (say 20%) to the s curve which reduces the machine's acceleration to a lower limit (80%). Maybe that override can be calculated?

In theory, my code should not lead to acceleration excursions.

It may be a bug in the math (unlikely) or some interaction / wrong understanding of trajectory planner on my part (very likely).

The tinyG 6th order bezier curves inspired me to the code in the branch

g2 fork claims, that jerk-free acceleration works with feed overwrite and start/stop

Hi rmu,
Excellent work. I want to help carry it forward.
First a few caveats that will simplify the problem:
1. Leave spindle synchronized motion alone. Let that fallback to the trapezoidal planner
2. For each call to tpRunCycle, if the value of the Feed override Velocity has changed, recompute the optimization with new feed value based on current feed (call tpRunOptimization). In this case, include whatever is left of the current executing segment too.
3. For Cycle Pause, do the same as (call tpRunOptimization again).
4. On Estop, do whatever is done currently.

There are only 3 sources of change of velocity for the planner during running.
1. Estop
2. Cycle Pause
3. Feed override

Each TC segment has an initial velocity vi, final velocity: vf and max velocity: vm. It also has a time taken for execution, tf and the starting position and end position. Assume that the start accel and end accel of each segment is 0 (for simplification of the problem) as you have done: ( github.com/rmu75/linuxcnc/blob/ed7c30ab5...rc/emc/tp/tp.c#L2443 ).

Let me know your thoughts on the issue and maybe we can work on it together?
-automata

automata wrote: Hi rmu,

Let me know your thoughts on the issue and maybe we can work on it together?
-automata

Thank you for your kind words.

I'm in the process of getting my dev environment back together. It shouldn't take too long for "master" to build on ubuntu focal. It seems the rs_6otp branch applies cleanly on top of rene-dev/limuxcmc. I will rebase my branch onto current linuxcnc as soon as the python3/gtk3 fixes are merged to master.

IIRC from my last tests, sometimes strange things like accel limit violations would happen when running 3D_Chips.ngc, and some circumstances start a motion that never stops.

Spindle synchronized motionc is kinda off-topic anyways, because motion is synchronized to whatever the spindle is doing, not the other way round as far as I understand it.

Jogging could be a useful thing to target.

But feed override is not that easy to crack, because it should be applied while the current segment is executing (that segment could be long), so it needs to be recalculated on the fly and ideally, axis should accelerate to overridden feedrate smoothly. I imagine a bunch of cases like current segment too short for acceleration, long enough with current feed but too short with new feed, and so on.

A possiblity could be to use an "internal" feed override that gets updated from "real" feed override, and those updates are smoothed out.Then no recalculation of segments should be needed, but I have to check if this works with the trajectory planner.

E-Stop shouldn't matter. With "real" hardware, drives go into e-stop and decelerate motors as fast as possible.