New Trajectory Planner - Testers/programs wanted

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
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.

rellenberg wrote:

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.

Yes, I have seen that too while doing spiral milling using sin/cos and a lot of G1's (the easy way out, that is).

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

I can run up to about 1400mm/sec^2 also without anything special, but the machine (Chinese mill) doesn't like it. Using limited jerk to soften the hard edges makes a noticeable difference. The downside is that it also fights with software backlash compensation, and it causes a small deviation from the programmed path since it is the servo loop doing the limited jerk and not the motion planner. The backlash bites me during every experiment, but the current method of fixing it is building a new mill. All this experimentation with steppers in velocity mode and a separate PID component in HAL, feedback with linear glass scale, etc. is basically for the new mill although I use the current one for testing ideas.

Being able to do all this is why i love LinuxCNC, by the way.

I will check the actual number of the 'maxa' parameter used for the limit3 component (which is fed velocity, so maxa is jerk) for you tomorrow.

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.

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?

Yes. Probably this weekend I will find an hour or two to build a RIP environment with your TP. If it runs normally, I will use that build for actual milling.
I have no fine-detailed milling jobs to do, but I always wanted to try making a lithophane. All those parallel scanlines carving out a photograph would be a good test for the new TP.

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.

On the other hand: half-decent hobby-class mills are probably not LinuxCNC's main target.
But still, I really think that a lighter machine with top-notch TP can outperform tons of cast iron with a prehistoric control. When using smaller endmills, higher speeds and softer materials (aluminum, plastic, wood) it is the acceleration/deceleration and jerk that strains the machine frame the most, not the forces created by actual milling. IMHO, that is.

I built a RIP environment using the new TP today on the machine connected to the mill. Have not done any testing yet.

Is there a quick way to switch between old and new TP behaviour? Preferrably while AXIS is running a program? (halcmd setp blabla.bla maybe?)

As promised before: the HAL code with jerk limit:

Not exactly nice&shiny and not tuned to perfection, but it does work with little following error and a rounding at the constant velocity->ramping up/down velocity boundary

I finally got some time to pull the experimental branch. It fixes the issue you are seeing. Your program ran at 1828 mm/min.

sam

ArcEye wrote:

Hi

I don't pretend to understand it, but here is a non-scientific test that shows a difference

Run 1 - the patched linuxcnc-beta RIP
Velocity during the spiral in axis_mm sim, with all the [TRAJ] settings made, max velocity set to 3200
1701mm/min

Run 2 - 'standard' RIP of 2.6~pre
Same sim and velocity settings
1828/1813 mm/min fluctuates between 2 as each segment changes

The code is here (it is imperial, but I didn't have a metric equivilent)

G40 G90
G20 G17
G40 G8
F3000
;M3 S600
;G4 P10
;M5
G00 X0.7500 Y0.7700
G01 Z-0.0300
G03X0.7000Y0.7200I0.0000J-0.0500
X0.7500Y0.6700I0.0500J0.0000
X0.8300Y0.7500I0.0000J0.0800
X0.7500Y0.8300I-0.0800J0.0000
X0.6400Y0.7200I0.0000J-0.1100
X0.7500Y0.6100I0.1100J0.0000
X0.8900Y0.7500I0.0000J0.1400
X0.7500Y0.8900I-0.1400J0.0000
X0.5800Y0.7200I0.0000J-0.1700
X0.7500Y0.5500I0.1700J0.0000
X0.9500Y0.7500I0.0000J0.2000
X0.7500Y0.9500I-0.2000J0.0000
X0.5200Y0.7200I0.0000J-0.2300
X0.7500Y0.4900I0.2300J0.0000
X1.0100Y0.7500I0.0000J0.2600
X0.7500Y1.0100I-0.2600J0.0000
X0.4600Y0.7200I0.0000J-0.2900
X0.7500Y0.4300I0.2900J0.0000
X1.0700Y0.7500I0.0000J0.3200
X0.7500Y1.0700I-0.3200J0.0000
X0.4000Y0.7200I0.0000J-0.3500
X0.7500Y0.3700I0.3500J0.0000
X1.1300Y0.7500I0.0000J0.3800
X0.7500Y1.1300I-0.3800J0.0000
X0.3400Y0.7200I0.0000J-0.4100
X0.7500Y0.3100I0.4100J0.0000
X1.1900Y0.7500I0.0000J0.4400
X0.7500Y1.1900I-0.4400J0.0000
X0.3100Y0.7500I0.0000J-0.4400
X0.7362Y0.3102I0.4400J0.0000
G00Z0.1500
G00X0.0Y0.0

G28

M2

Obviously it is not quite the sort of short segment code some others were testing, but there is a real difference in the 'wrong' direction

regards

I finally got some time to pull the experimental branch. It fixes the issue you are seeing. Your program ran at 1828 mm/min.

sam

Hi Sam

I can see the commit on github, but my git fu is not up to figuring out how to get it into my existing clone

git checkout circular-blend-arc-beta-experimental errors
and doing a pull tells me I am up to date

regards

Umm - I don't know.. My git foo isn't very strong. I normally just create another directory with the new branch. (that way it is easy for me to compare without rebuilding)

sam

ArcEye wrote:

I finally got some time to pull the experimental branch. It fixes the issue you are seeing. Your program ran at 1828 mm/min.

sam

Hi Sam

I can see the commit on github, but my git fu is not up to figuring out how to get it into my existing clone

git checkout circular-blend-arc-beta-experimental errors
and doing a pull tells me I am up to date

regards

Hi

I think the problem was that the original was the master with Robs stuff added, whereas this is all in his fork of the master
I just cloned Robs fork, checked out the experimantal branch and built it

It runs at full speed (1828) all the way around, which is an improvement because the bog standard master fluctuated 1828/1813 as every arc segment ended and a new one began

So yeah, works fine as far as I can see

regards

I think the problem was that the original was the master with Robs stuff added, whereas this is all in his fork of the master
I just cloned Robs fork, checked out the experimantal branch and built it

Should installation instructions be changed?

Rick G

Rick wrote:

I think the problem was that the original was the master with Robs stuff added, whereas this is all in his fork of the master
I just cloned Robs fork, checked out the experimantal branch and built it

Should installation instructions be changed?

Rick G

No I think they are fine as they are Rick.

This was in his experimental, Alpha branch, which he wanted confirmation on before pushing over to the Beta that everyone is being asked to test.

I just assumed that they were different branches of the same repo originally, which is where the (my) confusion came from

regards