Gemini tells me too...
The Problem: The 7-Phase WallWhen we move from traditional Trapezoidal (T-curve) to S-curve (Jerk-limited) motion, we hit a massive computational wall during High-Speed Machining (HSM). In a "cloud of points" (dense G-code with 0.01mm segments), a 3rd-order planner like the Yang Yang method has to solve a 7-phase analytical equation for every junction.At a 1ms servo thread, this is heavy. At 250µs, it’s nearly impossible for the CPU to stay in real-time. The result? "Unexpected Realtime Delays" or the planner "giving up" and slowing the feedrate (F) to a crawl to stay within Jerk limits.
The Best Available Solution: The "Double FIR" ApproachIf you are struggling with latency in your new S-curve trajectory planner, the most efficient implementation for dense point clouds isn't more complex math—it’s Digital Filtering.Instead of solving the 7-phase cubic equations at every point, the "Gold Standard" for high-frequency (250µs+) loops is the Double FIR (Finite Impulse Response) Filter:Trapezoidal Base: Use a simple, ultra-fast Trapezoidal planner to generate "raw" velocity.Filter 1: Pass the raw velocity through a moving average filter. This creates 2nd-order motion (Linear Acceleration).Filter 2: Pass that result through a second moving average filter. This creates 3rd-order motion (S-Curve / Jerk-limited).Why this wins for Point Clouds:O(1) Complexity: The math is just addition/subtraction. It doesn't care if the segment is 10mm or 0.001mm.Low Jitter: It’s perfectly suited for the 250µs window.Natural Blending: The filters act as a low-pass filter, naturally "smoothing" the noise inherent in point clouds without the overhead of junction-blending logic.
In professional controllers (Fanuc/Siemens), this is solved by having a dedicated DSP (Digital Signal Processor) or an FPGA that does nothing but the motion math, leaving the main CPU to handle the G-code.
