New Trajectory Planner - Testers/programs wanted

I ran your test file and can confirm that it does hit a speed limit of 1701 mm/min during the spiral portion. This is because I scale the maximum velocity of all arc motion slightly to allow safe tangential acceleration. I found during testing that running at the actual maximum speed during tight arcs hits the acceleration limit just from normal acceleration. This means that if we have to slow down in the middle of the arc, the total acceleration will be greater than the limit. A good analogy here is driving a car around a corner at the limit of the tires' friction. If you're a great driver, you can keep it on the road, but if you have to hit the brakes suddenly, you'll likely slide out and crash.

What you're seeing is the maximum speed of the machine (1828mm/min) scaled down by sqrt(sqrt(3)/2). This scaled velocity corresponds to sqrt(3)/2 * max acceleration, which means we have 0.5* max acceleration free for tangential acceleration.

What I realized looking at your results is that I applied this scale factor to every circular arc in the program, without checking if it actually needed scaling. This means that large-radius arcs could have a higher maximum velocity. This is a subtle bug with an easy fix. I'll post a fix shortly in my experimental code branch , and move it to the beta branch if it passes the tests.

Thanks for tracking this down! I doubt I would have seen this myself, as my test code does not often hit the maximum machine velocity.

Regarding the above spiral test what values were used for G64 P & Q?

Rick G

@Rick, I ran ArcEye's test with P0.0 and Q0.0, since the code didn't specify a G64 explicitly.

Hi Rick

Rick G wrote: Regarding the above spiral test what values were used for G64 P & Q?

Rick G

I ran it with P0 Q0 by default the first time, because G64 was enabled without any values set

I tried a few modest values then and found it did not make any difference, which appears to be because the governing
factor was a built in limit on arc velocity rather than how tight or loose the plot following was.

regards

rellenberg wrote: Engraving-type toolpaths are definitely where these changes can help, especially on faster machines. I'm always looking for more test cases, so if you have code that works well (or conversely, shows any performance losses), it would be a great help.

I will see if I can generate some code using 'cheap CAM software'. My handcrafted code is more optimal for LinuxCNC, although I see/hear slowdowns when going from a line segment to a tangent arc. Especially with low blending tolerances.
But I think I will pull your branch , build it, and just start using it. Let's see how it holds up.

Here is my original proposal for this method, which describes the main concepts and what tradeoffs there are.

Thanks! It just interests me; I am one of those masochists that want to know how it works :laugh:
Trajectory planning is one of those subjects that seem simple until you dive into them. I scanned through your document, but have to read it more thorough to fully understand it.

I'm interested in limited jerk planning as well, and have done a fair amount of reading / research into the subject. My conclusion initially was that limited jerk planning might not be worth the effort if we can't attain high movement speeds.

I disagree. Limited jerk planning is not worth the effort if you cannot do high acceleration. It has little to do with speed.
Imagine driving a car at speed X and the need to brake to a halt. Trapezoidal velocity / infinite jerk profile is pressing the brake with a constant pressure and keeping it there until velocity=0. The moment your speed reaches zero, a shock passes through the car. The complaints of the passenger grow with deceleration, not with initial speed.

It is this shock that you want to get rid of. Especially on not too rigid 'hobby class' machines such as routers and only-250-pounds-iron Chinese mills.

With my current mill I can do about 500-750mm/sec^2 acceleration using the standard motmod->stepgen flow before the shudder becomes too bad when milling small features in softer materials.
When running a 'servo loop' using the stepgen in velocity mode, a PID-controller to generate the velocity and a limit3 component between the PID output and stepgen velocity input to limit jerk I can do much better. 1200mm/sec^2 for EMC, 1500-1750mm/sec^2 for stepgen/limit3. But it does give a deviation from the programmed path since motmod spits out trapezoidal motion. The motor initially falls behind since acceleration has to be ramped up, then has to catch up, and finally overshoots since deceleration has to be ramped up too. So this method is useable only to remove the 'sharp edges' at most.

With the stock trajectory planner, the only way to get high speeds with small segments is to turn the acceleration up.

And acceleration is useful. Unless you are only milling large squares with rounded corners I would trade high speed for high acceleration anytime. Even with perfect blending you do need a high acceleration to follow a circular path at some speed.

Even though the new TP is technically infinite jerk, it means that you don't need to crank accelerations up really high to reach your desired feeds in fine work. If your toolpaths are very smooth, you might be able to cut your axis accelerations

Lowering the acceleration is a bandaid to lessen the 'shudder' problem caused by infinite jerk and less than perfectly stiff frames. But a useable bandaid is still a practical solution..

Good points on the value of limited jerk. What I meant by "high speed" was simply that the original trajectory planner was running artificially slowly due to the segment length. This meant that you could have a toolpath that had gentle curvature, but it would still run very slowly. In these circumstances, movement speed was slower than what you'd expect from cornering acceleration, so there were gains to be made even with the same conservative acceleration settings.

With my current mill I can do about 500-750mm/sec^2 acceleration using the standard motmod->stepgen flow before the shudder becomes too bad when milling small features in softer materials.
When running a 'servo loop' using the stepgen in velocity mode, a PID-controller to generate the velocity and a limit3 component between the PID output and stepgen velocity input to limit jerk I can do much better. 1200mm/sec^2 for EMC, 1500-1750mm/sec^2 for stepgen/limit3. But it does give a deviation from the programmed path since motmod spits out trapezoidal motion. The motor initially falls behind since acceleration has to be ramped up, then has to catch up, and finally overshoots since deceleration has to be ramped up too. So this method is usable only to remove the 'sharp edges' at most.

I'm impressed that limited jerk allowed you to run at almost twice the acceleration. What was the maximum jerk for this case?

And acceleration is useful. Unless you are only milling large squares with rounded corners I would trade high speed for high acceleration anytime. Even with perfect blending you do need a high acceleration to follow a circular path at some speed.

Also a good point; acceleration limits your maximum speed in small features because of the tight curvature.

Since you've had first-hand experience with the limits of infinite-jerk planning, would you be willing to test the new TP on your machine? Since the trajectory planner can achieve higher speeds, the higher cornering acceleration may introduce more jerk to the machine as well. It would be really informative to get a real world test of fine-detail work. The new TP has some large theoretical gains, but if we can't fully reach them without shaking the machine to death, it would make a good case for a limited-jerk version.