Hi Art,
I understand that bevel gears are meant to be cut with 4-axis machines. Is it possible to cut a simple bevel with a 3-axis machine - either as a raster or an offset.
This may be a totally dumb idea but I thought I'd ask.
John
Bevel Gear
Bevel Gear
1% inspiration 99% try, try again
Re: Bevel Gear
John:
At the moment no. But I have had discussions in the last week with John S. that perhaps having
a pocketing type of build or engraving type of build in 3 axis would be preferable to 4th. No-one really
uses the 4th axis bevel code, its just too complex to set it all up. I am considering adding a 3axis option
but I know from initial calculations that it will take a long time to cut such a thing. Tolerances being what they
are its just not easy to cut a bevel. Of course, even a gear builder woudl tell you bevels are a tough thing
to build for anyone using any technology. ( Except perhaps 3d printing ).
I cant promise youll see such a thing till next season, but I suspect bevel's in 3 axis will become
possible as output. I think the option needs to be explored at any rate.
Thx
Art
At the moment no. But I have had discussions in the last week with John S. that perhaps having
a pocketing type of build or engraving type of build in 3 axis would be preferable to 4th. No-one really
uses the 4th axis bevel code, its just too complex to set it all up. I am considering adding a 3axis option
but I know from initial calculations that it will take a long time to cut such a thing. Tolerances being what they
are its just not easy to cut a bevel. Of course, even a gear builder woudl tell you bevels are a tough thing
to build for anyone using any technology. ( Except perhaps 3d printing ).
I cant promise youll see such a thing till next season, but I suspect bevel's in 3 axis will become
possible as output. I think the option needs to be explored at any rate.
Thx
Art
Re: Bevel Gear
I'm a crazy one, using loops, conditionals, and embedded math in my g-code, but I've generated bevel gears with five axis movements with gcode programs half a page long. I had to mount a rotary table on a rotary table on an XY table to do it. The dance of the machine and the quality of the gears is something to behold. Crazy exercise, but not remotely practical for general consumption.
I was thinking about three axis bevel gear cutting for sane people ...
Bevel gears are spherical in nature, and I was wondering if it would be possible to generate tool paths that reflected this. If the tool path traced the gear form such that the tool's distance from the sphere's center was constant, and if you could tell the machine to apply the tool comp perpendicular to the tool path and perpendicular to the sphere's/tool position's radius, subsequent tool paths would be identical, except they would be scaled. The nice thing is that this would make fairly smooth running gears, even with relatively few passes of a ball mill.
Was that understandable?
I was thinking about three axis bevel gear cutting for sane people ...
Bevel gears are spherical in nature, and I was wondering if it would be possible to generate tool paths that reflected this. If the tool path traced the gear form such that the tool's distance from the sphere's center was constant, and if you could tell the machine to apply the tool comp perpendicular to the tool path and perpendicular to the sphere's/tool position's radius, subsequent tool paths would be identical, except they would be scaled. The nice thing is that this would make fairly smooth running gears, even with relatively few passes of a ball mill.
Was that understandable?
Re: Bevel Gear
Justin:
Hmm, if I understand it, its basically what the 4th axis code is designed to do. I have two
flavours, one that uses a taped bit and one that uses a endmill. They each do a shaving based on the
beveled angles..but even then its hiddeously complicated..really as you say just not good for general
consumption.
On the other hand, if you mean to do basically a pocketing of each tooth based on its spherical projection
and dropping by a set amount of Z on each pocket with tool comp..then I think that might work for general
consumption..something Ive been kicking around.. It woudl allow it to be cut flat..but even then requires a very
low stepdown to elliinate the jaggies..
Art
Hmm, if I understand it, its basically what the 4th axis code is designed to do. I have two
flavours, one that uses a taped bit and one that uses a endmill. They each do a shaving based on the
beveled angles..but even then its hiddeously complicated..really as you say just not good for general
consumption.
On the other hand, if you mean to do basically a pocketing of each tooth based on its spherical projection
and dropping by a set amount of Z on each pocket with tool comp..then I think that might work for general
consumption..something Ive been kicking around.. It woudl allow it to be cut flat..but even then requires a very
low stepdown to elliinate the jaggies..
Art
Re: Bevel Gear
Art, no.
I'm picturing the bevel gear laying flat on the XY table, with the tool following a path that is entirely on one spherical surface, let's say a spherical surface at the toes of the teeth. This sphere would have its center at the apex of the bevel gear of course. Then on subsequent paths, that tool path would be projected out on the next spherical surface, and so on, until the path is out on the heels of the teeth. The path would look like a circle if seen from the far end of the room. Each interpolation would be three axis.
This would be in no way a "generation" process -- just interpolations between calculated points.
How do you tell the machine which direction to apply the tool comp in? In two dimensions it is perpendicular to the path, but in three dimensions you have to tell it what the surface normal is....
I'm picturing the bevel gear laying flat on the XY table, with the tool following a path that is entirely on one spherical surface, let's say a spherical surface at the toes of the teeth. This sphere would have its center at the apex of the bevel gear of course. Then on subsequent paths, that tool path would be projected out on the next spherical surface, and so on, until the path is out on the heels of the teeth. The path would look like a circle if seen from the far end of the room. Each interpolation would be three axis.
This would be in no way a "generation" process -- just interpolations between calculated points.
How do you tell the machine which direction to apply the tool comp in? In two dimensions it is perpendicular to the path, but in three dimensions you have to tell it what the surface normal is....
Re: Bevel Gear
Art,
The advantage is that the tool path will follow the rolling motion of the gear, instead of crossing it, which will make gear action smoother with fewer passes.
The advantage is that the tool path will follow the rolling motion of the gear, instead of crossing it, which will make gear action smoother with fewer passes.
Re: Bevel Gear
Ahh, I see what you mean. Yes, no reason one couldnt do it that way. Ill give it some thought..
Art
Art
Re: Bevel Gear
>>How do you tell the machine which direction to apply the tool comp in? In two dimension s it is perpendic ular to the path, but in three dimension s you have to tell it what the surface normal is....
Normals are pretty easy to compute on a bevel really.. well OK not easy but doable. Ill give this a bit of
thought for the next attempt at easier bevels..
Art
Normals are pretty easy to compute on a bevel really.. well OK not easy but doable. Ill give this a bit of
thought for the next attempt at easier bevels..
Art
Re: Bevel Gear
Calculating the normal is easy (cross product of the vector from the sphere's center and the vector tangent to the path) but where in the g-code do you tell the machine what the normal is?
Re: Bevel Gear
>>but where in the g-code do you tell the machine what the normal is?
You dont. You use the normal to calculate the minimum distance to contact that normal for the waypoints you make. Of course
thats basically the same as any 3d pocket contouring problem, and has the same troublesome problem of normals that intersect in spots when the tool becomes too small to fit. There is no easy solution, each one you think of will have complexiities in differing area's is all. This one is basically a pocketing in 3 dimensions and limiting the pocket motion to circular motion. Or I should more
properly say its an engraving in circular form with more or less the same codeing as doing a photograph raster engraving where you
have to figure where a surfaces nomal disallows a particular depth so you rise above that depth for that waypoint.
( Christ this stuff needs a new language for description..math is so hard to explain in english..needs diagrams to be clear really..)
Art
You dont. You use the normal to calculate the minimum distance to contact that normal for the waypoints you make. Of course
thats basically the same as any 3d pocket contouring problem, and has the same troublesome problem of normals that intersect in spots when the tool becomes too small to fit. There is no easy solution, each one you think of will have complexiities in differing area's is all. This one is basically a pocketing in 3 dimensions and limiting the pocket motion to circular motion. Or I should more
properly say its an engraving in circular form with more or less the same codeing as doing a photograph raster engraving where you
have to figure where a surfaces nomal disallows a particular depth so you rise above that depth for that waypoint.
( Christ this stuff needs a new language for description..math is so hard to explain in english..needs diagrams to be clear really..)
Art