LinuxCNC S-Curve Accelerations

@grandixximo
According to my understanding, the P-tolerance is intended to prevent the need to slow down to speed 0 in a corner and to reduce the speed before the corner to such an extent that the 'corner' can be driven through without exceeding the jerk and acceleration.

@ruediger123
For your exact parameters: 1ms cycle, 50 m/s³ jerk, 5 m/s² acceleration, P0.01 on a 45° corner, the only cornering speed that mathematically fits within the jerk limit on a 1ms grid is zero. Any non-zero cornering speed produces a direction change that cannot be absorbed within the jerk limit given the grid resolution. This is not a tuning issue, it is a fundamental property of discrete-time trajectory execution on a fixed clock.
In practice the planner currently exceeds the limit only slightly, and for most servo drives this is acceptable because the drive interpolates internally at a much higher rate and the mechanical system never sees the spike. What HALscope shows is the command stream quantized at 1ms, not what the motor actually does.
That said, an option to automatically fall back to a complete stop when the jerk-constrained cornering speed rounds down to effectively zero could be useful, giving integrators a way to get mathematically clean HALscope traces at the cost of cycle time on sharp corners. Worth considering as a TP option.

@ruediger123

Think of it like a train on tracks. Your train has a strict rule: it must never jerk the passengers more than a certain amount. It approaches a sharp 45° bend in the track. The only way to respect the jerk rule through that bend is to slow down enough before it. Fine so far.

But now imagine the track is divided into fixed 1 meter segments and the train can only change speed at the boundary between segments, never in between. The bend does not fall exactly on a segment boundary. So no matter how carefully the train slows down, the moment it crosses the bend it is mid-segment, and the direction change happens in one step. That step is a spike, regardless of how slow the train is going.

Your 1ms cycle time is those fixed segments. The corner of your octagon is the bend that never lands exactly on a boundary. The jerk spike is that one unavoidable step.

The only way to eliminate it completely is to stop the train at the bend, let it come to a full standstill, change direction, then start again. That respects every rule. But it is slow.

Everything else is a compromise: the spike exists, it is small, and a good drive smooths it out internally before it reaches the wheels. For most machines that is perfectly acceptable. But if you need the command stream itself to be clean, a full stop at sharp corners is the only option within your parameters.

I would tend to disagree. An ideal TP should always obey constraints, and this is possible
even with a zero P value (motion simply stops at the corner) and enough lookahead.
The TP slows enough on non-differentiable features that it can both obey constraint
bounds and deviate less than P from the programmed path.

If the TP does not obey constraints, some external and likely less controllable
factor will determine the bounds.
 

@PCW
Agreed that an ideal TP should always obey constraints, and the full stop fallback is the correct mechanism to achieve that. No argument there.
The question is whether strict enforcement should be mandatory or an integrator choice. A 20% jerk overshoot on a 1ms grid at a G1 corner is not an unknown uncontrolled violation, it is small, bounded, and predictable, and on drives with internal interpolation the mechanical system never sees it. That is a different situation from the uncontrolled external factors you are rightly warning about.
The practical concern is cycle time. On a complex CAM toolpath with many short segments, mandatory stops at every corner that fails the jerk test could multiply execution time significantly. That is a real regression for integrators who have matched their drive capabilities to their application.
So the proposal is: implement the jerk-aware full stop as an option, off by default to preserve existing behavior, and let integrators who need provably clean command streams or are running drives without internal interpolation opt in. That gives you the mathematically correct behavior when it is needed, without penalizing everyone else.

grandixximo wrote:

@PCW
Agreed that an ideal TP should always obey constraints, and the full stop fallback is the correct mechanism to achieve that. No argument there.
The question is whether strict enforcement should be mandatory or an integrator choice. A 20% jerk overshoot on a 1ms grid at a G1 corner is not an unknown uncontrolled violation, it is small, bounded, and predictable, and on drives with internal interpolation the mechanical system never sees it. That is a different situation from the uncontrolled external factors you are rightly warning about.
The practical concern is cycle time. On a complex CAM toolpath with many short segments, mandatory stops at every corner that fails the jerk test could multiply execution time significantly. That is a real regression for integrators who have matched their drive capabilities to their application.
So the proposal is: implement the jerk-aware full stop as an option, off by default to preserve existing behavior, and let integrators who need provably clean command streams or are running drives without internal interpolation opt in. That gives you the mathematically correct behavior when it is needed, without penalizing everyone else.
 

non budget drives always have more step filtering to suppress these behaviour... I think from differential calculus it is exactly that we need count with some limits of movememt caused by curving, jerk implementation fundamentally ...

it should be switchable from Gcode directly by user, who knows whats is doing... if the trajecotry tolerance is too high and velocity in that moment is non sensing plus path is small segmenting... some overlimit during small amount of time are acceptable(timing tolerance and spiking toleracne should be controlled by the user)

bending(trajectory) the tolerance - to handle this situation is non sense 

All this talk about exact stop mode and angles to me seems to be an academic exercise in mathematics. In the real world it can be solved by simply sacking the part designer. A few minutes at the design phase to account for the physical constraints of the manufacturing process can save many hours of work on the shop floor. This does not just apply to the machining world, there are many other work environments where this rule applies. In my case, it applied in the printing industry and I made sure wherever possible my graphic artists designed for our capabilities.

Reject the design, and send it back for rework would solve most issues when this hits the real world...
 

@endian
Exactly right, the cycle time is a fundamental constraint that belongs in the tolerance budget, not something to fight against. G-code level control of spike tolerance makes a lot of sense and aligns well with what I have been discussing as a TP option.

@rodw
Fair point in an ideal world, but LinuxCNC has to interface with a very wide range of CAM outputs, many of which the end user has no control over. We should strive for maximum compatibility. Yes, some G-code will be genuinely nonsense and will need fixing at the source, but for cases where the geometry is valid and the only issue is a parameter mismatch between the toolpath and the machine limits, an INI or G-code option that lets the integrator choose the behavior is the right balance rather than rejecting the job outright.

Yes, I was aware of the issues. Blind workflows where you have little control over the inputs is always a problem compared with a closed workflow.
My thought is you should be true to the physics. If a blind stop is required, do it. If the outcome is undesirable, its up to the user and his client to resolve.

Just because a part can be designed in paper or computer, does not mean it is machinable.

@rodw

Agreed that the planner should be true to the physics, but the physics here has two valid outcomes depending on the machine. A small bounded jerk spike on a 1ms grid at a sharp corner is absorbed transparently by any drive with internal interpolation, the part comes out correct, no stop needed. On a drive without internal interpolation, the spike is real and a stop is the right answer. Both are physically correct responses to the same situation on different hardware.

The point is not to hide the problem but to give the integrator the right tool to handle it. A blind stop at every corner where the jerk limit cannot be met on the 1ms grid would significantly hurt cycle time on complex CAM toolpaths for no benefit on machines where the drive handles it anyway.

The proposal on the table is a new modal G64.1 P Q
jerk-aware continuous path mode that behaves like G64 P Q but adds automatic full stop fallback when the jerk-constrained cornering velocity rounds to zero. Off by default to preserve existing behavior, opt-in for integrators who need provably clean command streams or are running drives without internal interpolation. That seems like the right balance between being true to the physics and being useful across the wide range of hardware LinuxCNC runs on.