LinuxCNC S-Curve Accelerations

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

Hi, folks!

Dreaming about smoother movement with LCNC i have found and sucessfully try on Arduino Due this code:
github.com/synthetos/g2
with well-described jerk-controlled motion:
github.com/synthetos/g2/wiki/Jerk-Controlled-Motion-Explained

Are there any chance to recompile and intregrate this math to LCLC?

Hi BesPav,

Do you have a direct link to the math please?

Grotius wrote: Do you have a direct link to the math please?

Hi, Grotius!

I have zipped some planner sources with all those crazy discrete time and differential math, fortunately they have good comments, please check if this is what you wanted.

you can look at this github.com/rmu75/linuxcnc/tree/rs_6otp for an implementation of the 6th order bezier curve. the discrete diff math is not needed in linuxcnc, cpus powerful enough to run linuxcnc are powerful enough to use floating point and "direct evaluation".

I included a ipython notebook for those who want to play around with the bezier curves. , rename extension to .ipynb

Hi,

@ Rmu,
If this linuxcnc repro is working out of the box, wich i don't know at the moment, would be helpfull.
Then a diff to master will tell us what has to be modified for the scurve implemenation.

@BesPav,
There is no real scurve math inside. It looks like they hide it somewhere else.

I am working on a hal component that includes the scurve implemenation.
The user can request values for a certain timestamp. And it also gives other important values.
It is in fact a complete implementation of the first paper i posted before.
I think it will also be usefull to soft start spindles etc.

velocity start=1
velocity end=0
acceleration start=2
de-acceleration end=3 (machine can stop quicker)
A output example with halscope : user-images.githubusercontent.com/448801...a56-f8b83324c0b9.mp4

hi arvidb
I start testing your branch "smooth1d".
I seem to have compiled everything correctly. maybe )
But I didn't notice the difference. Can you explain How to configure your function? for Dummies

Grotius wrote: Hi,

@ Rmu,
If this linuxcnc repro is working out of the box, wich i don't know at the moment, would be helpfull.
Then a diff to master will tell us what has to be modified for the scurve implemenation.

It is just a few commits, and last I tried it rebased relatively cleanly on master. The math is in the ipython notebook, and there is another thread in this forum discussing the whole thing. github.com/rmu75/linuxcnc/blob/rs_6otp/src/emc/tp/tp.c#L2436 contains a description of the approach. Some familiarity with Bezier curves is expected, wikipedia should do it for starters. In principle it is the same what the tinyG thingy does, transplanted into the "execution" stage of the linuxcnc trajectory planner.

Caveat emptor, this thing is not finished and may explode your machine and/or computer, esp. if you use feed override (which will have very unpredictable effects).

TheRoslyak wrote: hi arvidb
I start testing your branch "smooth1d".
I seem to have compiled everything correctly. maybe )
But I didn't notice the difference. Can you explain How to configure your function? for Dummies

Thanks for testing!

It's quite possible that most people won't notice much of a difference with jerk-limited planning. I think it will have the most effect on heavy machines with a very tight servo loop and where an MPG is used for jogging. How did you test it?

There should be no configuration needed. If the jerk-limited planner is active, you will see debug printouts such as these on the terminal each time a new move is planned: Did you see such printouts? If not, make sure you are jogging in joint mode, since the joint planner is the only planner that I replaced. Once the machine is homed and in axis jog mode, the old planner is still used.