Advanced Search

The sp_scurve code is based on S-curve (7-segment) trajectory planning mathematics, which uses jerk-limited motion profiles derived from the kinematics equations of motion.

Mathematical Foundation
The core math is based on third-order polynomial motion equations with controlled jerk (rate of change of acceleration):


Position: P(t) = P₀ + V₀·t + ½·A₀·t² + ⅙·J·t³
Velocity: V(t) = V₀ + A₀·t + ½·J·t²
Acceleration: A(t) = A₀ + J·t
These equations appear explicitly throughout the code (e.g., lines sp_scurve.c:187-197, 842-844, 1089-1091).

Key Mathematical Components
7-Segment S-Curve Profile - The trajectory is divided into 7 phases (S0-S6/n0-n6):

S0: Increasing jerk (acceleration ramps up)
S1: Constant acceleration
S2: Decreasing jerk (acceleration ramps down to 0)
S3: Constant velocity (cruise)
S4: Decreasing jerk (deceleration begins)
S5: Constant deceleration
S6: Increasing jerk (deceleration ramps to 0)
Cubic Equation Solving - The solve_cubic() function at lines 80-184 solves cubic equations using Cardano's formula and trigonometric method for finding roots.

There is a Newton-Raphson Method - The solute() function at lines 54-68 uses Newton-Raphson iteration to solve polynomial equations, but it is not in use, Cardano's formula is computationally superior.

Stopping Distance Calculation - Based on the relationship Amax² = V·J + 0.5·a² (line 949), derived from integrating the jerk-limited motion equations.

Attribution
The code credits go to 杨阳 (Yang Yang) as the original author, he also referenced a Chinese technical document at doc88.com/p-9119146814737.html for the S-curve formulation.

Thnk you , for fast respond
Today I try again with your advice I and D change to 0 and clear all paremeter in calibration box
again its not help
now
X axis
P 17 , I = 0 , D = 0
deadband same result can't touch
I try re config FF0 FF1 FF2 but not any change
now FF0 = 0 FF1 = 0.04 FF2 = 0

but there is still a slight vibration/noise at standstill that I cannot get rid of yet.

FYI : DELTA ASDA-A3 750w

Thank you again for your help.
Asis,

Good job my friend!
Can you provide any paper or info of the math background you used for it?

I bought a similar grease gun. You can get cheaper ones off ebay if you search for Jiabara threaded style for 70-80 gram tubes. 
The tubes are a clever accordion that screws onto the grease gun.
I did not like the nozzle/rigid stem. It locks on really tight. So maybe the real deal works better.
If you have old LM blocks with brittle plastic, you risk the chance of pulling the grease fitting out of the plastic threads. 
Be aware that some manufacturers use grease fittings with an odd pitch of M6x0.75! In case you need to modify something.

I have a machine that recommends 2 different greases. NSK Grs AS2 for the LM blocks and LR3 for the ball screws. AS2 is probably fine for both. 

I'm thinking of adding a centralized lubrication system to my current project instead of trying to access each block under the way covers. 
I have used Bijur pump and metering units adapted to ball screws and LM guides in the past using vactra no2.
I'm interested in finding out what others are doing that is more of a modern system. 
I know Haas went through a couple of redesigns with their remote lube/grease systems.
 

Did you try lowering the acceleration?
The default of 750mm/s/s is to much for some machines.

github.com/grandixximo/linuxcnc/tree/9d

This is phase 0 completed, according to my plan, this is extremely experimental work in progress, there are known issues at the moment, no arcs no blends, no scurve, as illustrated by the plan you can find at this post, which I got not much feedback..

forum.linuxcnc.org/38-general-linuxcnc-q...ons?start=640#341856

Next phase it is IMO too hard to be vibe coded, but I will try in my spare time.

The issue with the original code was it was developed with a machine that homes to index so it does not work cleanly with home to sensor. The real problem  is that during device homing, Linuxcnc throws following errors because it has not commanded movement. What generally needs to happen is the position feedback is synced with commanded position so Linuxcnc is happy. This is why most working solutions also provide their own cia402.comp

Yes, I think homing can be standardized for cia402 devices and the new home comp is there now to support that. So much of homing.c becomes irrelavent with device homing so the homecomp allows control of what is needed. I've had a couple of goes at it. The first was obsoleted by a rewrite of the homecomp paradigm.

The cia402 state machine is actually very simple. very linear with the exception of error and safety steps to prior states. The flowchart here is a good resource
www.kebamerica.com/blog/comprehensive-gu...a-402-drive-profile/

Anyway, back on task. It occurred to me that I had included some standard PDO's that are not reported by Ethercat pdos. I will revisit that. 

 

Thanks for your reply @andypugh

I copied and pasted your suggestion into my HAL file, replacing the original erroneous text.

Unfortunately when launching Linuxcnc, an error is shown up as attached in the .png file.

Revised HAL file also attached.

Regards

Phil

I mostly run G64 P0.05 in metric, G64 P0.002 in inches, G61 is afterthought for us, but will be tested...

the on screen button and physical button cannot remain synchronized as the screen cannot physically change the mushroom buttons state. so you will need to add in some hal NOT allowing the UI estop button in probe basic to be in a state different from the physical mushroom button.

github.com/LinuxCNC/linuxcnc/issues/3717

(No solution yet)

You could quickly check if those have the desired affect by opening halshow, opening the "watch" tab and picking those pins from the tree. Then you can set values directly.

If that works then link them up in HAL.

One advantage of the Pi is that it is perfectly reasonable to have an identical spare to swap in in case of trouble.

This feels like possibly a race condition, I wonder what happens if the queue-empty check is just disabled?
(ie, I wonder if it indicates a real problem?)

I use gmoccapy.

So far, I have found that these two signals control the feed rate:
gmocacapy.spc-feed.value
gmocacapy.spc-speed.value