LinuxCNC S-Curve Accelerations

Hello,
I tested on an Orange Pi5 Plus and noticed that the jerk was not always maintained.

the ini and the nc code in the appendix.
In addition, an NC code generated by a CAM where the jerk is also not maintained.. 

@ruediger123
I believe the jerk is not matained, because it is not possible to maintain it with your cycle time and your tolerance, you are purposely settings the machine up to spike, and it will because there is no choice if it follows your thread cycle, if it follows your tolerance, and it follows your set feed, how do you propose this should be fixed? One of these limits should be relaxed, which one?

I don't think I should hard code limits, it should be up to the integrator to setup the machine with proper cycle time and limits according to processing requirements 

@endian @rodw
TP2 in a separate thread should be the medicine that fix our ailments, filtering, NURBS, all will be taken into consideration, it is an active development and testing on our end, not ready to share yet.

grandixximo wrote:

I don't think I should hard code limits, it should be up to the integrator to setup the machine with proper cycle time and limits according to processing requirements 

@endian @rodw
TP2 in a separate thread should be the medicine that fix our ailments, filtering, NURBS, all will be taken into consideration, it is an active development and testing on our end, not ready to share yet.
 

Do you think that TP1 + TP2 should be in the separate thread ?

thanks

Short answer: no.
Longer answer:
Kinda, TP1 and TP2 are different ideas/models/architectures, TP2 is what can be moved in a separate thread, because it was made to plan out of RT, TP1 idea was to run in RT, both are valid ways to solve the jerk-limit, so me and YY agree both can live, they are different approaches, with their own pros and cons, moving TP1 to a separate thread would basically mean TP2.
 

@grandixximo
The machine is congigured with a 1ms servo cycle, the speed with 15 m/min, the acceleration with 5 m/s² and the jerk with 50 m/s³ so nothing unusual for servo axes.
P64 P0.01 Q0.0 is also not unusual.
In my opinion, the limits for jerk, acceleration and speed should not be exceeded so that the behavior of the machine is predictable.
The unusual thing from my point of view is that MAX_LINEAR_JERK and MAX_JERK are different.
If there are restrictions on certain parameters, please let me know so that I can take them into account in my tests.

@ruediger123

The restriction is the corner itself. A sharp corner is a mathematical direction discontinuity. The velocity vector must change by ~191 mm/s across a 45° turn. With a 1ms cycle time, respecting 50 m/s³ jerk would require spreading that change over ~3800 cycles, during which the machine travels nearly a meter. No feed rate fixes this, the problem is geometric.

The only mathematically correct solution within your parameters is for the planner to detect that no valid cornering speed exists that satisfies the jerk limit given the available segment geometry, and fall back to a full stop at the corner. That is exactly G61.1 behavior.

This is actually a valid point and potentially a missing feature: the junction velocity calculation should be jerk-aware, and when the jerk-constrained cornering speed rounds down to zero, the planner should stop rather than arrive too fast and spike. Currently it may only be acceleration-aware at the junction, which allows a non-zero entry speed that looks acceptable to the acceleration limit but still violates jerk because the ramp does not fit in the available geometry.

The practical workaround in the meantime is either G61.1 explicitly, or a P tolerance of several mm to give the planner room for a proper S-curve through the corner. P0.01 is geometrically equivalent to sharp.