LinuxCNC S-Curve Accelerations

Nice paper you found there!

Your diagrams look much better now, I cannot see any obvious problems. Thumbs up!

Do you think you can make it work with initial acceleration as well? Another thing to try is a very short displacement and large initial velocity, so that displacement overshoot, and the velocity has to change sign to get back to the requested displacement.

Hi,

Do you think you can make it work with initial acceleration as well?
Yes.

Current implementation:
trajectcalculator(double velmax, double accmax, double dccmax, double accbegin, double accend, double vbegin, double vend, double lenght){

[edit]
- Using start acceleration value
- Using end acceleration value
- Using max-acceleration (acc stage)
- Using max-deacceleration (dcc stage)

Grotius wrote: A second question then would be, is it usefull to add a AccEnd value to the program?

No, neither AccEnd nor VelEnd are useful for LinuxCNC. Both AccStart and VelStart are required though.

Grotius wrote: Another thing to try is a very short displacement and large initial velocity, so that displacement overshoot,
Something like attached picture? But there is no overshoot.

No, use a short length and a large Velocity start, so that there is no time to slow down before the displacement has passed the requested length.


There are bugs in your AccStart & AccEnd implementation. Please do more thorough testing of your code. Hint: double-check the actual displacement.

Hi,

In attached code the displacement output is more checked. I expanded this today.
I know the displacement inaccuracy (i have seen value's out of position : 1~4mm).
I have to investegate the cause of this. I think we will find the problem.
My first idea was, it could be a formula imperfection of the used paper.

github.com/grotius-cnc/S-curve-motion-pl...g/releases/tag/1.0.3

I've done a preliminary integration of my code into LinuxCNC now. It's published here , in the branch "smooth1d".

Anyone interested in testing it, please read below!


Some safety notes

Bugs in the planner code can make your machine run away in ways that will neither produce a following error nor trigger soft limits! Make sure your machine has hardwired limit switches, or can tolerate running full speed into its end of travel!

For the same reason, please don't insert any part of yourself into the machine while running this code in its current state.


Things to test:

• Does the code compile and run?
-- You must install a Rust compiler - see instructions for your distro. (This usually involves downloading and running the rustup script.)
-- If you are using a joint.N.jog-accel-fraction HAL pin, you need to comment that out since "acceleration fractions" are no longer needed for jogs, so this pin has been removed.
-- At the moment this code will only compile on PREEMPT systems, not on RTAI.
-- Don't forget to checkout the smooth1d branch before compiling.
-- Please run linuxcnc from the terminal so that you can catch debug printouts if you run into any bugs.


• Does the new planner make a noticeable difference?
  Note that I've only replaced the joint jogging planner, so you should get jerk-limited jogging while the machine is unhomed, and the usual constant-acceleration jogging after the machine is homed. (I think this is how it works?)


• Does homing work as expected?
  Due to the way simple_tp (the constant-acceleration planner) is entangled into the LinuxCNC code, I had to do some rather brusque code cutting in relation to homing, and this needs to be tested.

Known bugs:

• In some situations, the planner fails to find a solution and stops before reaching the intended position. (So some jogs might be shorter than expected.) I'm working on figuring out why. If this happens very often for you, I'd like to know about it.
  
  
• The build integration needs a lot of work. (E.g. 'make clean' doesn't work, RTAPI doesn't work, dependency checking doesn't work... and more)
  
  
• You will see a lot of debug printouts on the terminal (one long line each time a new target position is requested).

Hi Arvidb,

Nice work. I will study your code soon !

I found the in-accuracy of the displacement value's.
I was calculating the (total) lenght's and (total) time of acc and dcc path's wrong for the scurve.
After a code modification all output value's seems correct now. The output is double checked with various formula's.

When studying the (new) attached document (paper), i came to the conclusion the used formula's are identical to the paper i first used.
Then i thought, the displacement in-acurracy problem has to have a different origin.

A sample:


a video : user-images.githubusercontent.com/448801...954-a2350cc98fdf.mp4

For download:
1. hal component code with s-curve library as header only lib
2. qt c++ project
github.com/grotius-cnc/S-curve-motion-planning/releases