New Trajectory Planner - Testers/programs wanted

Awesome!

Thanks Rob

rellenberg wrote:

Nice work! I have a fix in the works for this. The code that checks for the maximum axis accelerations didn't properly handle the case of having fewer than 3 axes. It seems to be a simple enough fix on the TP side, though I still have to look canon. I'll have it pushed to a test branch off of 2.7 in another day or two.

Hi guys,

Thanks for everyones' help with getting my 3-axis router running. I've milled a couple small .jpg files so far but haven't had much time to play too much. However, I have a 300 sheet order of different shapes cut from plywood coming and 3d molds for a concept car body after that. So I'm going to be doing a hell of alot machining in the months coming up. I'm hoping during this period you guys can help me get this machine screaming fast. It looks like the new trajectory planner is the way to go. Just looking for some input. Using 2.6.5 on 10.04 now. I've read a little on this thread and it looks like the tp I have now is good for only 100 ipm....is this still the case? I'll definitely need more speed than that for all this work. I think this is a good machine to test if you guys agree. thanks.

Ok I'll experiment with the accelerations tomorrow & see what happens. I wrote a couple of spiral programs that are point to point with a curve tolerance of .001". One of them is a regular 2d spiral and the other moves down in the z direction as it spirals out. Though this might be useful after reading through the thread. They are attached.

When I download the new 2.7 version with the updated tp will I be able to easily go back and use my current 2.6.5?

If you change the 2.7 back to 2.6 and run an update, you will receive 2.6 again.

The option I use is to run the regular LinuxCNC as 'installed' and the master (latest bleeding edge code) as 'Run In Place' build, compiled from sources. This allows a seamless switch between multiple versions of LinuxCNC.

But in reality all I use 2.6 for is to verify that strange behaviour is indeed a stupid user error instead of a bug. So far I have no stability or other problems running the development releases so I doubt you want to go back to 2.6 once you have 2.7 installed.

And yes, the new TP is a HUGE step forward. I am amost exclusively using curvy HSM-toolpaths, and with the new TP it is absolutely no problems to push 100Kbytes of awful CAM-generated short-segment G-code through the interpreter/motion controller in 5 minutes of milling.

Ok, that sounds good. I have no idea how to set up 2.7 as 'run in place'. Will the info. earlier in this thread get me there? If not could you point me in the right direction? I hate to be so needy here but my time is limited right now and if I can get it running at 100ipm that will do for a little while. I'll get back to the 2.7 issue tonight though. Thanks for the help.

I would do as Andy said and use the buildbot first: a lot less hassle if you are tight on time and I doubt you need to go back to 2.6. It won't be long before they release 2.7 officially anyway.

Thus:
- Open a terminal window
- Do a 'sudo apt-key adv --keyserver hkp://keys.gnupg.net --recv-key E0EE663E' in that terminal window
- Do a 'sudo gedit /etc/apt/sources.list.d/linuxcnc-buildbot.list' and change a reference to 2.6 which is already there to 2.7. If there is none, add these two lines at the end of the file:

deb buildbot.linuxcnc.org/ lucid 2.7-rt
deb-src buildbot.linuxcnc.org/ lucid 2.7-rt

- Then save and exit gedit.
- Still in the terminal window do 'sudo apt-get update'
- Do a 'sudo apt-get install linuxcnc'
- Done.

The quotes (') above are not part of the commands and just there to separate the command from the rest of the text. Type/copy the commands without these quotes.

If you want to revert back to 2.6 do the same, but change 2.7 to 2.6 when editing the linuxcnc-buildbot.list file.


Now, I think the new TP uses reasonable defaults, but in case you might want to play: I have this configuration in my INI file:

..
..
[TRAJ]
AXES = 4
COORDINATES = X Y Z A
..
..
ARC_BLEND_ENABLE = 1
ARC_BLEND_FALLBACK_ENABLE = 0
ARC_BLEND_OPTIMIZATION_DEPTH = 480
ARC_BLEND_GAP_CYCLES = 4
ARC_BLEND_RAMP_FREQ = 200
..
..

Both the optimization depth and ramp freq are a lot higher than default, but as I said: I am mostly running curvy toolpaths, I have fairly speedy axes (18 meters/minute) with high acceleration (2500-5000mm/s^2), a high servo thread rate (8kHz) and I need to keep the cutter cutting so heat goes into the chips and not into the endmill/workpiece when doing HSM-style toolpaths.

I had forgotten to update this. Rob has fixed this issue (x-y only machines violating constraints) and a few others. It will be in the next 2.7 pre-release. (maybe this weekend)

or you can pull the branch - it is on git.linuxcnc.org

feature/spiral-arc-handling-2.7

sam

Hello,

i have a few mistakes with milling circles. My cam (CamBam) divides full circles into segments, so an circle consists of 3-4 Arcs.
Now with LinuxCNC 2.7, i have the problem that the machine everytime at the end of the first segment slows down.
But the following Circle Segments would be driven right, all together without slow down.

I have tested this with G64 and P from 2 to 0.05, its all the same.

this is the gcode:
If you delete the line "G1 F300.0 Z-3.0" , all segments would be driven as one circle without slow down.

Any suggests?

Regards DB

I am seeing the behavior here. It seems to exact stop between the first 2 arc. (and removing the Z move fixes makes it not stop)

I will ping rob and see if he has some time to look at it.

sam