linux compared to centroid and acromill

Things are never as simple as they initially appear. The same is true for old vs new TP. By properly setting up path following tolerance and naive cam detector it is possible to minimize the difference between the two, and in the end you cannot beat physics; there is a hard limit on how fast a machine can change directions and speed. But so far I have yet to encounter a real-life situation with a lot of CAM-generated short-segment code where the new TP is no improvement over the old one given an equal and realistic path following tolerance. For us hobbyists and router guys who are 'stuck' with highspeed spindles and therefore the need for a constant and high feedrate the new TP is a blessing.

That said: I would get things up and running with a stable release too. I suppose it won't take years before they integrate the improved TP in the stable release, and even if they don't a development release can coexist happily with the regular stable release.

It all boils down to choices.
Pick the type of machine, travel range, spindle speeds and cost of components that are the best compromise for what you intend to do. Then create workarounds or different approaches for the jobs that do not fit too well in the chosen compromises. Your mill performs excellent when facing a block of steel but takes ages to mill a PCB, mine is the reverse. But both machines can do both tasks.

On the current mill I use a 24000rpm Chinese watercooled spindle that replaced the 2500rpm original. Buy carefully and you get a lot of value for the money, and the higher RPM's are well suited to milling softer materials with relatively cheap small sized (<12mm) endmills. Does that rule out the milling of for example stainless steel? No, just pick a different approach. Low angular engagement of the endmill combined with coated carbide pushes the surface speed back into the range of the high speed spindle.

But then you *must* be sure that you can keep up the high feedrate, and because of the high surface speed of the endmill the feedrate must be high. Work hardening is an ugly thing and with high surface speeds you must be sure that heat ends up in the chips.
Same with wood and to a lesser extent plastics: slowdowns cause burnt spots on the edges.

Traditionally LinuxCNC was/is very well suited to control mills such as the beast you mentioned. Brute force, fairly slow axis speed and spindle speeds, relatively simple toolpaths.
For controlling light and highspeed machines such as the average wood/plastic router or 3D printer LinuxCNC used to be less suitable up to the point where swapping it for a different control makes more sense (remember my gantry homing issues, for example?).

But luckily, things are improving rapidly.

Well, I'm going to order the mesa cards next week. I want to thank everyone for the input. Any suggestions on a new pc are welcome. A few pics of the machine are attached. I'd like to make it a 5-axis at some point with a rotary axis at the router and a "double-x" axis that allows me to machine parts that are longer Maybe 16 feet we'll see. Thanks alot.

Interesting. I was thinking of a long high speed xtra x-axis table added to the existing bed since i have plenty of z-height. Then i could use the existing gantry basically as a moveable x-axis.........it would be able to change x-axis zero positions to get the extra length but it would stay still during machining. I would just have to set up two(multiple) cad files with different xzero positions...........am i making sense?

cm

Why not make a configuration that moves both the extra table and the gantry in proportion? Say you want to move the X 10mm. Then you could move the additional table 5mm and the gantry 5mm in the opposite direction.

Or even purely mechanical:

that sounds really cool but i would have no idea how to do that. can you have two axes responding to the gx moves in the code? seems like there would have to be some kind of algorithm in the control that spit up the gx moves into two channels while the program is running..........sounds way over my head.

In the end the LinuxCNC software package is just a bunch of Lego blocks that you can stick together anyway you like.

Normally you stick the 'stepgen' blocks directly onto the 'motion' block, but nobody prevents you from placing a few Lego blocks between the 'motion' block and 'stepgen' blocks that take the X coordinate, divide it in two, send the first half to the gantry 'stepgen', invert the second half, and send the inverted second half to the extra table 'stepgen'. That is the real beauty of LinuxCNC; you can make it work the way you want.

Of course it is not quite as simple as just splitting the coordinates in half; a few side issues need resolving if you decide to go this route. But don't let that scare you; things are never as simple as they initially appear. That was already true when you learnt to lace your shoes when you were a kid.

If you never ran LinuxCNC then of course this is above your head. Get it running first, get a bit comfortable with the system, build the table, and then implement this. Plenty of helpful folks over here.