FC Gears: Feedback thread

[abdullah]

Hi!

I decided to start a feedback thread for FC Gear WB here, as the forum is a good way of sharing points of view, and surely many of you know way more about gears than me, so you can correct wrong statements and contribute to the development ideas.

I was discussing with loo, the mastermind after the Gear WB about the challenges of bevel gears. We shortly posted here:
https://github.com/looooo/FCGear/issues ... -374728367

So basically (if I got it right), in the original Gears WB, the origin of the bevel gear was the center of the sphere used for projection. The plane cutting the gear profile and passing by this origin defines the plane where the module is exactly the number provided (e.g. m=1 mm), as in bevel gears the module is not constant. The gear is extended the same amount to both sides of this plane, giving in total the height parameter.

Construction of the gear

This, I thought at least, generated a big issue when working the original gear object to create an actual object having a gear (for example with PDNext). Changing the gear likely changed the number of faces making any attachment to a face changing due to toponaming. I realize now (that I better understand it), that I could have defined this bottom face plane just by offsetting a plane passing by the origin (the XY plane of the gear) by height/2 using an expression (or at other distance if I must cut the gear from the bottom part in any other way).

In any case, loo added in a branch an option to have by default the origin translated to the bigger face. This makes it easier to further work on the object.

I realize now that I can live with any of both origins.

Alignment of the gear

In any case, all this thinking about gears has brought me to the wonderful world of designing gears and I have learned (read half learned) the hard way that aligning bevel gears is a pain. Even for the most straight-forward case (two equal 45 degree pitch bevel gears) and still disregarding clearances, making an good alignment without some clear "references" ("pitch cone apex", or a defined "mounting distance",) is quite a nightmare. In this example I have imported the gears to PDN as base features and I have attached some planes to opposing faces (of the crown and slot) and datum lines through the axis in both (I have changed the colors of one to pink to make it clearer) and I have aid myself by using a perpendicular perspective:

Align_gears.gif (110.23 KiB) Viewed 6011 times

And that is for the most straight-forward simplified case as I said.

I was reading this practical guide too:
https://www.geartechnology.com/issues/0 ... lation.pdf

I do not know exactly how one designs/aligns bevel gears. Not even how does one align then in a CAD package after having them designed. I am closer to a programmer than to a mechanical engineer. I have read there are formulas for these things. The mekanex catalog (in some Nordic language,se/no/dk/fi, which I do not quite understand, and which drive Google translation crazy) shows some positioning formulas:

Mekanex_cat.png (50.17 KiB) Viewed 6011 times

I thought about calculating (this and/or other) parameters inside the Gear WB, read-only, and using them via the expression engine for positioning/aligning the objects. I am not sure whether that is a good idea or not, or if there are better ideas. In any case, alignment seems to be an issue.

Design of the gear

Many things have to be taken into account to design gears, most of them I ignore. Probably it would make sense to have some kind of "Gear designer" tool. This is an advanced feature. But I wanted to have it here.

Feel free to comment and contribute

[triplus]

Progress in this area for sure is welcomed. As for assembling the gears. That might end up being the task for Assembly workbench. Try out Assembly 3 workbench to see how that goes.

[microelly2]

it's a good idea to have this thread,
I'm interested in the improvement of my collision tools, gearings are a good place to see how object match in motion and to see where destructive forces can occur.

[looo]

Progress in this area for sure is welcomed. As for assembling the gears. That might end up being the task for Assembly workbench. Try out Assembly 3 workbench to see how that goes.

I also think the task of assembling gears will be part of an assembly-workbench. But somehow the assembly module must know how to connect the gears. So gears must provide some properties, which can be used by the assembly module. So some kind of interface between these workbenches has to be defined. I guess finding and defining a generic interface is the first step. But as the assembly module is changing quite frequently, I don't know if now is the right moment to do this.

Actually we allready had some discussion about this:
https://github.com/looooo/FCGear/issues/10
I guess lack of understanding of assembly /part-design was the reason why we didn't made any progress.

[looo]

it's a good idea to have this thread,
I'm interested in the improvement of my collision tools, gearings are a good place to see how object match in motion and to see where destructive forces can occur.

Doing some dynamic FEM with coupling of two gears, where one gear is driven. I guess this is a much more advanced topic.

[looo]

I just tried to align the meshed gear from the topic Truggy differential challenge. I post this here as I think it is slightly related to this topic.
I used a statistical method to find the origin of both gears. This assumes that all generating lines of the profile are intersecting in the origin:

1. extend some lines of the profile (draft-workbench, I like the workflow *)
2. compute intersection point by finding a point with minimum distance to all lines (least-square-problem)
3. compute the diff of the two gears
4. adjust the position

file is attached. It looks like the profile of the meshed gears is not very well aligned....


* snapping points only would be a nice addition for draft-snapping-tools. I don't think this is currently possible.

ps.: I post the scrpt for the nearest-point detection here (to not loose it). Such least-square methods would be a nice addition fro draft-wb:

Code: Select all

import numpy as np

def find_origin(group_name):
    math_lines = []
    a = App.ActiveDocument.getObjectsByLabel(group_name)[0]
    for line in a.Group:
        math_lines.append([np.array(line.Start), np.array(line.End)])

    # normalizing
    for line in math_lines:
        line[1] -= line[0]
        line[1] /= np.linalg.norm(line[1])

    mat = np.zeros([len(math_lines) * 3, len(math_lines) + 3])
    vec = np.zeros([len(math_lines) * 3])

    for i, line in enumerate(math_lines):
        for j in range(3):
            mat[i * 3 + j, i] = line[1][j]
            mat[i * 3 + j, j - 3] = 1
            vec[i * 3 + j] = line[0][j]

    p = np.linalg.lstsq(mat, vec)[0][-3:]
    return p

p1 = find_origin("mid_point_drive")
p2 = find_origin("16T")

diff = p2 - p1
print(diff)

[abdullah]

I just tried to align the meshed gear from the topic

The alignment of those two is on me, as they are stls I imported and oriented.

tried to look into the alignment of the assembly of the differential, which comes directly from the author:
https://www.thingiverse.com/download:183633

and they may not be that well either:

diff_gears_align.png (112.37 KiB) Viewed 5636 times

file:

extend_trial.fcstd

(620.01 KiB) Downloaded 108 times

[abdullah]

Progress in this area for sure is welcomed. As for assembling the gears. That might end up being the task for Assembly workbench. Try out Assembly 3 workbench to see how that goes.

I also think the task of assembling gears will be part of an assembly-workbench. But somehow the assembly module must know how to connect the gears. So gears must provide some properties, which can be used by the assembly module. So some kind of interface between these workbenches has to be defined. I guess finding and defining a generic interface is the first step. But as the assembly module is changing quite frequently, I don't know if now is the right moment to do this.

Actually we allready had some discussion about this:
https://github.com/looooo/FCGear/issues/10
I guess lack of understanding of assembly /part-design was the reason why we didn't made any progress.

I do not know anything about the Assembly modules (1, 2 or 3). I have a beginners understanding of PartDesign. As far as it is C++ code I can contribute with checking things (looking how things are done, how could be changed, ...) and of course it goes without saying, with coding.

My very general understanding is that Assembly today works with physical entities (points, faces, ...) and a solver that solves for some constraints on the placement of those entities. Maybe it is that I tend to assimilate it how the Sketcher works, where I have a more decent understanding of the whole picture.

From my deep ignorance, these are some ideas:

a) Alternative 1: Create physical entities, an example:
a.1. Create a set of (datum) planes, points, lines with the Gear. This entities are "linked" to the gear object (for an example of practical implementation, there is the realthunder-paulee idea of exporting sketch edges, which can be construction lines, let's say these datums are "construction entities", not part of the real shape of the gear, but exported from it for alignment). Of course, if a construction entity is moved/rotated, the gear shall be notified and act consequently.
a.2. Use any assembly relationship as assembly normal working.

This approach has obvious limitations (the degree to which simple elements can define the needed relationship), but may be sufficient for a great majority of the cases.

b) Alternative 2: Use expressions alike approach. Which is the other way that can be used in the sketcher to "link" things.
b.1. The user manually sets relationships via the expression engine, which the Assembly solver "respects", so they are fixed parameters for the assembly solver. Not sure how this is implemented in the Assembly solver, I know how it would be implemented in the Sketcher's GCS solver (i.e. how it is implemented there).

c) Alternative 3: Implement a distributed solver in assembly (most probably I do not know what I am talking about)
c.1) If the assembly solver is the one that has to decide what to do with the "placement" to effect a change in a "mounting distance", it may need the gradients of how the mounting distance is modified. It does not sound reasonable that the assembly knows this, so the "interface" could be between the "Gear Object" and the Assembly, where the "Gear Object", obviously knows this information and conveys it to the assembly solver. Whereas the Sketcher's GCS solver is centralised, in that it comprises all knowledge about differentials of sketch supported elements, which means that supporting a new type in the sketcher means providing a corresponding implementation in the GCS solver, in a maybe possible implementation this support for assembly could be done in a distributed fashion, being the object responsible for responding the question of how its properties change when the placement changes. So, for example, normal objects will not implement an interface for assembly and may be given a default treatment (placement driven) by the assembly WB, objects requiring more dedicated alignment, may implement an special interface responsible for this interchange of information.

I think it clearly points to our need for Assembly. We probably should seriously think how we want to proceed with assembly in v0.18-v0.19.

[ezzieyguywuf]

I do not know exactly how one designs/aligns bevel gears. Not even how does one align then in a CAD package after having them designed. I am closer to a programmer than to a mechanical engineer. I have read there are formulas for these things.

I am a mechanical engineer. I do believe there are formulas "for these things". In particular, I've relied heavily on Shigley's Mechanical Design for problems regarding gear design. I have this text in my office, I can review the equations on monday and perhaps shed a little bit of light on this situation.

[abdullah]

I do not know exactly how one designs/aligns bevel gears. Not even how does one align then in a CAD package after having them designed. I am closer to a programmer than to a mechanical engineer. I have read there are formulas for these things.

I am a mechanical engineer. I do believe there are formulas "for these things". In particular, I've relied heavily on Shigley's Mechanical Design for problems regarding gear design. I have this text in my office, I can review the equations on monday and perhaps shed a little bit of light on this situation.

Thanks! I always wanted to have a reference for mechanical design.

I must admit I am getting fascinated by gears.