584,833 active members*
5,542 visitors online*
Register for free
Login
IndustryArena Forum > Machine Controllers Software and Solutions > Mach Software (ArtSoft software) > Mach Wizards, Macros, & Addons > Chip thinning strategies, trochoidal toolpaths, high-speed machining using Mach 3?
Page 1 of 2 12
Results 1 to 20 of 29
  1. #1
    Join Date
    Oct 2006
    Posts
    669

    Chip thinning strategies, trochoidal milling, high-speed machining on the Tormach...

    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.

  2. #2
    Join Date
    Dec 2004
    Posts
    1865
    Not that I know of but I will watch with interest.

    Mike
    Warning: DIY CNC may cause extreme hair loss due to you pulling your hair out.

  3. #3
    Join Date
    Oct 2006
    Posts
    669
    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.

  4. #4
    Join Date
    Feb 2006
    Posts
    251
    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.
    BlueFin CNC LLC
    Southern Oregon

  5. #5
    Join Date
    Jul 2007
    Posts
    1602
    Those cutting strategies would come from your CAM program. Mach should be able to interpret them.

    bob

  6. #6
    Join Date
    Oct 2006
    Posts
    669
    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.

  7. #7
    Join Date
    Dec 2004
    Posts
    1865
    Quote Originally Posted by BlueFin View Post
    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.
    Warning: DIY CNC may cause extreme hair loss due to you pulling your hair out.

  8. #8
    Join Date
    Jun 2007
    Posts
    168
    Chip thinning... I use it everydays.

    I've done a little video on youtube: [nomedia="http://www.youtube.com/watch?v=nn6SyX0b9Co"]YouTube - dynamic mill_03.mpg[/nomedia]

    Programmed with Mastercam... but... it's a expensive soft.

    It't a real charm for the Tormach.

  9. #9
    Join Date
    Oct 2006
    Posts
    669
    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

  10. #10
    Join Date
    May 2007
    Posts
    1026
    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.

  11. #11
    Join Date
    Oct 2006
    Posts
    669
    Quote Originally Posted by sansbury View Post
    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!

  12. #12
    Join Date
    Oct 2006
    Posts
    669
    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...

  13. #13
    Join Date
    May 2007
    Posts
    1026
    I'm not sure we're saying the same thing when we use the term "offsets." What I mean are literally the toolpaths output by your CAM software. These are calculated by drawing offsets of the part geometry. The process of doing this is really easy for a square pocket, or almost any polygonal pocket with no islands.

    Now, imagine you've got a pocket like the pentagonal one (red is being removed) here. This starts to get trickier, but you can still kind of get away with taking a ruler and drawing offsets. Now, stick a couple of irregularly-shaped islands in an irregularly-shaped pocket, and it gets real nasty. It's easy to offset any one of them, but then you have to check if the offset collides with other pieces of geometry. You end up with algorithms that either fail under certain (not obviously) tricky circumstances (meaning they either run the tool into the part or fail to clear areas that they should), or they can take long to compute and/or produce inefficient toolpaths.

    If I understand correctly, your idea is to basically start with G-code, and post-process it to extract features which can be milled more efficiently. For instance, a rectangular area that's getting cleared might be turned into a one or more circular areas which can be cleared with a helical or circular toolpath. Circular toolpaths are in many ways optimal as they allow you to get the maximum usable cutter engagement and keep it there through the whole cut. So you could hog out all the big open spaces and then use slower toolpaths just to make one or two finish passes to clear out the corners.

    Anyway, here's the thing: if you think of the G-code as just another way of drawing geometry, then you can see how the problem of drawing toolpaths based on G-code isn't really any different from drawing toolpaths based on geometry in a DXF. And you're going to have to trust me that this becomes non-trivial pretty quickly. The more you want to apply complex toolpath strategies, the more quickly this hits you.

    Where I do agree with you 100% is that there is definitely a lot of value for these kinds of machining strategies for those of us running toy machines at home. That's where I think things like this Voronoi library are important--it provides a foundation for doing things like what we're talking about. I'm not trying to be discouraging, but just trying to explain, from a programmer's point of view, why this is not a particularly simple problem to solve.
    Attached Thumbnails Attached Thumbnails pocket.png  

  14. #14
    Join Date
    Dec 2004
    Posts
    1865
    How about we start small with the ability to do straight lines.

    I would use this for milling slots that are near the diameter of the endmill or to cut a piece of material in 1/2 using an endmill.

    Case in point. I want to cut a 1"thick piece of 410 stainless into smaller parts. It is way to big for my band saw.
    I would like to cut using a trochoidal tool path with a .500 insert mill and make the slot .625" or possibly .550" to save material.
    I would put the length and width of the slot into the wizard DROs and it would spit out usable G-code.

    Mike
    Warning: DIY CNC may cause extreme hair loss due to you pulling your hair out.

  15. #15
    Join Date
    Mar 2003
    Posts
    35538
    This would be easy to accomplish using a macro...
    If it was, somebody would have done it. As Sanbury said, it gets complicated real fast.

    I'm not a real programmer, but I wrote an AutoCAD macro that I use to create almost all of my 2.5D toolpaths. I probably spent over 200 hours working on it. It doesn't do pockets, because those would be more complicated than everything else combined. Sure, round or rectangular are easy, but anything else is waaaaay harder.
    Gerry

    UCCNC 2017 Screenset
    http://www.thecncwoodworker.com/2017.html

    Mach3 2010 Screenset
    http://www.thecncwoodworker.com/2010.html

    JointCAM - CNC Dovetails & Box Joints
    http://www.g-forcecnc.com/jointcam.html

    (Note: The opinions expressed in this post are my own and are not necessarily those of CNCzone and its management)

  16. #16
    Join Date
    Oct 2006
    Posts
    669
    Sansbury,

    I do understand where you're coming from and I appreciate you taking the time to explain it to me.

    What I don't understand is why it must be so incredibly complex to program, when it's a calculus function using variables...my scientific calculator can spit out the answer as soon as I press =

    In macro format it's almost exclusively either/or, include/exclude, inverse function, rationating, or derivative function...

    Yes, granted there are some missing algorithms, and I am definitely not the man to formulate them, but I do know some rather clever fellows who solve mathematical puzzles for fun.

    It seems to me that there are some "open-source" algorithms from hackerspace or the spam world that would fit in nicely...after all, some of those are rather elegant programs that accomplish much with very little effort, often with little to no real aptitude by the end-user.

    I do plan on doing some research in regards to the Voronoi library. Is there any way to contribute?

  17. #17
    Join Date
    Oct 2006
    Posts
    669
    Quote Originally Posted by ger21 View Post
    If it was, somebody would have done it. As Sanbury said, it gets complicated real fast.

    I'm not a real programmer, but I wrote an AutoCAD macro that I use to create almost all of my 2.5D toolpaths. I probably spent over 200 hours working on it. It doesn't do pockets, because those would be more complicated than everything else combined. Sure, round or rectangular are easy, but anything else is waaaaay harder.
    Not trying to argue with you.

    But it seems the simplest solution to those problems of geometry would be solved via the nesting implementation of multiple circular pockets inside the defined area. Where a circular pocket determined by the variables supplied by a user will fit, it can be cut. Where it can't, it will be ignored.

    This is a problem to be solved. Obviously I need programmers to accomplish it, but using the same thinking that hasn't been able to achieve this solution isn't going to find the solution either. That's why I suggest looking at the problem not as a programmer, but as a mathematician.

    We are talking about the implementation of arcs, tangents, and sines inside a user defined area. I have done this by hand on several different drawings. If I can write the problems and the solutions long hand, there has got to be a way that some programmer can do it quicker and more elegantly.

    As you said, you aren't telling me it can't be done, just that it hasn't been accomplished yet. Which defines the real problem...how it has currently been attempted. The problem isn't if it can be done, but how.

    Instead of programmers responding sullenly out of wounded ego, why don't they respond proudly from a proven ego?

  18. #18
    Join Date
    Oct 2006
    Posts
    669
    Quote Originally Posted by TOTALLYRC View Post
    How about we start small with the ability to do straight lines.

    I would use this for milling slots that are near the diameter of the endmill or to cut a piece of material in 1/2 using an endmill.

    Case in point. I want to cut a 1"thick piece of 410 stainless into smaller parts. It is way to big for my band saw.
    I would like to cut using a trochoidal tool path with a .500 insert mill and make the slot .625" or possibly .550" to save material.
    I would put the length and width of the slot into the wizard DROs and it would spit out usable G-code.

    Mike
    You can accomplish this already using a few tools already at your disposal, but it's going to be an enormous file unless you use subroutines or write a macro to do the "heavy lifting".

    The width of your path will be determind by the OD of your tool plus the offset needed to implement a circular interpolation (most controllers require a certain amount of lead-in for engagement to work properly, this is generally a percentage of the tool OD)...your controller might work with as little as .025" lead-in, or need as much as .100"...this plus your tool OD will determine the actual width of the slot.

    After that, it's merely tricking your controller into seeing the "line" as a bunch of overlapping/advancing arcs, that your tool will be ramping into and away from, at an appropriate chip-load, speed & feed. This is where your subroutines or macro comes in, because at each call-up you don't want your machine to stop, but merely to continue into the next cut. Your code has to execute repeatedly as many times as it takes to complete the length of cut...it could be 100 call-ups, it could be 1000 call-ups.

    It's, for lack of a more elegant name, linear corkscrew milling. Kinda like having a tornado on a leash

  19. #19
    Join Date
    May 2007
    Posts
    1026
    Quote Originally Posted by 307startup View Post
    Instead of programmers responding sullenly out of wounded ego, why don't they respond proudly from a proven ego?
    There's only one ego in this room and I think it's yours.

    You've stated that you're not a programmer, and you didn't even stay in a Holiday Inn Express last night. Ger21 actually wrote his own CAM library, and I've studied this problem at length, and have been in the software industry as a developer and product manager since 1999. If clients want to throw spitballs at me, that's fine, they're paying for the privilege, but if you want help from the community, I suggest you avoid psychoanalysis.

    Not being a programmer, I think you are underestimating the difficulty of implementing a robust algorithm. It may be that your own needs are limited and the examples you've worked on paper are what I've referred to as trivial. Or, it may be that as you've worked your problems, you've failed to notice when you solved a problem by using a bit of human judgment that's very hard to implement in software. Either way, if the solution is really so much closer to the surface as you think it is, then post some of your sketches here and walk us through them. You may in fact have a great idea, but we need to see a little more.

  20. #20
    Join Date
    May 2007
    Posts
    1026
    In the interest of keeping this on topic, and illustrating what I mean by robustness, here is a part that will break most naive attempts to cut it. If you print this out and try to work it on paper I think it will help you see how things that aren't too exotic can become quite challenging.
    Attached Thumbnails Attached Thumbnails torture_test.png  

Page 1 of 2 12

Similar Threads

  1. High speed toolpaths
    By camtd in forum Mastercam
    Replies: 19
    Last Post: 01-06-2012, 07:06 PM
  2. Replies: 1
    Last Post: 11-11-2010, 11:21 PM
  3. NEW: TFM - Mastercam Surfacing High Speed Toolpaths Training CD
    By Mike Mattera in forum News Announcements
    Replies: 0
    Last Post: 07-14-2010, 05:30 PM
  4. Replies: 0
    Last Post: 07-14-2010, 05:28 PM
  5. High Speed toolpaths
    By Ford25 in forum Mastercam
    Replies: 12
    Last Post: 09-13-2009, 12:02 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •