New Trajectory Planner - Testers/programs wanted
Thanks, I will give it a try this week.
Rick G
Please Log in or Create an account to join the conversation.
It is useless code but might show some differences and offers an easy way to try different variables.
The NGCGUI sample configuration was used.
To exaggerate the differences the acceleration of the X and Y axis was set to an extremely low rate of .05
Set for inches.
Use MDI to set G64 Pn Qn before running.
This test was done with G64 P.001 Q.001
There is a move to the start location, a lead in Arc then a circular path made of segments and finally a lead out arc.
The velocities
Original TP...
Lead in arc max 4.74 slows at end to enter circular path.
Circular path max 3.82 - 3.32
Lead slows to 1.5
New TP...
Lead in arc max 3.32 slows at end .04 to enter circular path.
Circular path max 5.24 - 5.02
Lead out slows to .05
Highest circular path speeds at 45/135/225/315 deg when X and Y are both moving closest to the same rate.
There appears to be a dramatic increase in the circular path speed 3.82 vs 5.24.
The transition from arc to segment and back again appears to cause more of a slow down.
To try some text samples NGCGUI and true type tracer might be used.
As a side note auto homing seems to ignore the acceleration settings on some moves in both cases.
o<circle_arc_test_b> sub
;simulator test only, not useful for anything
;arc lead in, segmented circular path, arc lead out TP test
;segment is the length of each straight move to make up circular path
;set path tolerance with G64 Pn Qn in MDI before running
#<diameter> = #1 (= 4 diameter)
#<segment> = #2 (=.005 segment size)
#<x_center> = #3 (= 2 X center)
#<y_center> = #4 (= 2 Y center)
#<z_safe> = #5 (= .25 Z safe)
#<Feed_rate> = #6 (= 100 Feed rate)
#<Kerf> = #7 (= .025 Kerf)
#<Lead_in> = #8 (= .25 Lead in)
#<Lead_out> = #9 (= .25 Lead out)
#<Arc_Lead_out> = #10 (= .20 Arc Lead out)
#<Main_cord> = 54
#<Temp_cord> = 55
#<Main_cord_n> = 1
#<Temp_cord_n> = 2
G17 (xy plane)
G20 (inches)
G40 (cancel cutter radius compensation)
G49 (cancel tool length offset)
G90 (absolute distance mode)
G94 (units/min feed rate)
G#<Main_cord>
#<radius> = [[#<diameter> / 2] - [#<Kerf> / 2]]
#<circumference> = [[22/7] * [#<radius> *2]]
#<number> = [#<circumference> / #<segment>]
#<number> =FUP[#<number>] ;number of segments in full circle
(debug, number #<number>)
#<deg> = [360 / #<number>] ; degs each segment
(debug, deg #<deg>)
#<segment_final> = [#<circumference> / #<number>]
(debug, segment final #<segment_final>)
#<Arc_deg_out> = FUP [[#<Arc_Lead_out> / #<segment_final>]]
(debug, arc deg out #<Arc_deg_out>)
G90
G0 Z #<z_safe>
G0 X #<x_center> Y #<y_center>
G10 L20 P#<Temp_cord_n> X0 Y0 Z#<z_safe> (set Temp cord)
G#<Temp_cord>
G0 x[#<radius> - #<Lead_in>] y0
G91 (relative distance mode)
F#<Feed_rate>
G3 x#<Lead_in> R [#<Lead_in>/2]
#<circle_number> = [#<number> + #<Arc_deg_out>]
o100 repeat [#<circle_number>]
G1 ^#<deg>
o100 endrepeat
M63 P0 (turn off digital motion)
G3 x-#<Lead_out> R [#<Lead_out>/2]
G90 (absolute distance mode)
G#<Main_cord>
o<circle_arc_test_b> endsub
Rick G
Please Log in or Create an account to join the conversation.
- skunkworks
- Offline
- Moderator
- Posts: 361
- Thank you received: 150
You can see it if you would run a program like
%
(1" square with rounded corners)
G90 G54 G20
g64
G0 X0 Y.25 Z0
G1 Y.75 F999
G2 X.25 Y1 I.25
G1 X.75
G2 X1 Y.75 J-.25
G1 Y.25
G2 X.75 Y0 I-.25
G1 X.25
G2 X0 Y.25 J.25
M30
if you run this the second time (to be sure the tool is starting at the begining of the line segment) - you can see it slow down at the start of the first line-arc transistion and then again at the last line-arc transistion.
I know Rob has talked about this on the list and is looking at rectifying it. ah - found it
That's by design, though it's not optimal. I abort optimization if a
segment is already in progress , to prevent stepping on tp 's toes. Also,
the optimization doesn't run on the last segment in the queue, because that
segment has the potential to be shortened by a future blend arc.
Both of these problems are fixable. I was looking into how to detect "end
if file" in the code, and it seems that the interp_waiting state
corresponds to the interpreter running out of valid moves (rather than just
having a full queue). If this is the case, then a simple check should be
enough to flag the last move. Similarly, I could make blend arc creation
work on the unchanged portion of a segment in progress.
As far as homing - can you give more info? I have not seen constraint violations in quite a while. (homing and otherwise)
sam
Please Log in or Create an account to join the conversation.
As far as homing - can you give more info? I have not seen constraint violations in quite a while. (homing and otherwise)
I just took the sim NGCGUI ini and reduced the acceleration to the extremely low rate for X and Y. Left Z alone.
When you hit home all there is a combination of slow and fast moves.
O.K. I will add a extra move at the start and an extra move at the end to see what happens.
However the main path shows a substantial improvement in speed, and thus the possibility of maintaining a more constant cut speed during a program. A big deal.
Rick G
Please Log in or Create an account to join the conversation.
- rellenberg
- Offline
- Junior Member
- Posts: 37
- Thank you received: 10
As for the homing issue, I don't think I've seen any violations myself, but I haven't been specifically looking for them during homing. My simulation configs have the homing process cut short, because I got tired of waiting 5-10 seconds every time I loaded the GUI. Nothing that I've changed in this branch should directly affect homing, but it's always possible there are unintended consequences.
Please Log in or Create an account to join the conversation.
As a side note auto homing seems to ignore the acceleration settings on some moves in both cases.
That may not have been clear, I meant with the original TP and the new TP the results are the same.
I added another arc to the end, but did not see an improvement.
Rick G
Please Log in or Create an account to join the conversation.
- skunkworks
- Offline
- Moderator
- Posts: 361
- Thank you received: 150
The homing should be exactly the same as they are simple moves (no blending...)
sam
Please Log in or Create an account to join the conversation.
- skunkworks
- Offline
- Moderator
- Posts: 361
- Thank you received: 150
Please Log in or Create an account to join the conversation.
Can I switch TP behaviour between old/new while running a program by setting a HAL pin/parameter or so?
Please Log in or Create an account to join the conversation.
- skunkworks
- Offline
- Moderator
- Posts: 361
- Thank you received: 150
I haven't done that much milling lately and then only simple, non-short-segment stuff, but so far I haven't noticed strange issues with the new TP. Where the old TP would do an audible slow down/accelerate on segment to segment boundaries the new TP just continues.
Can I switch TP behaviour between old/new while running a program by setting a HAL pin/parameter or so?
Please Log in or Create an account to join the conversation.