GearHeads Forum

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

Art,
Perhaps beer would be a better lubricant than coffee for translating Euclidean topology to spherical topology...

--Justin

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,

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.

>>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

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?

>>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

Ahh, I  see what you mean. Yes, no reason one couldnt do it that way. Ill give it some thought..

Art

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.

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....