LinuxCNC S-Curve Accelerations

The new PR with comp kinematics support for TP2 will have artifact debs at the end of this link

github.com/LinuxCNC/linuxcnc/actions/runs/23100211514?pr=3807

Thanks for the comp file kinematics update.

I am trying that out.In the meantime, I have been experimenting with current update.
I find that the planner type 2 also cannot accelerate across multiple segments. For a file with very small lines, it is not taking up adequate speed and the file execution is very slow. I am going to try to increase the jerk and try it on a real machine too...  
 

The ngc/tap file is also attached.  

I was thinking this could be solved with defining zones for acceleration. Where segments with similar kinematic parameters and some tolerance of direction can be accelerated over simultaneously. 
I have tried to capture my "Zones" based acceleration idea (using Claude.ai to elaborate on the details).A zone is a group of consecutive path segments that are treated as a single kinematic unit for acceleration planning. Segments are grouped into a zone when they are nearly collinear — i.e., the direction change between them is below a threshold (angle_threshold, default ~0.57°). A zone boundary is created when:

• The direction change exceeds the threshold  or 
• The kinematic limits (v_max, a_max, j_max) differ between adjacent segments 

This collapses thousands of micro-segments (e.g. from a linearized arc) into just a handful of zones

Corner Velocity Constraint: At each zone boundary (a "corner"), the maximum speed the machine can carry through the junction is computed geometricallyradius = path_tolerance / (1 - cos(θ/2))  
v_corner = sqrt(a_max × radius)

• path_tolerance = max allowable deviation from the sharp corner (e.g. 0.01 mm)  
• θ = junction angle between the two direction vectors
• A 90° corner at 0.01 mm tolerance and a_max=500 gives v_corner ≈ 4.1 mm/s — forces a near-stop
• A collinear junction (θ→0) gives v_corner → ∞ — no speed reduction needed

Zone-Level Bidirectional Velocity Planning: This is where acceleration is actually resolved:
Forward pass — starting from v_start, for each zone compute how fast the machine can exit given the distance and limits:          
           v_fwd[k 1] = min(max_reachable_from(v_fwd[k]), zone_Vmax, v_corner[k 1])
Backward pass — starting from v_end, do the same in reverse:          
           v_bwd[k] = min(max_reachable_from(v_bwd[k 1]), zone_Vmax, v_corner[k])
Merge pass — take the minimum at every zone boundary:          
           v_zone[k] = min(v_fwd[k], v_bwd[k], v_corner[k])

VelocityPlanner.max_reachable_velocity computes how fast you can reach the end of a segment given jerk/accel limits. Zones are then classified as accel, cruise, or decel based on whether the entry/exit velocities rise, stay flat, or fall. Consecutive same-type zones are merged into runs, and one S-curve (7-phase jerk-limited profile from SCurveSolver) is planned per run.This means for a linearized arc with 1000 micro-segments, only ~3–4 S-curve phases are generated (ramp-up, cruise, ramp-down), instead of 1000 independent profiles.

Regards,

-automata

There already is some basic merging, I'm sure it can be improved upon