New Trajectory Planner - Testers/programs wanted

More
22 Jan 2014 20:43 #43077 by Rick G
ArcEye,

Thanks, I will give it a try this week.

Rick G

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

More
24 Jan 2014 16:12 - 24 Jan 2014 16:15 #43122 by Rick G
Here a NGCGUI sub was used to compare the original and the new TP.
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
Attachments:
Last edit: 24 Jan 2014 16:15 by Rick G.

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

More
24 Jan 2014 20:07 #43124 by skunkworks
I think there, and rob will have to weigh in here, that the first and last segment do not get blended well yet. (so your lead-in and lead-out arc probably slow more than previously..)

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.

More
24 Jan 2014 20:49 #43125 by Rick G

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.

More
26 Jan 2014 02:34 #43162 by rellenberg
Based on feedback from the dev list, it may be difficult to fully optimize the last segment, since the TP doesn't know when a program is done, vs. just waiting on more commands. However, one workaround to this is to make your last move of the program a rapid retract away from the part. Since the last step in the part is no longer the last step in the program, you'll still get a smooth cut.

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.

More
26 Jan 2014 17:00 #43190 by Rick G

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.

More
27 Jan 2014 23:23 #43237 by skunkworks
You are still not clear... :)

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.

More
27 Jan 2014 23:58 - 27 Jan 2014 23:59 #43239 by skunkworks
I posted this on the list - but what the heck - I like redundancy...

This is the above program with a lead-in, out path..



Current TP strait G64 - peaks at 159ipm


New TP strait G64 - peaks at 222ipm


Current TP G64P.001Q.001


New TP G64P.001Q.001
Last edit: 27 Jan 2014 23:59 by skunkworks.

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

More
28 Jan 2014 00:34 #43240 by DaBit
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.

More
28 Jan 2014 02:34 #43243 by skunkworks
I don't think so - they are ini settings...

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.

Time to create page: 0.282 seconds
Powered by Kunena Forum