- Posts: 611
- Thank you received: 0
New Trajectory Planner - Testers/programs wanted
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 to join the conversation.
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.
Please Log in to join the conversation.
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
Please Log in to join the conversation.
- rellenberg
- Offline
- Junior Member
-
- Posts: 37
- Thank you received: 0
DaBit wrote: 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.
DaBit wrote: 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 to join the conversation.
- skunkworks
- Topic Author
- Offline
- Platinum Member
-
- Posts: 351
- Thank you received: 0
The current tp seems to be a lot looser
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)
Code: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 to join the conversation.
- skunkworks
- Topic Author
- Offline
- Platinum Member
-
- Posts: 351
- Thank you received: 0
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 to join the conversation.
- rellenberg
- Offline
- Junior Member
-
- Posts: 37
- Thank you received: 0
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 to join the conversation.
Rick G
Please Log in to join the conversation.
- rellenberg
- Offline
- Junior Member
-
- Posts: 37
- Thank you received: 0
Please Log in to join the conversation.
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
Please Log in to join the conversation.
