New Trajectory Planner - Testers/programs wanted

Found another minor hickup, when i stop the execution of a part and continue with "run from here" it ignores the "g64 p0.1 q0.1" that is at the begining of gcode, and it defaults to something like q5 as itnormaly does if no g64 command is issued. So i have to issue an MDI command of g64 p0.1 q0.1 before the "run from here" command.

Unfortunately that is the same for anything using the 'Run from Line' and nothing to do with the TP per se.

Other controllers will go back to the last feed and speed settings, re-start the spindle etc, but the one in Linuxcnc is quite crude.

If you stop regularly for some reason, swarf clearance or whatever, you will be better breaking your code into seperate files, with their own headers and footers to set all the conditions properly for each run

regards

I was preety sure it does not have anything to do with the new TP, so it is a 2.7 pre hickup, since none of the versions before had this issue. I do a lot of "run from here" on daily basis so i am sure it was not doing this before. More testing .......oh goodie !
Regards and thanks fro the prompt reply,
Tom

Using XYZU axis ( 3D print ) - I don't see speed improvement with circular shapes - but using only XYZ axis there is noticeable speed improvement

Why is it so ?

the improvement (look ahead) only is implemented on xyz.

If you switched to velocity extruding - that limitation would be gone.

hackaday.com/2014/05/10/blobless-printin...-velocity-extrusion/

sam

Ps - rob is hoping to expand the lookahead to all axis - but is pretty busy with life right now.

Here are some pics of our turning center running the same program with and without the new TP enabled,

With new TP enabled







Without new TP enabled







And here is the gcode for this

G00 X-2.000 Z-12.000

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.000 F150
G01 X-2.000 Z-12.000 F150

M30
%


Thanks

Rick

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

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.

Attachment not found

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