Expose functions that provide measurements of bevel gears

[ReallyCoolName]

I would like to use the bevel gears, but as far as I can tell there is no exposed way to calculate things like the position of the tip of the cone containing the bevel gear.

Use case would be calculating where I need to poke a hole for the gear's shaft to go through.

I tried looking through the code and it got very complicated.

Since bevel_pitch_angle is exposed, I think giving 2 points on opposite ends of the circle which is the base of the cone containing the bevel bear will also do, since you can derive the entire cone from this.

(And thank you for the amazing work you do)

[adrianVmariano]

I think the "apex" anchor point provides the position of the tip of the cone? Can you explain why you need the cone tip for making gear shaft holes? I don't think I understand what you're doing.

[ReallyCoolName]

Perhaps I don't understand what I'm doing. Looking at the code again I see I can get the anchor from the bevel_gear function, though it requires using an undocumented argument _return_anchors

As for why I need the cone tip to make gear shaft holes: as I understand it, the tips of the cones of a pair of mating bevel gears touch, so the tip of the cone for one gear is at the height at which the hole for the shaft should be (in the case where they mate at a 90 degree angle)

[adrianVmariano]

The point of the anchor is that you can put something there directly without explicitly knowing the coordinates of the anchor. I'm trying to understand if that functionality is insufficient for your application.

The hole for the shaft can presumably be anywhere along the centerline of the cone. The apex is not obviously a distinguished point for positioning the shaft hole. Furthermore, you can't put both shafts at the apex---they'll be trying to occupy the same space. Maybe post some example code?

[ReallyCoolName]

The point of the anchor is that you can put something there directly without explicitly knowing the coordinates of the anchor. I'm trying to understand if that functionality is insufficient for your application.

Then the problem would be getting the anchor, I am not aware of an exposed way of doing so (not counting the use of _return_anchors which seems not to be not intended for general use). Unless there's a way it's meant to be grabbed that I'm not aware of? as far as I can tell all the anchors for the bevel gear are calculated inside the bevel_gear function and don't use a function that's exposed.

The hole for the shaft can presumably be anywhere along the centerline of the cone. The apex is not obviously a distinguished point for positioning the shaft hole. Furthermore, you can't put both shafts at the apex---they'll be trying to occupy the same space. Maybe post some example code?

I didn't mean that I would put the shaft at the apex - just that I can get the centerline of the cone from the position of the apex (combined with the angle of the mating of the gears).

example code: if I were to have a bevel gear sitting with its base at height 0, at what height do I need to place the shaft for its mating gear, which mates at an angle of 90 degrees?

include <BOSL2/std.scad>
include <BOSL2/gears.scad>

t1 = 10; t2 = 10;
vnf = bevel_gear(mod=2,teeth=t1, mate_teeth=t2, slices=12,anchor="apex", spiral=0,cutter_radius=0,_return_anchors=true);

translate(vnf[1][2][1]) rotate([90,0,0]) cylinder(r=1,h=20, center=false);

also, using flattop anchor and translating the bevel gear by 2*vnf[1][1][1] seems to place the bevel gear with its bottom at height 0, which is also useful for positioning pieces relative to the gear

[adrianVmariano]

Why do you need to "get" the anchor. The point of anchors is that you put things there, not that you "get" them. You should not use the undocumented internal _return_anchors parameter, as its behavior can change at any time.

There is also no guarantee that the VNF will be produced in the same order or format in future versions of the code, so relying on a specific vertex or face sequence is risky.

Suppose we provided a function that returns the cone apex. I imagine this would be a function that returns a single value, the distance of the apex from the pitch base. Would that even help you? How would you use it? The shaft is determined by being centered on the gear and orthogonal to it, and knowing the cone apex distance seems not very useful. Presumably in your example you would determine the location of the crossing axis by using the pitch radius, which is already provided by a function. One could ask how are you positioning gears so they mesh if you aren't using the pitch radius to do it.

How about a complete example with two meshing gears that shows the difficulty in shaft placement?

[ReallyCoolName]

Why do you need to "get" the anchor. The point of anchors is that you put things there, not that you "get" them

What I meant was I don't know how to place additional things (e.x. a shaft) at that anchor point, as (it seems to me) the anchor is created and used internally by bevel_gear, so if I wanted to place additional things at, say, the apex, I can't quite figure out how to do it without extracting its position from the bevel_gear function, which as you said, I shouldn't. That's why I'm asking for additional features

and knowing the cone apex distance seems not very useful.

but the cone apex combined with bevel_pitch_angle is useful

Presumably in your example you would determine the location of the crossing axis by using the pitch radius, which is already provided by a function

Are you referring to the pitch_radius function? It wasn't clear to me that it also applies to bevel gears, that's my bad - I assumed it's for spur gears only

How about a complete example with two meshing gears that shows the difficulty in shaft placement?

The main point of this example is to demonstrate the difficulty of creating some sort of housing for the pair of meshing gears - without using vnf[1], I have no clue how I could position the shaft at the bottom (for the horizontal bevel gear to rotate around) and the hole, unless I'm missing something (the shaft is the cylinder - 2nd line in union that creates the base. the hole is the difference starting at the 3rd line of the same union)

include <BOSL2/std.scad>
include <BOSL2/gears.scad>
t1 = 16; t2 = 28;

vnf = bevel_gear(circ_pitch=5, teeth=t2, mate_teeth=t1, right_handed=true,
    slices=12, anchor="apex", backing=3,_return_anchors=true
);
union() {
    bevel_gear(
        circ_pitch=5, teeth=t1, mate_teeth=t2,
        slices=12, anchor="apex", orient=FWD
    );
    rotate([-90,0,0]) translate([0,0,20]) cylinder(r=2,h=20);
    }
difference() {
    bevel_gear(
        circ_pitch=5, teeth=t2, mate_teeth=t1, right_handed=true,
        slices=12, anchor="apex", backing=3, spin=180/t2
    );
    cylinder(r=2.1,h=100,center=true);
}
translate(-vnf[1][2][1]-vnf[1][1][1]-[0,0,1])
union() {
    cube([40,60,2],center=true);
    cylinder(r=2, h= 8);
    difference() {
        translate([0,30,19]) cube([40,2,40],center=true);
    translate(vnf[1][2][1]+vnf[1][1][1] + [0,0,1]) rotate([-90,0,0]) cylinder(r=2.1,h=40,center=false);
    }
}

(I'll admit it was difficult to come up with a specific example for this one because the anchors make it so easy - the axes go right through the centers of the meshing gears)

[ReallyCoolName]

Ok, I'm learning some new things about how the anchors work, like the fact it applies to children.

But I can't figure out how to, for example, design a box that contains my gears, since I can't get their dimensions without the ill-advised undocumented _return_anchors, or design the housing as I did in the previous comment, as it requires combining the information in 2 different anchors to place the hole correctly relative to the base of the gear.

[adrianVmariano]

I took a look at your code and you're anchoring on the apex which means you then don't know where anything is. If we gave you the apex distance you still wouldn't know where things are because you don't know the distance between the bottom of the gear and the pitch base. If you instead anchor on the pitch base and use the bottom parameter then you can position the gears with pitch_radius() and you know where everything is. (You could conceivably anchor on BOT but then I think it will be hard to mesh the gears.) You could also make the enclosure wall as a child of the gear and anchor it to the gear bottom, but then I think it will be hard to connect parts of the enclosure.

include <BOSL2/std.scad>
include <BOSL2/gears.scad>
$fn=16;
t1 = 16;
t2 = 28;
bottom = 3;
bevel_gear(circ_pitch=5, teeth=t2, mate_teeth=t1, right_handed=true,
    slices=12, bottom=bottom, shaft_diam=4
);
difference(){
  down(bottom)
    cuboid([50,60,2],anchor=TOP);
  cyl(r=2,h=200);
}  

up(pitch_radius(circ_pitch=5,teeth=t1))
  back(pitch_radius(circ_pitch=5, teeth=t2)){
    difference(){
      back(bottom)
        cuboid([50,2,35],anchor=FWD);
      ycyl(r=2,h=200);
    }  
    bevel_gear(
            circ_pitch=5, teeth=t1, mate_teeth=t2, bottom=bottom,
            slices=12, orient=FWD, spin=360/t1/2, shaft_diam=4
        );
  } 

[ReallyCoolName]

If we gave you the apex distance you still wouldn't know where things are because you don't know the distance between the bottom of the gear and the pitch base

I'll take your word for it since you're obviously more familiar with the code than I (though as far as I can tell, a correct combination of the anchors can give me what I need, as evidenced by the fact things in my code seem to line up), in which case, there would be more calculations that need exposing aside from the apex location.

You could also make the enclosure wall as a child of the gear and anchor it to the gear bottom, but then I think it will be hard to connect parts of the enclosure.

Finally, a good reason to expose some functions that give us the dimensions of the bevel gear, no?

[adrianVmariano]

Since my example works fine without needing anything new exposed I am not seeing a clear need to expose something new. If we need to provide a function to calculate some new thing, we need to know what that new thing would be.

Everything about bevel gears is referenced to the pitch base which is located in the middle of the gear, so the apex distance would not be the distance to the bottom of the gear, but the distance to the pitch base. You could use this to position things next to the gear---if you use the bottom parameter---but you can do this already without the extra parameter as I illustrate above. That is, the key thing that makes it work is setting bottom, not having access to the apex distance.

When I said it would "be hard" to connect parts of the enclosure what that means is that you don't know the distance from the pitch base to the bottom of the gear. This is the problem that the bottom parameter is meant to solve. You need to know this to know where the intersection point of the enclosure walls will be. It's also awkward because the enclosure walls are constructed in different places as the children of different gears. It's probably easiest to actually construct the gears relative to that intersection by shifting each gear along the enclosure wall by its pitch_radius().

[ReallyCoolName]

I think I'm beginning to understand (and I think I've wasted your time once again, for that I am sorry).

only problem left that I can think of is figuring out the length of the shaft needed to go through the whole bevel gear; but eyeballing that is good enough for me.

Thank you for your help and work.