New Trajectory Planner - Testers/programs wanted

More
13 Jan 2014 15:16 #42683 by Rick G
Interesting results in the path comparisons. I have gotten into the habit of specifying both the P and Q on all my files.
While looking at the velocity results with the old TP I set the acceleration incredibly low to exaggerate the results.

When I tried moves that should be combined on the sim say...
F20
G1X0
G1X10
G1 X20
Once up to speed completed the moves at a constant speed of 20. As expected.
F20
G1X0
G1X10
M5
G1 X20
Slowed to a stop at the M5 then accelerated off. As expected.
F20
G1X0
G1X10
M63
G1 X20
Accelerated to the speed of 20 then a slight dip at the M63 (perhaps 19.995?) stayed at that speed then jumped back to 20 to finish the move. The dip in speed was very slight but showed on the sim.

When I use a M3/M4 I normally program a pause for the spindle to reach speed.
However it seems there would be advantages to have some Mnn perhaps some user defined M codes that did not break blending.
In my case I would like to turn a plasma torch off without bringing the machine to a stop. It appears I can do this with M63 on the old TP. (of course I will have to complete building the table to actually try)

Thank you,

Rick G

Please Log in or Create an account to join the conversation.

More
14 Jan 2014 20:44 - 14 Jan 2014 20:56 #42760 by DaBit
Robert for president!

The very conservative motion planner of LinuxCNC was one of my complaints about the system. 3D contouring toolpaths manage to slow down the current TP to a crawl, and even at tangant line-arc transitions I could hear the motors slow down and accelerate. I wil definitely give this new code a try.

Is there more information about this new TP anywhere? How far can it look ahead the programmed path? How does it work? Any plans for jerk/jounce limited motion? Etc.
Last edit: 14 Jan 2014 20:56 by DaBit.

Please Log in or Create an account to join the conversation.

More
15 Jan 2014 01:24 - 15 Jan 2014 01:25 #42777 by ArcEye
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
Last edit: 15 Jan 2014 01:25 by ArcEye.

Please Log in or Create an account to join the conversation.

More
15 Jan 2014 02:07 #42779 by rellenberg
:laugh: Thanks! It wouldn't have been possible to get here without all the help from the community and the many hours of testing from other developers and users like skunkworks.

The very conservative motion planner of LinuxCNC was one of my complaints about the system. 3D contouring toolpaths manage to slow down the current TP to a crawl, and even at tangent line-arc transitions I could hear the motors slow down and accelerate. I will definitely give this new code a try.


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.

Is there more information about this new TP anywhere? How far can it look ahead the programmed path? How does it work? Any plans for jerk/jounce limited motion? Etc.


Here is my original proposal for this method, which describes the main concepts and what tradeoffs there are. Circular arc blending is not a perfect solution, but there were a number of advantages to the method. It works by inserting tangent arc segments in between line pairs as they are added to the queue. An optimization similar to "lookahead" walks over the queue and calculates the maximum safe velocity for each segment (this runs only when a new segment is added). The new TP also handles tangent segments without slowing to a stop, which means that motion can be much faster than the speed limit imposed by having to stop at the end of each segment.

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 suspect that at least part of the perceived need for limited jerk comes from how machines are tuned for linuxcnc. With the stock trajectory planner, the only way to get high speeds with small segments is to turn the acceleration up. Unfortunately, this leads to bigger jerk spikes.

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 in half or more without a major loss of performance (in terms of total program time).

All this aside, I'd love to be able to do limited jerk planning at some point. There are other development efforts such as araisrobo's linuxcnc mirror which have implemented limited jerk planning and NURBS. It's an exciting prospect, though I haven't kept up with their development recently.

Please Log in or Create an account to join the conversation.

More
15 Jan 2014 02:13 #42780 by skunkworks
I am seeing that too with the axis_mm.ini. The only thing I can see is that the path following is a bit different between the two..

The current tp seems to be a lot looser

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

Attachments:

Please Log in or Create an account to join the conversation.

More
15 Jan 2014 02:22 #42781 by skunkworks
my config (english) with 500ipm and 30in/sec^2 on each axis..
new TP peaks at about 5100mm/min -> runs program in 5 seconds.

old TP peaks at about 4000mm/min - runs the program in 6 seconds.

Please Log in or Create an account to join the conversation.

More
15 Jan 2014 03:08 #42782 by rellenberg
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.

Please Log in or Create an account to join the conversation.

More
15 Jan 2014 14:10 #42807 by Rick G
Regarding the above spiral test what values were used for G64 P & Q?

Rick G

Please Log in or Create an account to join the conversation.

More
15 Jan 2014 14:17 #42808 by rellenberg
@Rick, I ran ArcEye's test with P0.0 and Q0.0, since the code didn't specify a G64 explicitly.

Please Log in or Create an account to join the conversation.

More
15 Jan 2014 15:09 #42809 by ArcEye
Hi Rick

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

Please Log in or Create an account to join the conversation.

Time to create page: 0.100 seconds
Powered by Kunena Forum