New Trajectory Planner - Testers/programs wanted
13 Jan 2014 15:16 #42683
by Rick G
Replied by Rick G on topic New Trajectory Planner - Testers/programs wanted
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
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.
14 Jan 2014 20:44 - 14 Jan 2014 20:56 #42760
by DaBit
Replied by DaBit on topic New Trajectory Planner - Testers/programs wanted
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.
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.
15 Jan 2014 01:24 - 15 Jan 2014 01:25 #42777
by ArcEye
Replied by ArcEye on topic New Trajectory Planner - Testers/programs wanted
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)
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 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.
- rellenberg
- Offline
- Junior Member
Less
More
- Posts: 37
- Thank you received: 10
15 Jan 2014 02:07 #42779
by rellenberg
Replied by rellenberg on topic New Trajectory Planner - Testers/programs wanted
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.
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.
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.
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.
- skunkworks
- Offline
- Moderator
Less
More
- Posts: 361
- Thank you received: 150
15 Jan 2014 02:13 #42780
by skunkworks
Replied by skunkworks on topic New Trajectory Planner - Testers/programs wanted
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
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
Please Log in or Create an account to join the conversation.
- skunkworks
- Offline
- Moderator
Less
More
- Posts: 361
- Thank you received: 150
15 Jan 2014 02:22 #42781
by skunkworks
Replied by skunkworks on topic New Trajectory Planner - Testers/programs wanted
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.
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.
- rellenberg
- Offline
- Junior Member
Less
More
- Posts: 37
- Thank you received: 10
15 Jan 2014 03:08 #42782
by rellenberg
Replied by rellenberg on topic 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.
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.
15 Jan 2014 14:10 #42807
by Rick G
Replied by Rick G on topic New Trajectory Planner - Testers/programs wanted
Regarding the above spiral test what values were used for G64 P & Q?
Rick G
Rick G
Please Log in or Create an account to join the conversation.
- rellenberg
- Offline
- Junior Member
Less
More
- Posts: 37
- Thank you received: 10
15 Jan 2014 14:17 #42808
by rellenberg
Replied by rellenberg on topic New Trajectory Planner - Testers/programs wanted
@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.
15 Jan 2014 15:09 #42809
by ArcEye
Replied by ArcEye on topic New Trajectory Planner - Testers/programs wanted
Hi Rick
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
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