Spiral toolpath to machine a cone?

[Voicecoil]

Anyone know of an easy way to generate a spiral toolpath to machine a smooth (upwards pointing) cone please? Trying to do it the obvious way (3D model > .stl file > CAM > G-code) isn't cool as the polygons in the .stl seem to result in lots of G01 instructions rather than cutting it in arcs/helical sections. If all else fails I'll have to write a spreadsheet to do it, but I fancy it could be a bit of a ball-ache.

[Kitwn]

Anyone know of an easy way to generate a spiral toolpath to machine a smooth (upwards pointing) cone please? Trying to do it the obvious way (3D model > .stl file > CAM > G-code) isn't cool as the polygons in the .stl seem to result in lots of G01 instructions rather than cutting it in arcs/helical sections. If all else fails I'll have to write a spreadsheet to do it, but I fancy it could be a bit of a ball-ache.

I'm afraid I cannot help with an answer to the question, but thanks for planting the idea that you can use a spreadsheet to calculate G-code moves of mathematical shapes. One of those little snippets of wisdom that might be the solution to a problem somewhere in the future. I hope someone else can be slightly more useful.

Kit

[Doddy]

I thought, "pah!, 'tis just your post-processor", and spent the last twenty minutes trying to pursuade Fusion with the UCCNC post to generate a cone - cannot persuade it to move away from G1's - thought there was a hope with the minimum-arc-length but nada.

I still think it's a post-processor issue, and I wouldn't use an stl export (the stl generates a point-mesh resulting in a tessellated object, so doesn't lend itself to arc processing)... but real life (work) interrupts what was otherwise an interesting problem :(

[Voicecoil]

Yes, I would agree that the .stl transfer is a problem, however that (and .3ds, another polygon based format) seems to be all that my CAM will accept. Are there any affordable CAM packages out there that will import an IGS or .step and that have a UCCNC post I wonder?

[Neale]

There's an element of "I wouldn't have started from there!" unfortunately.

As Doddy says, the STL model is built from a series of flat planes and the CAM will try to reproduce that. If the mesh is fine enough, it may be that CV mode in the motion controller will smooth these out, with a bit of tinkering with the motion controller parameters.

You cannot, mathematically, generate a spiral with G2/3 codes as the radius of the curve is changing continually. Best you can do is a series of close-spaced circles, gradually moving up the cone. That lets you use G2/3 commands. However, you do need a circular model with smooth curves to start with. Personally, I would use F360 for something like this but even then, it often generates many short G1 moves where you might expect curves - but the motion controller seems to smooth them out.

The free version of F360 will import .step, I believe.

[Voicecoil]

I realise it's not possible to do a true spiral, however it strikes me that an approximation done with a number of arcs per turn is going to be less lines of code and/or smoother than a series of straight lines.

[Neale]

My feeling is that G1 straight-line segment approximations will be fine but you need to start with a smooth curve model, not faceted as per STL, so the CAM process can sort out better approximations. Not sure why you seem a bit "anti" G1? I know it feels counter-intuitive but having done a fair bit now with F360 I find it often produces lots of g1s where you would expect curves, but the only downside seems to be file size. I've ended up with gcode files for quite small parts which have maybe 75K lines of code which are generated by the adaptive cutting strategies, but after my initial surprise, I now just shrug! In the days when machines read files from floppy disk, that would have been pushing the storage limits but these days, even a smallish memory stick holds 10000 times that so it just ain't a problem. As long as your motion control software/hardware can then do the constant-velocity stuff to smooth out the corners and with decent MC hardware this isn't rocket science.

Or just build your spreadsheet to generate one G2 per vertical step, and calculate away! I'm sure that that will work. But my IT background says that if a machine can do the work for me, then I'm not going to spend brain cycles doing it by hand...

Good luck either way.

[Kitwn]

Or just build your spreadsheet to generate one G2 per vertical step, and calculate away! I'm sure that that will work. But my IT background says that if a machine can do the work for me, then I'm not going to spend brain cycles doing it by hand...

Good luck either way.

I was pondering along these lines as well, a good excuse to swot up on exactly how G2 and G3 instructions work and whether Excel will export files delimited with cariage returns. The arc centres are all the same and the end points progress outward in symetrical straight lines so it should not be too dificult. If the angles match then using a V-bit will help smooth the edges but that would only be possible for very short cones with most V-bits.

You're not going into competition with OMLCNC are you? http://www.mycncuk.com/threads/14408...632#post123632

Kit

[Voicecoil]

You're not going into competition with OMLCNC are you? http://www.mycncuk.com/threads/14408...632#post123632

No :-) my cones are only going to be 2...3cm tall and made of 7075 ali

Kit

[Voicecoil]

I was pondering along these lines as well, a good excuse to swot up on exactly how G2 and G3 instructions work and whether Excel will export files delimited with cariage returns. The arc centres are all the same and the end points progress outward in symetrical straight lines so it should not be too dificult. If the angles match then using a V-bit will help smooth the edges but that would only be possible for very short cones with most V-bits.

Kit

Did a bit more thinking about this and to get a smooth toolpath the arc centres aren't the same, you need to offset them ever so slightly to get the arc ends to join up and get the best approximation - as Neale pointed out, on a true spiral the radius is continually increasing, hence if you divide the circumference into a small-ish number of sections with the same centre there would be a slight bump in-between sections. In the end for prototyping I took the crude but simple approach, slicing the model to create a number of 2D toolpaths which I outputted together. Wasn't as much work as I thought thanks to the speediness of Generic CADD (actually took less time than I'd spent playing around with the maths of an elegant solution!), and has ended up greatly reducing the machining time as I've been able to include the flutes which I was going to cut into the cone as a separate operation. The 303 stainless cuts nicely on my little machine using blue-nano coated cutters, only running at 800mm/min at the mo but from the noise it feels like it could go a fair bit faster - but I'll leave pushing the limits until the development work is done!