LinuxCNC S-Curve Accelerations

More
7 months 2 days ago #344940 by endian
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 
The following user(s) said Thank You: akb1212

Please Log in or Create an account to join the conversation.

More
7 months 2 days ago #344947 by rodw
Replied by rodw on topic LinuxCNC S-Curve Accelerations

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...
The following user(s) said Thank You: endian

Please Log in or Create an account to join the conversation.

More
7 months 2 days ago - 7 months 2 days ago #344958 by endian

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...
 
 
I think the best way to apply that... its consulate with Luca or Yang Yang if they are allready not using something like that now...  I'm not that familiar with their code till now ... it toooo way complicated for me

my next observation is - high value of G64 tolerance around 0.1(650us spikes) is spiking more than 0.001(250us spikes)

best setup till now ... most influential spiking thingy is the 
Code:
OPTIMIZATION_DEPTH... this creates real mess
Code:
ARC_BLEND_ENABLE = 1 ARC_BLEND_FALLBACK_ENABLE = 1 ARC_BLEND_OPTIMIZATION_DEPTH = 8 ARC_BLEND_RAMP_FREQ = 64 ARC_BLEND_GAP_CYCLES = 64 TC_QUEUE_SIZE = 200
Last edit: 7 months 2 days ago by endian. Reason: setup add
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

More
7 months 1 day ago #344976 by NWE
Replied by NWE on topic LinuxCNC S-Curve Accelerations

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

 
Thanks, I've been wondering too. I've been dreaming about kinematics using multiple realtime threads. Does anyone know whether/why it would not do?

Please Log in or Create an account to join the conversation.

More
7 months 1 day ago #344979 by ewlsey
Go easy on me. I tried to read through this whole thread, but there's a lot to digest. 

How does the current linuxcnc approach compare to how S curve acceleration is being done in GRBLHAL? 

I've tried to read the linuxcnc servo loop code, but it's pretty well impenetrable. 

However, GRBLHAL is very cleanly written and well commented. From what I can see, it has many features discussed here.

It has a backwards (and forwards) buffered trajectory planner with prescribed tangential acceleration. It has buffered segment interpolation. Both run outside the realtime loop, but the segment buffer is fast enough for feed overrides and holds to feel instantaneous. 

I know it's not a "real" control, but it's pretty amazing they could get all that to work (along with g-code interpreter, etc) on an 8 bit AVR microcontroller. 

The current HAL version offers jerk limited acceleration, though I have to say its utility is a bit questionable for industrial machines. I believe the GRBL equivalent of the "servo loop" only runs at 100Hz, so you would need really low jerk values to see an effect. But, the framework seems sound.

Please Log in or Create an account to join the conversation.

More
7 months 1 day ago #344980 by NWE
Replied by NWE on topic LinuxCNC S-Curve Accelerations

Go easy on me. I tried to read through this whole thread, but there's a lot to digest. 

--snip--

I know it's not a "real" control, but it's pretty amazing they could get all that to work (along with g-code interpreter, etc) on an 8 bit AVR microcontroller. 

 
Just now I discovered:
GRBLHAL = 32 bit
GRBL = 8 bit
Thanks for bringing this up. A long time ago I read all about GRBL 8-bit and sort of gave up on it. Now I notice the main project is 32 bit. Now that seems worthwhile. Cheap 32-bit MCUs today pack some punch.

That said, I'll leave the S-curve talk for the pros.image missing /media/kunena/emoticons/smile.png

Please Log in or Create an account to join the conversation.

Time to create page: 0.091 seconds
Powered by Kunena Forum