New Trajectory Planner - Testers/programs wanted

Paul wrote:

My spiral was made in Inkscape which was saved with thier version of an AutoCad R14 format. That's where the splines come from. I then converted the spiral to polyines.

Thanks...

PK

DaBit wrote:

Skunkworks was faster; I was just going to give the same answer.

This seems to be one of those typical 'welcome to CAM-software' issues. If the new TP is good enough in optimizing line-line transitions, there is virtually no problem anymore since everything can be approximated using line segments. Nice solution? No. Practical? Yes.

skunkworks wrote:

exactly.. And in the future there may be a solution for other segment transitions..

To recap - so far the readahead works with
line-line segments
tangent line-arc segmetns
tangent arc-arc segments

%
G90
F100
G0 X2 Y0
G0 X0 Y0 
G91
G1 X1
G1 X1
G3 X1 Y1 R1
G3 X-1 Y1 R1
G3 X-1 Y-1 R1
G3 X1 Y-1 R1
G1 X1
G1 X1

G90
G0 X0 Y0 
G91
G1 X1
G1 X1
G3 J1
G1 X1
G1 X1
G90
%

Rick wrote:

The new TP runs the arcs and the circle at the same steady speed, so the first portion runs smoother and faster. This speed is somewhat slower than the current TP did the full circle.

Rick wrote:

Where the current TP blends on exiting the circle to the straight the new TP appears not to and prepares for a stop even thought there is a extra lead out move.

rellenberg wrote:

Rick wrote:

The new TP runs the arcs and the circle at the same steady speed, so the first portion runs smoother and faster. This speed is somewhat slower than the current TP did the full circle.

I ran your test file, and I think slowdown you're seeing was fixed in the experimental branch. I'm working on an update to push out to the beta branch that will fix this and a few other minor issues.

Rick wrote:

Where the current TP blends on exiting the circle to the straight the new TP appears not to and prepares for a stop even thought there is a extra lead out move.

I'm seeing this too, and I think it's because Naive CAM is turned on (Q0.001), which combines the lead-out move into a single segment. Since this new single segment is the last move in the program, there is still that pesky exact stop. I'm looking into ways to get around this limitation, but it's surprisingly tricky. There isn't currently a way for the motion module to know that a program is complete. Falling back to a parabolic blend on-the-fly is tricky because parabolic blends have a lower max acceleration. One thing that could work for this is reducing the acceleration that the optimizer sees for the last segment, so that we can safely fall back to parabolic blends on the fly. If that works, I should have a fix out today.

I am also looking into line-arc and arc-arc blends. The good news is, I've managed to get line-arc blends working in some circumstances (see attached). Unfortunately, I'm still working some bugs out, and the line-arc code is rather messier than line-line. The trade-off with circular arc blends is that line-line stuff is mathematically easy, but anything more complicated has to be handled case-by-case. Luckily, as you said, line-line intersections are the most common.

-Rob

skunkworks wrote:

wow - rob, as aways, very impressive. (I am someone that keeps checking you experimental branch to see if you have added any commits.. )