Reply with Quotehere is an example of the current development. This is a 533k file all short line segments.
Old TP 2H:53M G64P.0025Q.0025
New TP 1H:33M same tolerance.
New Trajectory Planner - Testers/programs wanted
A linuxcnc developer has made some impressive improvements to linuxcnc trajectory planner. At this point we think it may be stable enough to have a wider group test it.
Some history.
Currently the trajectory planner in linuxcnc uses parabolic blends to transition between segments. It also has the limitation that it has to be able to stop by the end of the next segment. (effectively making have 1 segment look-ahead.) For most things - this isn't a problem. As you get into higher speeds like routing and such - the limitation starts to show itself.
Robert (the developer working on this) has added circular blending to the TP. This allows him to calculate what is need to look further ahead in the programmed path. (As I understand it - the math is harder with parabolic blends). He has not solved for every segment-segment transition. Currently he has look-ahead working for
Line-line transitions
Tangent line-arc transitions
Tangent arc-arc transitions
He hopes to study other transitions and add them in the future. His main plan was getting line-line transitions working as that is what a lot of 3d tool paths out of cam software produces. Any unhanded transitions fall back to parabolic blends. (so it still blend but has to slow back down to current TP performance)
Here is an example of the performance increase - this config is 500ipm - 30in/sec^2 (sorry - pretty crappy video)
The current tp peaks somewhere around 100ipm(first run) - the new tp peaks over 400ipm(second run)
To test this you need to build the rip version of linuxcnc.
These are the basic steps..
You will want to get familiar with this
LinuxCNC Documentation Wiki: Installing LinuxCNC
The basic steps in terminal
git clone git://git.linuxcnc.org/git/linuxcnc.git linuxcnc-beta
cd linuxcnc-beta
git remote add github-robE https://github.com/robEllenberg/linuxcnc-mirror.git
git fetch github-robE
git checkout -b 3d-blend-arc-techdemo github-robE/circular-blend-arc-beta
cd src
./autogen.sh
./configure --enable-run-in-place
make
sudo make setuid
cd..
. ./scripts/rip-environment
linuxcnc
^ that should launch the run in place version linuxcnc with the new TP...
It is basically the same as the wiki link except it is also pulling the patches from Robs branch.
You are almost done... There are some changes to the ini file
In the [TRAJ] section you need to add a few lines
ARC_BLEND_ENABLE = 1
ARC_BLEND_FALLBACK_ENABLE = 1
ARC_BLEND_OPTIMIZATION_DEPTH = 50
ARC_BLEND_SMOOTHING_THRESHOLD = 0.4
So - to run the RIP version
Open terminal
cd linuxcnc-beta
. ./scripts/rip-environment
linuxcnc
This is still pretty new - so be careful and let us know of any issues..
Also - if you have some gcode programs that you think would be a good test for the new tp - please post them.
sam
Similar Threads:
here is an example of the current development. This is a 533k file all short line segments.
Old TP 2H:53M G64P.0025Q.0025
New TP 1H:33M same tolerance.
I cannot edit the main post - so I am updating here..,
Rob pushed his branch to the linuxcnc repository. This makes building a little quicker and debs should be available soon.
This is quite an improvement not only does it look ahead for these segment
Line-line transitions
Tangent line-arc transitions
Tangent arc-arc transitions
it also does
non-Tangent line-arc transitions
non-Tangent arc-arc transitions
The directions have changed slightly now for building.
git clone git://git.linuxcnc.org/git/linuxcnc.git linuxcnc-rc1
cd linuxcnc-rc1
git branch --track circular-blend-arc-rc1 origin/circular-blend-arc-rc1
git checkout circular-blend-arc-rc1
cd src
./autogen.sh
./configure --enable-run-in-place
make
sudo make setuid
cd..
. ./scripts/rip-environment
linuxcnc
The [traj] section of the ini has also changed a little bit.
ARC_BLEND_ENABLE = 1
ARC_BLEND_FALLBACK_ENABLE = 0
ARC_BLEND_OPTIMIZATION_DEPTH = 50
ARC_BLEND_GAP_CYCLES = 4
ARC_BLEND_RAMP_FREQ = 20
(I don't have a good explaination for the last 2 lines yet.. Will add it when known)
eep.
ok, so I was just setting up my xzero router today. mach3 contouring bug makes it a no go, so ive got emc2 on there. as Im sure you remember, I HATE emc's contouring, so can you tell me if this solves the issues I have with it?
g64 sticks to the path, deviates at the corners, but rounds too much at speed. this we all know BUT
1: g64 plus any p or q number causes the path to wildly deviate all over, even on long straight lines! it doesn't just round corners. therefore you need to set p to something like 0.0005" or less to get an accurate part. of course, then the thing gets insanely slow.
2: g64 causes an otherwise finely detailed path curve to become highly faceted. basically, the exact opposite of what you want out of it. its not "rounding" corners, its really just recreating them in the wrong spot.
if this new trajectory planner solves this, id like to give it a try right away. it would then be as good as mach3, without the stalling. mach3 has 1000 line look ahead btw.
oh and for suggestions:
1: do NOT smooth transitions between cuts and rapid moves. there should be an automatic shift to exact stop mode here.
2: likewise g64 should "disengage" on other circles that wont need it, drilling, tapping, etc. this is because some people/cam software will just put 64 at the top of the program as a catch all.
3: helical moves (g2 and g3 in 3 axes) should use 64, in addition to the lines and arcs. id venture to say that these are the only things that require it. (maybe nurbs too, although I know nothing about that part of emc2 and cant see ever using it in practice)
Hey - we would love your input.
This is a good reference of the work being done. A good read.
LinuxCNC Support Forum :: Topic: New Trajectory Planner - Testers/programs wanted (1/14)
There are some changes on how to build that I hope to nail down in the next day or two - so the above directions will work - just chage rc1 to rc3
Couple of answers I think..
1: As of right now - the rc3 does exact stop between rapids and cuts.
2: canned motion and such drilling and tapping run exact stop mode. (if that is your question)
3: they do.
Now on the other G64 questions.
Linuxcnc isn't mach. This is a 101 of what G64 doesn in linuxcnc world.
G64
Go as fast as you can but touch every line segment atleast once.
Px.xxx
Only deviate from the programmed path by x.xxx amount
Qx.xxx
This is what is called the naive cam detector. if lines fall within x.xxx - they are combined into one line. (with the new TP - a little Q goes a long way...) (rob has a good explaination at the end of his thread.)
Things to remember - P and Q are in the units the gcode running in (or whatever linuxcnc is set to) If you have G20 - it is in inches. If you program G21 it is in mm.
clear as mud?
It is late here - so if you want anything explained more - please ask. As far as what mach does - I have a test system setup here and am able to log what mach is outputting. I do see the constraint violations others and you have notice. Plus its path following imho is worse than the current TP as you increase velocity.
LinuxCNC Documentation Wiki: NewTrajectoryControl
is a good read (testing I have done while using the new TP.) compares some profiles between the old TP, new tp and mach.
sam
hi, thanks.Originally Posted by samco
I need to make a drawing of what emc is doing.
in mach, apart from the bug where it stalls, it follows the path precisely, EXCEPT at a corner. imagine a 6" square. it will follow the path correctly until it gets a set distance from the corner. then it will round it. it also has automatic corner detection, which I imagine the bug is.
in emc2, it does the same thing when you type ONLY g64. it just happens to have a vey large rounding tolerance so depending on the speed, you may get more rounded corners than mach.
but critically, the square is still a square. the sides are still perpendicular and parallel. in this mode, mach and emc are "the same" more or less.
when you had a P value, it breaks. completely. the square is no longer square, its skewed and twisted by the amount set in P. so unless you set P to a higher tolerance than your desired part - like 0.0005" you get an inaccurate result. and then of course, its so slow even on straight lines that its hardly worth it.
I should note the last version I had updated to was 2.43. perhaps this bad behavior has already been fixed.
so what im asking is really... is that "fixed"? if it is, ill be happy, haha.
I really don't know what you are seeing. that is not the behavior of G64 in linuxcnc unless the Q is set way too high.
here is a 1"x1" square. I am running it at 500ipm to show the blending. 6 boxes. G64, G64P.1, G64P.05, G64P.025, G64P.01, G64P.005
You can see the strait g64 with my config goes as fast as it can (pretty much makes a circle (you can see the exact stop at the beginging and end of G0...)
Now the Px.xx is how far the path can deviate. so take at look at the next one - P.1 - the distance between the corner and perpidicular to the blend is no more than .1" (and so on..)
Let me find a visual on how Q interacts..
sam
Here is a spiral made up of about .2" long line segemnt.
Now I set P to .001 show it follows the new Q path closely so you can see the effects.
They are Q0, Q.01, Q.02, Q.05 and then a non-sensical Q.5 to show how lines segments are combined..
You can use P and Q to fine tune your path.. The thing is - the path will never diviate more than worse case P+Q
sam
as far as lookahead - I have not had a slow down having linuxcnc set to 50. With mach (which defaulted to 20) I had to up it to 200 to get it to run the same profiles smooth. Also - I got to witness the feed hold delay. (which is still pretty instantaneous in linuxcnc) Rob also has a way to calculate what your lookahead should be (in the linuxcnc thread)
sam
Ok, oignore q for now...
Try your square again but make it not colinear with x and y.... So just a skewed box like shape.
Also try the emc logo gcode example.
Try the new and old to and compare if you can.
I'll try to screen grab my emc tonight.
Your first example looks perfect.... Not what I get.
Thanks for the help.
Lookahead will depend on the file and machine. At 300ipm, its unlikely to need more than 50-100. Mach default is 100 and it rarely bogs.
I've seen emc do it often, but not as much as you'd imagine having only one line. 1000 lines is more for things like lasers moving at 2000+ ipm I think.
Some screen shots would help troubleshoot. one thing that probably isn't documented very well is currently if you program G64P.005 with no Q - it assumes Q.005. So if you want no naive cam detector - you would program G64P.005Q0 (there have been arguments about this off and on) but you have the control to tell linuxcnc exactly what you want. (once you know the secret hand shake)
sam
Well that's some info... Should I set q to zero to turn it off? I can see this as a possible issue. I'll test that tonight.Some screen shots would help troubleshoot. one thing that probably isn't documented very well is currently if you program G64P.005 with no Q - it assumes Q.005. So if you want no naive cam detector - you would program G64P.005Q0 (there have been arguments about this off and on) but you have the control to tell linuxcnc exactly what you want. (once you know the secret hand shake
sam
yes - Q0 turns it off.
sam
I KEEEEEEL YOU!!!
how come when I was complaining 2 years ago no one (including you, sorry) thought to mention this. all I ever got was "well its better than mach" etc. not one person offered any settings to change. *grumble*
anyhow, it works as expected now... mostly. the corners don't really "round", the get short segments about 8-10 thou long. I imagine that's by design so it doesn't bog down. its not super slow now, cause I can set P to .005 or .01 and get a perfectly adequate result.
ill have to try the new TP soon, after I get my 48v psu and set the machine to run over 400ipm.
anyhow, thanks! I hate EMC2 a lot less now, haha. more importantly, I can USE it!
Well - that is what linuxcnc strives for 'less hate'
There are now a couple ways to get the new TP - the above build from source and now there are debs. I have to install the deb so I can get some instructions typed up..
sam
Re: New Trajectory Planner - Testers/programs wanted
This all sounds great. Any idea of when will it become part of the standard release?
Van
Re: New Trajectory Planner - Testers/programs wanted
from what I understand - it will go into master (development version) after the 2.6 release. This is the to-do list before the 2.6 release. (lots of things being worked on atm.) LinuxCNC Documentation Wiki: Todo-2.6
Here are the latest directions for running the new TP.
These are the basic steps..
You will want to get familiar with this
LinuxCNC Documentation Wiki: Installing LinuxCNC
The basic steps in terminal
^ that should launch the run in place version linuxcnc with the new TP...Code:git clone git://git.linuxcnc.org/git/linuxcnc.git linuxcnc-rc3 cd linuxcnc-rc3 git branch --track circular-blend-arc-rc3 origin/circular-blend-arc-rc3 git checkout circular-blend-arc-rc3 cd src ./autogen.sh ./configure --enable-run-in-place make sudo make setuid cd .. . ./scripts/rip-environment linuxcnc
It is basically the same as the wiki link except it is also pulling the patches from Robs branch.
You are almost done... There are some changes to the ini file
In the [TRAJ] section you need to add a few lines
ARC_BLEND_ENABLE = 1
ARC_BLEND_FALLBACK_ENABLE = 0
ARC_BLEND_OPTIMIZATION_DEPTH = 50
ARC_BLEND_GAP_CYCLES = 4
ARC_BLEND_RAMP_FREQ = 20
So - to run the RIP version
Open terminal
cd linuxcnc-rc3
. ./scripts/rip-environment
linuxcnc
There will be debs made soon and I will post the directions for that. (a little quicker/easier than building the above)
sam
Re: New Trajectory Planner - Testers/programs wanted
Here are some screen shots of some tochoidal paths. They are programmed at 3000mm/m (118ipm) With strait G64 (go as fast as you can but touch every segment) the current tp can only reach 760mm/m(30ipm) - if you say combine line segments that are within .1mm - it will peak at about twice that. (the plot is of velocity,x and y acceleration)
The new TP runs strait g64 at programmed feed. (last picture) plus nice sin/cos acceleration plots.
sam
Re: New Trajectory Planner - Testers/programs wanted
The new TP behavior is on by default in master. If you have no TPI'm pleased to announce that Robert Ellenberg's new trajectory planner
has been merged into LinuxCNC. It is in the master branch, aka 2.7~pre,
what will become 2.7 later when it's released. It will be part of build
v2.7.0-pre0-550-gd699a06 and later. The new TP is not in 2.5 or 2.6,
those will keep working the same way they always have.
Robert's new trajectory planner improves LinuxCNC's ability to keep
machining speed up, while not violating the programmed feed rate or
machine velocity or acceleration constraints from the ini configuration.
Your G-code programs should still make the same parts as before, but
they should now adhere to the programmed feed rate more closely, and
thus cut better and run to completion more rapidly. The old trajectory
planner would sometimes slow down more than it needed to, the new one
does a better job.
Many thanks to Robert Ellenberg for all the coding and debugging, and to
Sam Sokolik and others for relentless testing.
Brave users of the master branch! Please keep an eye on your machines
and let us know if they misbehave in any way. (And let us know if your
machines run better than before!)
-- Sebastian Kuzminsky
settings in your [TRAJ] section - linuxcnc defaults to.....
ARC_BLEND_ENABLE = 1
ARC_BLEND_FALLBACK_ENABLE = 0
ARC_BLEND_OPTIMIZATION_DEPTH = 50
ARC_BLEND_GAP_CYCLES = 4
ARC_BLEND_RAMP_FREQ = 100
