New Trajectory Planner - Testers/programs wanted

skunkworks wrote: You where on IRC and I think we hashed it out... What it is doing is queuing up moves to get to the maximum velocity. (it takes a few moves at the start to see far enough ahead - the way I understand it) So if we take your program and run the diamond part twice - you can see it rounds all the corners larger. With strait G64 (no tolerance) that is the radius needed to keep the velocity at 150ipm.

here is a screenshot of the diamond running twice.

So the moral of the story is - make sure you set a tolerance if you don't want excessive rounding... G64Px.xxx

sam

ps here is the program I ran

g64
g18
G0 X-2.000 Z-12.000 f150
G01 X-2.000 Z-12.000 F150
G01 X-6.000 Z-6.000 F150
G01 X-10.000 Z-12.000 F150
G01 X-6.000 Z-18.00F150
G01 X-2.000 Z-12.000 F150

G01 X-2.000 Z-12.000 f150
G01 X-2.000 Z-12.000 F150
G01 X-6.000 Z-6.000 F150
G01 X-10.000 Z-12.000 F150
G01 X-6.000 Z-18.00F150
G01 X-2.000 Z-12.000 F150

g0x0z0
M30

Sorry for the delay getting back to this,

We will definitely be getting that tolerance into configs, most likely into the INI so it is a set value. The operators never mess with G61/64 in their programs, so I am comfortable doing so.

Thanks for the clarification on this one.

Rick

LAIR82 wrote: Sorry for the delay getting back to this,

We will definitely be getting that tolerance into configs, most likely into the INI so it is a set value. The operators never mess with G61/64 in their programs, so I am comfortable doing so.

Thanks for the clarification on this one.

Rick

Because all G code can be changed on the fly a preamble at the start of each file is the only way to know what you have. Take for example if you abort a program in the middle of a G92 offset it is still there when you run the next program unless you have a good preamble.

gnipsel.com/linuxcnc/g-code/gen01.html

JT

Rick - Did you try the latest master? Rob fixed the problem you where seeing with pausing a program and G95

git.linuxcnc.org/gitweb?p=linuxcnc.git;a...510c3ad8f8f4598c0fa6

sam

I did yes, I tried it on my demo pc in the office, looks good now, stops on a dime!!


Thank you!!

Rick

BigJohnT wrote:

LAIR82 wrote: Sorry for the delay getting back to this,

We will definitely be getting that tolerance into configs, most likely into the INI so it is a set value. The operators never mess with G61/64 in their programs, so I am comfortable doing so.

Thanks for the clarification on this one.

Rick

Because all G code can be changed on the fly a preamble at the start of each file is the only way to know what you have. Take for example if you abort a program in the middle of a G92 offset it is still there when you run the next program unless you have a good preamble.

gnipsel.com/linuxcnc/g-code/gen01.html

JT

I am trying to get the post processor modified to include this in the preamble of every program that we use, but I actually have the TP turned off until then. Our guys are resistant to change, so for them to have to remember for now to put that tolerance into the preamble, would be almost impossible.

Rick

Hi Rick,

Sorry it took so long to see this, and that you'll have to turn the planner off for now. Seeing your issue here gave me an idea: would it be useful to be able to set a default path tolerance in your INI file? Right now, the default is "0", which means no applied tolerance. However, this could be an optional value in the INI file passed in to the trajectory planner along with the rest of the INI settings. That way, you wouldn't have to specify the tolerance in your G code for every program.

Conversely, would there be any interest in setting other trajectory planner parameters via G code (and / or HAL)? Dewey Garrett implemented a way to set these parameters through HAL a while back, so it's at least possible to do.

For example, something like this:

could set the lookahead depth to 100 with the R word (or similar).

-Rob