LinuxCNC S-Curve Accelerations

I tried to follow your instructions, and it works ok for me.
I suspect it maybe something with the custom tool table which is missing from default, could you share that?

Hello,
I am sorry my bad ...I am too much focusing in something and then I failing in others ...

I have tested some toolpaths till now ... Infinite spikes are gone at tp 1 and 2 at paths where it defenetely were in the past ... I noticed that TP1 during its startup with testing code 1_1001.ngc spiking much with servo time (if we take 250us as our goal - for 1ms it is fine) ..

Default TP0 and TP2 do not this behaviour ...

dark blue from scope pictures in the attachments then TP1 is spiking at each segment change over 200us during cloud of points its repeating spiking too.. 

I notice that switching between TP1 and 2 is not possible sometimes it creates error and switch me back to TP2 from TP1

thank you E.

switching live I think is last refinement, YangYang working in separating the TP on a separate thread, switching will be refined after that.
At least spiking is gone, the fall back messages with TP1 are expected, just debugs, will be removed in next PR I think, thank you for spending the time testing.

no problem .. you are welcome, I am proud to cooperate/test this feature for linuxcnc comunity... as you noticed, I am not soo focused in the perfect trajectory but mainly at timing stability... sometimes it's like chasing your own tail

its interesting job and I see many advantages ... I am using TP0 for lathe threading/synchronization of motion for now, but we will wait for new stuff I am looking forward ...

yes I saw but Yang Yang publish new crucking repo few days ago but I have not time to study it ...

Luca which will be the next steps now ?

that dark blue spline at the bottom is the servo-thread.time, in the 100k resolution, which are sharply jumping at start of cloud of points as ... I am not pretty sure how the TP1 works to from the start but other files starting well without that spiking... is it possible to precalculated it or add some waiting to start the motion to smooth the beginning timing? 

How much influence latency of using Mate instead of Xfce gui ?
 

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.

Interesting. If it helps, I have a well tested non-looping moving average function in a component for torch voltage here github.com/rodw-au/showstopper/blob/mast...ents/ohmic3.comp#L92
If I wrote it today I would malloc the storage in the component's startup function instead of using fixed arrays.

Why can't you use more than one thread instead of a FGPA?

 

by way of explanation the moving average uses a simple circular buffer and calculates the sum of readings. Once the buffer is filled, the next reading overwrites the first reading in the buffer. So by deducting that value before it is overwritten and adding the new value as its written, the sum is maintained without any loops. The moving average is simply the sum / buffer size. There is no reason why it could not be called again recursively to calculate the second moving average.

endian wrote:

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.

As far as I know, that’s not entirely right.
For the nano-smoothing function (NURBS interpolation for cloud of points), Fanuc uses non-realtime buffered calculations on the CPU to prepare the trajectory (look-ahead buffer). Then, data from the interpolator is sent to the DSP, where the planner calculates the speeds in real time.

Yes Rod .. it is solution but it is creating constant delay between control position -> DFIR -> current position of tool ....

next stuff what Gemini tells me at Cloud of points topic is - 

* Look-Ahead Buffer CompressionConventional S-curves fail when the "Look-ahead" buffer is too small. If the planner only sees 10 points ahead, it doesn't know it can maintain $F500$ through the next 100 points.The Fix: Use a Compressor or Point Filter.In your trajectory planner settings, ensure the look-ahead is set to at least 100–200 segments.The Approximation: If three points are almost in a straight line, the planner should "ignore" the middle point. This turns a "Cloud of Points" back into a "Set of Vectors," which is much easier for S-curve math to handle.

(before noticed DRIF)
* The "Look-up Table" (LUT) Approximation
If the analytical math (solving cubic equations) is too slow for your CPU, you can use a pre-computed trapezoidal acceleration profile and apply a Finite Impulse Response (FIR) Filter.

The Method: Calculate a standard, "harsh" Trapezoidal move first. Then, run that velocity profile through a "Moving Average" filter.

The Result: The "sharp corners" of the trapezoid become smooth "S" shapes.

* Constraint Decoupling (Axis vs. Path)Latency often spikes when the planner tries to synchronize 3+ axes using 3rd-order math.The Fix: Instead of calculating a full 3D vector S-curve, calculate the S-curve for the Master Path (the total distance) and then linearly project that to X, Y, and Z.The Trade-off: This is slightly less "optimal" for machine time, but it reduces the math complexity by $66\%$, significantly dropping your latency.

* Frequency Domain Filtering (Advanced)
If you are writing the code for the planner, you can use a Low-pass filter on the commanded acceleration.
Generate the "rough" motion.
Pass it through a 2nd order low-pass filter (Butterworth or similar).
This effectively "limits jerk" by removing the high-frequency components (the "thumps") of the motion.

what I can see aproximation or longer thread timing are the only known solutions... but I am not expert in this topic 

endian wrote:

Yes Rod .. it is solution but it is creating constant delay between control position -> DFIR -> current position of tool ....
 

It will not add any delay as it should be applied as the acceleration is calculated or read per servo cycle. Just not sure how you need to use it. 
the size of the buffer is configurable.
Any other published moving average solution wanted to use loops which are a source of delay so I devised this..
One of the cleverest algorithms I have ever coded...