LinuxCNC S-Curve Accelerations

circular blending and jerk limiting are two similar but different concepts.
circular blending modifies the requested profile to adjust slowdowns/stops at corners. - ie The planner can modify the profile (within defined parameters) to get closer to the requested feedrate, usually on corners. This uses look ahead.

i understand the basics like replacing trajectory corners with arcs allows to keep a positive velocity with limited acceleration along the way. contrary to traveling thru a sharp corner which needs either a complete stop at it or an infinite acceleration.
but straight line -> arc transitions introduce a discontinuity into the acceleration, i.e. an infinite jerk.

so now there's a fast algorithm available which can construct an optimal trajectory between two states (pos,vel,acc) keeping the velocity, the acceleration and the jerk limited. which is kinda a big deal, as i understand.

so we need to transform a gcode-defined trajectory into something that can be fed to that Ruckig thing and it will happily interpolate it at the servo-thread frequency? is this solvable with the current state of the art? or i just don't have a clue how it's all done?

The laws of physics determine the arc radius that can be achieved for a given maximum acceleration. If you set a G64 limit then you are saying the machine must slow down to achieve that radius.
The lookahead allows the trajectory planner to check out the next segment so the velocity reduction matches what it has to do next. eg if you are travelling at 3 m/min and you have to slow to 2 m/min to negotiate the corner to meet the G64 limits. But if the next segment requires a velocity of 1 min/min, then the TP will slow motion so there is no jerk as it enters the next segment.

The gcode is read into a buffer which in turn is processed by the TP (motion) and tokenised into motion. So its not being applied at the gcode level but at the planning level.

As a first step. I'd like to see it applied to XY motion as that is used by plasma cutters where acceleration and velocity is king (but only  on the X & Y axes). There is no spindle so there is no real complications to deal with.

but passing thru a joint of a linear segment to a tangent arc with *any* non-zero velocity gives an infinite jerk because of a step change in the acceleration? as the acceleration vector rotate towards the arc center...
edit: can the blender use some higher order curves instead of arcs maybe? will that help?

g64 sets the path deviance tolerance. It deviates to keep speed up.

linuxcnc has no jerk limiting so there is infinite jerk every time acceleration changes from constant - even a straight move will have infinite jerk at the transitions.

Since the planner must calculate all coordinated axes together - I don't see it being easier to only jerk limit X and Y.

but doing jogging would be interesting to try on my big lathe.

cmorley wrote:

g64 sets the path deviance tolerance. It deviates to keep speed up.

linuxcnc has no jerk limiting so there is infinite jerk every time acceleration changes from constant - even a straight move will have infinite jerk at the transitions.

Since the planner must calculate all coordinated axes together - I don't see it being easier to only jerk limit X and Y.

but doing jogging would be interesting to try on my big lathe.

Not quite, without G64, the arc on a corner is negotiated at the feedrate in the gcode and an arc is formed. This can be quite huge (eg a 1 m square at 20 m/min is interesting). When you set a G64 tolerance you are setting a limit about how far from the programmed path it can deviate. This sets a smaller allowable arc. The physics of centripetal acceleration sets the maximum speed that we can run at to negotiate that corner. So machine acceleration is a key parameter as it determines the arc radius. eg faster acceleration can negotiate a tighter arc.

With a plasma machine there is no spindle and no z axis while cutting (it is commanded by external offsets, not by gcode). One of the issues I have mentioned re jerk limiting is the complexity of managing motion coordinated with the spindle (eg threading and constant velocity etc). So while the motion controller may look at X,Y & Z, on a plasma machine, the Z motion is always NIL. (Remember external offsets is external to the motion planner). Plus the absence of a spindle takes away a lot of complexity. But the high velocities and Tesla Ludicrous mode acceleration parameters mean plasma will benefit enormously from Jerk limited motion. So to my mind, its a good spot to start.

cmorley wrote:

Since the planner must calculate all coordinated axes together - I don't see it being easier to only jerk limit X and Y.

why? the Ruckig works for arbitrary number of DoFs?

as i understand, currently the blender fits the largest arcs it can into corners while keeping within g64 tolerance away from the path. and then the TP(?) follows that modified path trying to keep the programmed speed but slowing down if needed to stay withing acceleration limits. the Ruckig can also do the later plus also can keep jerks limited. but with arc blends it won't be able to do much better than slow down... wouldn't it?