LinuxCNC S-Curve Accelerations

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.

grandixximo wrote:

@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. 

I don't think it's actually zero, but it's pretty close. 
Centripetal acceleration is v^2/r and centripetal jerk is v^3/r^2.

My back of the envelope math says the maximum velocity at a 45 degree junction with .01mm deviation would be .0056 m/s or .336 m/min to keep centripetal acceleration at 5 m/s^2. That would produce a centripetal jerk of 4568 m/s^3, which is an order of magnitude over the limit. 

To keep the jerk within the limit, the maximum velocity at the junction would be .001243 m/s or .0745 m/min. At that velocity it would take 8ish servo cycles to traverse the radius. 

But, for all intents and purposes, it's basically a full stop. 

Wouldn't it be pretty simple to find the maximum junction velocity to keep both jerk and acceleration within the limits of each axis? We have everything we need to make that calculation. Interestingly, since corner tolerance, max accel, and max jerk are constants, this velocity limit is only dependent on the angle. That would make it pretty easy to use a look up table generated by the tolerance setting. 

onehossshay.wordpress.com/2011/09/24/imp...cornering_algorithm/
 

Jerk-Aware Full-Stop Fallback (The "G64.1" Proposal) - is possible solution but what if ...

Path Tolerance Splining (Point Compression): Instead of treating the corner as a "sharp" mathematical point, use the G64 P tolerance to convert the corner into a tiny, high-order polynomial curve (spline). This gives the "train" a physical radius to turn on, spreading the Jerk over several segments even at high speed?.... it should plan for the re-parameterized spline. By doing this, the "junction" disappears, and the Jerk limit is satisfied over a distance (the spline radius) rather than a single 1ms step. - but comp-power consuption will be high

or look-ahead Acceleration Pre-Smoothing...Use the look-ahead buffer to start the direction change "rotation" slightly before the actual vertex. By "bleeding" the X-axis velocity into the Y-axis earlier, you reduce the magnitude of the step-change at the corner. "Bell-shaped acceleration" or "Jerk-limited FIR filtering." - but not actual timing 

or second much faster thread which will handle just calculation to fine result .. as Taylor Series expansion to "fill in the gaps" between those 1ms updates: P(t) = P_0 + V_0 \Delta t + \frac{1}{2} A_0 \Delta t^2 ... This should ensure that the drive receives a perfectly smooth 4kHz or 8kHz stream, effectively making the Jerk "infinite" at the digital level but "finite" and smooth at the physical level ?