LinuxCNC S-Curve Accelerations
- grandixximo
- Topic Author
- Offline
- Premium Member
Less
More
- Posts: 132
- Thank you received: 5
24 Oct 2017 01:31 #100709
by grandixximo
LinuxCNC S-Curve Accelerations was created by grandixximo
Is it possible with LinuxCNC to set an S-Curve acceleration that does not effect motion blending?
S-Curve type acceleration has a much smother movement, way less jerky, but i've noticed a slight following error in some situations if it's set on the axis drives, so i was wondering if there is a way to set it directly from LinuxCNC, and if it would be any more precise, if there is not currently, are there plans for future versions?
S-Curve type acceleration has a much smother movement, way less jerky, but i've noticed a slight following error in some situations if it's set on the axis drives, so i was wondering if there is a way to set it directly from LinuxCNC, and if it would be any more precise, if there is not currently, are there plans for future versions?
Please Log in or Create an account to join the conversation.
- Todd Zuercher
- Offline
- Platinum Member
Less
More
- Posts: 5007
- Thank you received: 1441
24 Oct 2017 02:33 #100712
by Todd Zuercher
Replied by Todd Zuercher on topic LinuxCNC S-Curve Accelerations
No, at least not in any released branch of Linuxcnc. There have been some experimental branches where some people have worked on S-curve acceleration/limited jerk. But none of these were ever perfected, and I have no idea of their actual usability on a real machine.
Please Log in or Create an account to join the conversation.
24 Oct 2017 02:47 #100713
by cmorley
Replied by cmorley on topic LinuxCNC S-Curve Accelerations
linuxcnc does'n not have a S curve or jerk limited planer option.
There was work done in two different branches to add it - they were not finished - though very close i think.
The developer on one branch did mention he could ramp up the acceleration while still getting smooth movement.
i doubt you'll see it finished until someone is paid to do it.
Chris M
There was work done in two different branches to add it - they were not finished - though very close i think.
The developer on one branch did mention he could ramp up the acceleration while still getting smooth movement.
i doubt you'll see it finished until someone is paid to do it.
Chris M
Please Log in or Create an account to join the conversation.
30 Oct 2017 02:51 #100998
by Nico2017
Replied by Nico2017 on topic LinuxCNC S-Curve Accelerations
Hi,
if we want to implement such a S shape acceleration model, what would be the files to be looked at and to be modified? I huess it will be related to the trajectory planner.
Nicolas
if we want to implement such a S shape acceleration model, what would be the files to be looked at and to be modified? I huess it will be related to the trajectory planner.
Nicolas
Please Log in or Create an account to join the conversation.
30 Oct 2017 08:56 #101003
by cmorley
Replied by cmorley on topic LinuxCNC S-Curve Accelerations
Here is the git hub branch:
github.com/LinuxCNC/linuxcnc/tree/micges/master/limited_jerk
Might even find the author Micges on IRC
Chris M
github.com/LinuxCNC/linuxcnc/tree/micges/master/limited_jerk
Might even find the author Micges on IRC
Chris M
Please Log in or Create an account to join the conversation.
30 Oct 2017 09:11 #101004
by cmorley
Replied by cmorley on topic LinuxCNC S-Curve Accelerations
I'll point out that this work was based on the previous planner so does not have look ahead.
Chris M
Chris M
Please Log in or Create an account to join the conversation.
- Todd Zuercher
- Offline
- Platinum Member
Less
More
- Posts: 5007
- Thank you received: 1441
30 Oct 2017 12:55 #101014
by Todd Zuercher
Replied by Todd Zuercher on topic LinuxCNC S-Curve Accelerations
Just to inject my 2 cents, I always felt that the old parabolic blending planner actually sort of added a bit of rudimentary jerk limiting by it's self. And I think a good jerk limiting planner will need to incorporate a form of that type of blending (but with the multi line look-ahead added.)
PS: I will gladly volunteer to help anyone willing to work on this with testing on real machines. Unfortunately I do not have the programming skills to tackle it myself.
PS: I will gladly volunteer to help anyone willing to work on this with testing on real machines. Unfortunately I do not have the programming skills to tackle it myself.
Please Log in or Create an account to join the conversation.
30 Oct 2017 13:13 #101015
by VNR
Replied by VNR on topic LinuxCNC S-Curve Accelerations
An easy work could be to add S-curve accelerations only to G0 movements, that is a partial solution, but i usually see machine oscillations due to lack of rigidity only on rapids movements. Just my 2 cents.
Victor
Victor
Please Log in or Create an account to join the conversation.
30 Oct 2017 16:49 #101021
by cmorley
It had arc blending, which certainly helped.
The problem with the two tries at S curve was that they never worked out the problems for all forms of motion (eg threading).
If someone attempted again, I would suggest rather then removing the planner we now have, build a new motion component with S curve planner. Motion was built so it was load-time swappable.
In this way if someone built a planner with S curve that was not suitable for eg threading then it still could be used for routers etc.
This would expose it to more testers and developers. Leaving it in a experimental branch just lets it rot.
Same thing with reverse running planner etc....
Chris M
Replied by cmorley on topic LinuxCNC S-Curve Accelerations
Just to inject my 2 cents, I always felt that the old parabolic blending planner actually sort of added a bit of rudimentary jerk limiting by it's self. And I think a good jerk limiting planner will need to incorporate a form of that type of blending (but with the multi line look-ahead added.)
.
It had arc blending, which certainly helped.
The problem with the two tries at S curve was that they never worked out the problems for all forms of motion (eg threading).
If someone attempted again, I would suggest rather then removing the planner we now have, build a new motion component with S curve planner. Motion was built so it was load-time swappable.
In this way if someone built a planner with S curve that was not suitable for eg threading then it still could be used for routers etc.
This would expose it to more testers and developers. Leaving it in a experimental branch just lets it rot.
Same thing with reverse running planner etc....
Chris M
Please Log in or Create an account to join the conversation.
02 Dec 2017 09:41 #102589
by automata
Replied by automata on topic LinuxCNC S-Curve Accelerations
Hi,
Full jerk limitation with multi-axis look ahead has been the holy grail of trajectory planners for a while.
An easier route to implementing jerk control is to use jerk percentage method. More elaboration is given here:
support.motioneng.com/Software-MPI_04_00...s/diff_mtn_types.htm
Fanuc does something similar. They specify a time for jerk limitation. There is a parameter #1772 which specifies acceleration change time. They also have a similar parameter for jerk change time (parameter #1790). There is a single parameter (#1772) for the trajectory, implying that the jerk is limited for the trajectory and not each individual axes (or joints). No jerk guarantee is provided for jerk limitation for each axis or joint.
While Motion Engineering specifies a percentage for jerk, Fanuc uses a time parameter to limit the jerk.
It should be noted that, the time to execute the acceleration/deceleration part of the motion segment will not change. Hence the overall trapezoidal trajectory planner need not be changed. Only the playout part of the acceleration and deceleration sections need to incorporate the jerk limitation parts.
To implement in linuxcnc, we could find the point where the acceleration/ deceleration is computed and break that segment it into 3 parts. If an acceleration/deceleration segment is represented by a second order polynomial, we can break that polynomial into 3 parts. Two of third order polynimials and one second order polynomial. The formula to compute the 3 polynomials from the original second order polynomial should be straight forward given the boundary conditions.
Point to note for this method is that the acceleration limit for the trajectory will be violation can be computed in case we set jerk percent to 100% using the formula given in the motion engg website (support.motioneng.com/Software-MPI_04_00...s/diff_mtn_types.htm).
On freeing up some time, I plan to take this up. All help is appreciated.
-automata
Full jerk limitation with multi-axis look ahead has been the holy grail of trajectory planners for a while.
An easier route to implementing jerk control is to use jerk percentage method. More elaboration is given here:
support.motioneng.com/Software-MPI_04_00...s/diff_mtn_types.htm
Fanuc does something similar. They specify a time for jerk limitation. There is a parameter #1772 which specifies acceleration change time. They also have a similar parameter for jerk change time (parameter #1790). There is a single parameter (#1772) for the trajectory, implying that the jerk is limited for the trajectory and not each individual axes (or joints). No jerk guarantee is provided for jerk limitation for each axis or joint.
While Motion Engineering specifies a percentage for jerk, Fanuc uses a time parameter to limit the jerk.
It should be noted that, the time to execute the acceleration/deceleration part of the motion segment will not change. Hence the overall trapezoidal trajectory planner need not be changed. Only the playout part of the acceleration and deceleration sections need to incorporate the jerk limitation parts.
To implement in linuxcnc, we could find the point where the acceleration/ deceleration is computed and break that segment it into 3 parts. If an acceleration/deceleration segment is represented by a second order polynomial, we can break that polynomial into 3 parts. Two of third order polynimials and one second order polynomial. The formula to compute the 3 polynomials from the original second order polynomial should be straight forward given the boundary conditions.
Point to note for this method is that the acceleration limit for the trajectory will be violation can be computed in case we set jerk percent to 100% using the formula given in the motion engg website (support.motioneng.com/Software-MPI_04_00...s/diff_mtn_types.htm).
On freeing up some time, I plan to take this up. All help is appreciated.
-automata
Please Log in or Create an account to join the conversation.
Time to create page: 0.116 seconds