New Trajectory Planner - Testers/programs wanted

I am cutting at similar feeds 50-100 inches/min, but with much more pathetic accelerations. With the old planner I had the acceleration at 7 inches/ss. With the new planner I've had to back it off to 6 inches/ss. But even with the reduced acceleration, I am still seeing nearly a 20% improvement in run time.

we actually tried the new tp on the K&T a few weekends ago.. The acc is around 10-15in/s^2..

with the old planner - the motion was pretty tame.. With the new planner you could feel it in the floor...

There is some work on s-curve planner - but I think it is a long way from anything viable.. (it only does exact stop and has some constraint violations issues..)

the branch is araisrobo-scurve2 in the linuxcnc.org git.

sam

If the old TP slows down before entering a curve and then gently follows the curve at lower speed because it cannot go back to high speed instantly, there would be less 'shake'. Changing the direction of a moving mass needs a force, with higher cornering speed there is more force, and action = - reaction.

In my case the shake and shudder is less, especially when trying to obtain the same runtime for a program as with 2.5.4 (that needs more than twice the acceleration or a very relaxed G64Pxx).. I am still on 2.6.0~pre RC3 from some time ago though.

Here is a small vid of the new milling-machine-to-be running a gazillion of segments:
Video is pretty bad and more toying around with a new photo camera, but in the end you can see that LinuxCNC is processing segments like crazy. With 2.5.4 runtime almost doubles and when cranking up the acceleration to shorten the runtime the shaking gets far worse.

BTW: when running programs with really short segments at high feeds cranking up the servo thread rate helps a little too.

This is robs planner - combined to ja4 (needs some work)



the same section of code running the old planner..



sam

When I mean there is jerk, I don't mean the jerk you find when you cut out a circle with thousands of lines of GCode. I find jerk in the sense that you have a lot of mass that you're stopping and starting too rapidly, thus you get the shaking of the machine. Now you can just reduce acceleration, but from the videos I see from the TinyG controller perhaps jerk in a constraint/mathematical sense might help us.
Keep in mind I don't enjoy higher math, and am just an end user
Anyways overall the new TP is past excellent when you constrain your maximum feedrate and consequently the resulting jerk. I get a lot faster feedrates, and it's far less variable so I am very happy.

Found another minor hickup, when i stop the execution of a part and continue with "run from here" it ignores the "g64 p0.1 q0.1" that is at the begining of gcode, and it defaults to something like q5 as itnormaly does if no g64 command is issued. So i have to issue an MDI command of g64 p0.1 q0.1 before the "run from here" command.
Otherwise it is for all intents and purposes working flawlessly.
Tom