Chip thinning strategies, trochoidal toolpaths, high-speed machining using Mach 3?

[307startup]

Has anyone implemented the use of chip-thinning strategies, trochoidal milling or high-speed machining on a Tormach or similar sized machine?

Is there a wizard or add-on component for Mach 3 that will allow this?

Are there any affordable software packages available if this is not a capacity via Mach 3?

It seems to me that this is a viable option that should be looked into with interest on lower-horspower, less-rigid spindle machines to increase the capability of a Tormach or similar sized mill.

[TOTALLYRC]

Not that I know of but I will watch with interest.

Mike

[307startup]

It would be most beneficial on pocketing or 3D machining with areas of greatly differing heights.

I realize chain drilling can also be used to minimize the amount of material being milled, but this can only be used to great effect on big pockets.

It seems to me that someone skilled in programming could link this with wizards used for making circular and rectangular pocketing...once a pocket or other feature has been defined, the trochoidal tool path would have a finite area to calculate for machining purposes.

[BlueFin]

Trochoidal machining looks cool, I want to try it. But I am also worried about the amount of Gcode movements that the machine must do in order to get a part done. If you pocket a part with this method the table will have moved a LOT compared to the regular machining method, seems like you could get a missed step in there with all those steps taking place.

[rowbare]

Those cutting strategies would come from your CAM program. Mach should be able to interpret them.

bob

[307startup]

I would prefer to have something like a wizard, not a separate CAM software, unless it's non-doable as an add-on. It's not really a needed activity on 90% of 3D machining, but very helpful in certain scenarios.

[TOTALLYRC]

Originally Posted by BlueFin Trochoidal machining looks cool, I want to try it. But I am also worried about the amount of Gcode movements that the machine must do in order to get a part done. If you pocket a part with this method the table will have moved a LOT compared to the regular machining method, seems like you could get a missed step in there with all those steps taking place.

Properly tuned your machine should never miss steps. If you miss steps then you are either trying to go too fast or your power for the axis is too low.

[Freddy Bastard]

Chip thinning... I use it everydays.

I've done a little video on youtube: YouTube - dynamic mill_03.mpg
Programmed with Mastercam... but... it's a expensive soft.

It't a real charm for the Tormach.

[307startup]

Ok, here's my thoughts on the subject (granted I'm not a programmer or maths-whiz)...

To implement a Mach 3 chip-thinning wizard (rather than using a CAM-based system) should be relatively easy...I say this with calculated thought.

Here's why...pocketing using circular interpolation is basically macro-ized chip thinning.

What's needed to implement this fully is a fairly simple algorithm that breaks down a pocket based on it's dimensions and tool-size (w/offsets) into a multitude of mini-pockets for constant circular interpolation.

It would require a table of calculated step-overs for a range of tool sizes, concentrating on the body of the pocket, leaving the previously defined periphery and pocket depth for a final pass.

Basically what is needed is already available in two separate camps...CAM and Wizards.

So...here is just MY suggestion on the building blocks for making a chip-thinning wizard (rough pocketing, boundary milling, profile milling)...

USE the logic from a nesting software to determine the mini-pockets in a user defined space as is done in a hole milling wizard...

USE a table of calculated step-overs for a range of tool-sizes to maximize an effective chip-thinning strategy based on the tool chosen...

USE a table of calculated feeds & speeds based on the tool chosen...

USE a ramping strategy to maintain proper tool loads based on user defined geometry of the feature being machined...

Bundled together, this should be a very effective pseudo-trochoidal tool-path wizard.

What do you think? Feedback and inputs for anything I might have overlooked are welcome. I want this to be a problem-solving exercise, not a brush-off to stick to expensive (mid-range) software, but rather a community-based solution for DIY'ers, Home Shop Machinists, Benchtop CNC'ers and small-scale commercial CNC'ers (like Tormach users, Novakon, Syil, etc).

If you're a programmer, or know a programmer who might be interested in playing with this, poke your head in and let us know

[sansbury]

The challenge with any wizard that does more than trivial geometry (e.g. circular and rectangular pockets and profiles) is properly calculating offsets to define the toolpath. There are a variety of ways to get at this, but all of them involve a lot of fairly serious math, which is why open-source CAM is still very much in its infancy.

There are a lot of simpler/better-known ways to do this that *almost* work, or work in 99% of cases, but where you can cut a few corners with collision detection in games, in our case the corner you cut may be the jaw of your vise

I have a friend who is working on an open-source programming library for what are known as Voronoi diagrams, which are sort of the gold standard for computing offsets to geometry, among other uses. If and when he finishes that, it will make it a lot easier for a guy like me, who understands machining and programming moderately well, but barely passed second-year calculus in college, to do the sorts of things being talked about here. While my own interests are more on the side of integrating more functionality into EMC2, the open-source nature means that the code will be there for the Mach community to learn from as well.

[307startup]

Originally Posted by sansbury The challenge with any wizard that does more than trivial geometry (e.g. circular and rectangular pockets and profiles) is properly calculating offsets to define the toolpath. There are a variety of ways to get at this, but all of them involve a lot of fairly serious math, which is why open-source CAM is still very much in its infancy. This would be easy to accomplish using a macro...calculating offsets to define the toolpath is a function of the step-over rates for a given range of tooling, using the feed&speed rates tied to that same range of tooling...they are tied together, by virtue of being related functions. For example, if pocketing a 3"x3" square with 1/2" radius corners using a 3/8" endmill, the offsets for defining the tool-path are based off how many circular pockets smaller than 1/2" but larger than 3/8" can populate that region, minus the difference between them for the finish root & periphery path...in other words, a nominal 7/16" circle to allow for 1/16" for a finish pass, or better yet a 15/32" circle to allow for 1/32" for a finish pass, or even better yet a 31/64" circle to allow for 1/64" for a finish pass. The step-over rates assume continuously cutting this circular pattern within the boundaries established by the user regarding finish pass. The toolpath assumes that the circular interpolation is infinite within the pocket until approaching a user defined boundary, and thus must continue cutting on a path open to it, that hasn't been previously cut. There are a lot of simpler/better-known ways to do this that *almost* work, or work in 99% of cases, but where you can cut a few corners with collision detection in games, in our case the corner you cut may be the jaw of your vise There shouldn't be any collisions using a strategy that I outlined, because it can only function inside of a user-defined space. If the user doesn't define an obstacle, that is no fault of the software. I have a friend who is working on an open-source programming library for what are known as Voronoi diagrams, which are sort of the gold standard for computing offsets to geometry, among other uses. If and when he finishes that, it will make it a lot easier for a guy like me, who understands machining and programming moderately well, but barely passed second-year calculus in college, to do the sorts of things being talked about here. While my own interests are more on the side of integrating more functionality into EMC2, the open-source nature means that the code will be there for the Mach community to learn from as well.

Now this sounds VERY intriguing...and of course benefits the community as a whole. I like it!

[307startup]

The user-defined features of the machining space provide the boundaries, the user-defined info regarding finish allowances provide sub-boundaries, anything inside of these defined spaces the software would view as overlapping circles based on the difference between tool-size, existing feature radii, operating radii (the effective size of overlapping circles remaining inside the sub-boundaries, determined via difference between existing radii, tool radius minus finish allowance) and optimal chip-load determined by a tool-size based chart and speed&feed chart for that tool range.

Make sense? Seems this is very doable. Too bad I'm not a programmer...