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

[307startup]

Do you use CAM to program, or G-Code by hand?

It would actually be more useful to run ellipses than circles, with the long end running along the cutline.

CAD was very helpful for this, as I could draw my overlapping circles and plot points for G-Code...I was in-effect the CAM software.

This is what Sansbury was talking about...I was just hoping to automate the strategy.

Once you get the hang of it, you can do this reasonably quick, but if you want to be really effective, subroutines and macros are the only way programming by hand in this scenario will work...unless you enjoy spending days slogging thru a program for a 15 minute part.

I save a copy of my CAD drawing under a modified name, so I know they belong to the same family, and this modified drawing becomes my template for my overlay strategy.

First I offset my edge (saving this as my finishing cut), then I populate inside this new area with my circles, curlicues or ellipses. At the points where they intersect, I cut the lines that are behind the direction of travel. This way all my points look something like this: )))))))) only with points on the arcs touching where they overlap.

This is montonous at best. This is why I was hoping to implement a nesting strategy and use the pocketing wizards to handle the code for the individual pockets, then assimiliate this into a bigger, all-inclusive program.

I have achieved some semblance of success, by saving my modified CAD drawing (with my finishing pass offset drawn as the area to be cut), downloaded my .dxf to a nesting software, saved this result as yet another .dxf drawing, reloading it into my CAD software, plotting these points and saving the data on Notepad, setting a new perimeter (to "trick" the nesting software into providing me with new data), saving this as a new .dxf drawing, importing it into the nesting software, save the result as yet another "sub" .dxf drawing, importing it back into CAD, plotting these new points, saving the data to Notepad...as many times as necessary to accumulate all the points I need, to write my G-Code via hand coding and subroutines. This is what prompted me to look at macros, as these are great with families of similar parts and can mostly be written using Excel for inputting the variables.

I didn't mean to offend anyone. I'm merely looking for a better way to do what I'm already doing, and I figured it would help the community as well (since I can't afford to commission the software only for my personal use) and am not a competent programmer in any of the modern languages. (I guess EIA/G-Code is a language, but it's alot easier than even Basic or COBOL)

[sansbury]

You might want to check out VoluMill's website, they have a free web-based version of their software you can upload a pocket profile to, and it will generate G-code using their high-performance strategies. I think it's meant mainly for evaluation, but it might be enough for some of your uses.

My other thought would be that you might just want to look at a good basic CAM package like Dolphin, BobCAD, even CamBam might be an improvement. This won't automate the whole process, but could maybe cut the time in half or less as what you're doing sounds like a *lot* of workarounds to get somewhere. My thought for how to do a pocket would be to manually pack the pocket with circular or elliptical pockets for roughing and then run a profile op (on the inside) for finishing.

[307startup]

You might want to check out VoluMill's website, they have a free web-based version of their software you can upload a pocket profile to, and it will generate G-code using their high-performance strategies. I think it's meant mainly for evaluation, but it might be enough for some of your uses.

I'm drooling over VoluMill web-NC...can't wait to try it! The ability to use their code whenever simply by registering for use?! Sure, you're tied to the internet, but if you can't afford the license fee that's not a setback!

My other thought would be that you might just want to look at a good basic CAM package like Dolphin, BobCAD, even CamBam might be an improvement. This won't automate the whole process, but could maybe cut the time in half or less as what you're doing sounds like a *lot* of workarounds to get somewhere. My thought for how to do a pocket would be to manually pack the pocket with circular or elliptical pockets for roughing and then run a profile op (on the inside) for finishing.

Yes, I agree with you on both points. I need to find a good, solid CAM package that is user-friendly, effective and reasonably priced. I know, I know...I don't want much, do I?

And yes, doing it the way I've been doing it is alot of work...exhausting actually. It works...but it's so time-intensive and littered with room for errors, and that just adds stress on top of tedium & monotony.

I think VoluMill web-NC will most definitely work for me, I'm playing with the demo right now

It would seem a shame though for the open-source/small-volume programmers to let this dialog go to waste...should we start a new topic about open-source/small-volume solutions to this? You seem to agree that this type of implementation would benefit home-users to maximize their machines effectiveness...

[ger21]

If you're drawing all those lines in CAD and getting the points, can't you just join them into a single polyline and create code from a .dxf of the polyline.

[307startup]

If you're drawing all those lines in CAD and getting the points, can't you just join them into a single polyline and create code from a .dxf of the polyline.

Sometimes yes, sometimes no. I haven't found a rhyme or reason to it really, but on some drawings with really "basic" toolpaths, the polyline produces really irregular code...and on other drawings with really erratic toolpaths, the polyline produces workable code.

I have only tried this a few times and was reluctant to try it for fear of breaking a tool or destroying material. (I run all my programs through a backplotter, so I can check for interferences and make sure my code executes properly)

I'm much more of a machinist, than I am a draftsman or even a programmer...my world at work is almost exclusively manual machining on really big machines.