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
Bevel Gear
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
Re: Bevel Gear
Art, drink coffee before reading this,
I looked around and learned that 3d tool comp is pretty much impossible -- the tool comp needs to happen when the geometric data is converted into the g-code, which pretty much means it is not usable. Once it is g-code, the only way to do 3d tool comp would be to compare adjacent tool paths, which is equivalent to converting back to geometric data, which would be dumb.
Producing the spherically concentric tool paths for a bevel gear is vaguely comparable to producing them for a 2-1/2 D spur gear tool path, except instead of a different Z for each deeper pass, there is a different spherical radius for each pass. (There is also a headache in thinking about what the spherical version of an involute is--"spherical involute" or "octoid").
There is a kmoddl that is related:
http://kmoddl.library.cornell.edu/model.php?m=242
These spherical shapes are as much like a cycloid as they are like an involute.
I looked around and learned that 3d tool comp is pretty much impossible -- the tool comp needs to happen when the geometric data is converted into the g-code, which pretty much means it is not usable. Once it is g-code, the only way to do 3d tool comp would be to compare adjacent tool paths, which is equivalent to converting back to geometric data, which would be dumb.
Producing the spherically concentric tool paths for a bevel gear is vaguely comparable to producing them for a 2-1/2 D spur gear tool path, except instead of a different Z for each deeper pass, there is a different spherical radius for each pass. (There is also a headache in thinking about what the spherical version of an involute is--"spherical involute" or "octoid").
There is a kmoddl that is related:
http://kmoddl.library.cornell.edu/model.php?m=242
These spherical shapes are as much like a cycloid as they are like an involute.
Re: Bevel Gear
Justin:
>>Art, drink coffee before reading this,
As it turns out, I just did. :)
>>I looked around and learned that 3d tool comp is pretty much impossible
Not really, I understand it has been done in some 5 axis systems.. The GCode as its interpreted can create a solid model internally, which is then used as a
collision detector to ensure the toolpath remains out of collision with the object the Gcode describes. Very expensive system mind you..
>> the tool comp needs to happen when the geometric data is converted into the g-code, which pretty much means it is not usable. Once it is g-code, the only way to do 3d tool comp would be to compare adjacent tool paths, which is equivalent to convertin g back to geometric data, which would be dumb.
I agree that tryng to tell an ordinary interpreter to "tool comp" a 3d object is not the best way, the program generating the Gcode has all the information
it needs so its the Gcode generator that shoudl generate all such offsets as it does the generation.
>>Producing the spherically concentric tool paths for a bevel gear is vaguely comparable to producing them for a 2-1/2 D spur gear tool path, except instead of a different Z for each deeper pass, there is a different spherical radius for each pass. (There is also a headache in thinking about what the spherical version of an involute is--"spherical involute" or "octoid").
Actually, though in your idea the paths are spherical, the tool shape remians involute..or whatever the shape of the original tooth. Since the Z motion is not
straight up and down, but also in a spherical motion, the produced shape of the tooth remians as the original tooth shape, an involute. It would only change the tooth
shape if the path was circular, not spherical. But if your describing the end motion of the tool, then yes, I agree, the motion woudl be strange, Id describe it more
as a tilted involute, tilted to the bevel angle. Since bevels are not supposed to include undercuts, ( tooth count on a bevel should always be high enough to ensure no troichoid is used generally ), the scheme should work. Very hard to say though, Ive found the devil is always in the details on such things..
Art
>>Art, drink coffee before reading this,
As it turns out, I just did. :)
>>I looked around and learned that 3d tool comp is pretty much impossible
Not really, I understand it has been done in some 5 axis systems.. The GCode as its interpreted can create a solid model internally, which is then used as a
collision detector to ensure the toolpath remains out of collision with the object the Gcode describes. Very expensive system mind you..
>> the tool comp needs to happen when the geometric data is converted into the g-code, which pretty much means it is not usable. Once it is g-code, the only way to do 3d tool comp would be to compare adjacent tool paths, which is equivalent to convertin g back to geometric data, which would be dumb.
I agree that tryng to tell an ordinary interpreter to "tool comp" a 3d object is not the best way, the program generating the Gcode has all the information
it needs so its the Gcode generator that shoudl generate all such offsets as it does the generation.
>>Producing the spherically concentric tool paths for a bevel gear is vaguely comparable to producing them for a 2-1/2 D spur gear tool path, except instead of a different Z for each deeper pass, there is a different spherical radius for each pass. (There is also a headache in thinking about what the spherical version of an involute is--"spherical involute" or "octoid").
Actually, though in your idea the paths are spherical, the tool shape remians involute..or whatever the shape of the original tooth. Since the Z motion is not
straight up and down, but also in a spherical motion, the produced shape of the tooth remians as the original tooth shape, an involute. It would only change the tooth
shape if the path was circular, not spherical. But if your describing the end motion of the tool, then yes, I agree, the motion woudl be strange, Id describe it more
as a tilted involute, tilted to the bevel angle. Since bevels are not supposed to include undercuts, ( tooth count on a bevel should always be high enough to ensure no troichoid is used generally ), the scheme should work. Very hard to say though, Ive found the devil is always in the details on such things..
Art
Re: Bevel Gear
Art,
Perhaps beer would be a better lubricant than coffee for translating Euclidean topology to spherical topology...
--Justin
Perhaps beer would be a better lubricant than coffee for translating Euclidean topology to spherical topology...
--Justin
Re: Bevel Gear
Something a bit stronger than beer I fear...
Actually, Im doing a lot of work now on the new "Gearotic Thoughts", its a lot of 3d modeling work, so Im learnign reams,
it will likely help me quite a bit when I go to new Gcode generators for things like bevels..We'll carry this discussion
on when I reach that point..
Thx for the thoughts,
Art
Actually, Im doing a lot of work now on the new "Gearotic Thoughts", its a lot of 3d modeling work, so Im learnign reams,
it will likely help me quite a bit when I go to new Gcode generators for things like bevels..We'll carry this discussion
on when I reach that point..
Thx for the thoughts,
Art
Who is online
Users browsing this forum: No registered users and 5 guests