FC Gear module

[sjam986]

My problem has not gone away. I have updated the gears module and have tried to copy Looo's bevel gear example but cannot get a revolved sketch to cut into the gear. The software keeps telling me that the gear is not a part and insists on creating a new body for the sketch.
Can someone please set out the detailed steps needed to recreate the bevel gear example.

[looo]

The example is not done with partdesign. Not sure if partdesign has a common- feature. As far as I know partdesign only allows to subtract and add geometries. Due to this limitation, better work outside part-design. You can do this by switching to the Sketcher workbench and create a sketch directly.

If you want to further modify the gear with partdesign, drag the object you want to modify into a body container.

[sjam986]

Thanks for that. I have managed to edit a gear within a Body using the Sketcher module and the Part module. If I attempt to edit it further using the Part Design module, I get problems, but I can live with that.

[chrisb]

Done: https://github.com/looooo/freecad.gears ... 048374aea7

I have investigated the new PartDesign aware gears and made the following observations:

• If I add a single gear to a body and attach a sketch to it, it works as expected. I can pad and pocket it. This is a dangerous workflow, because changing e.g. the number of teeth is a guarantee to break the model.
• If I add a single gear and attach a sketch to a main plane, the gear is completely ignored. It doesn't contribute to the body.
  See BodyOneGear in the attached model.
• Having two gears in a body, which may well occur e.g. in a clock gear, the second gear behaves as if it doesn't belong to the body. It is not possible to attach something to that gear. The first gear is treated as in the case with a single gear.
  See BodyTwoGears in the attached model.
• Even if a sketch is attached to the gear with a correctly working feature, visibilty is not ok: The visibility of the gear can be changed independent of the other features.

[looo]

Done: https://github.com/looooo/freecad.gears ... 048374aea7

I have investigated the new PartDesign aware gears and made the following observations:

• If I add a single gear to a body and attach a sketch to it, it works as expected. I can pad and pocket it. This is a dangerous workflow, because changing e.g. the number of teeth is a guarantee to break the model.
• If I add a single gear and attach a sketch to a main plane, the gear is completely ignored. It doesn't contribute to the body.
  See BodyOneGear in the attached model.
• Having two gears in a body, which may well occur e.g. in a clock gear, the second gear behaves as if it doesn't belong to the body. It is not possible to attach something to that gear. The first gear is treated as in the case with a single gear.
  See BodyTwoGears in the attached model.
• Even if a sketch is attached to the gear with a correctly working feature, visibilty is not ok: The visibility of the gear can be changed independent of the other features.

I guess what we need are different behavior of the gear dependent on the position where it is inserted in the body. If it is at the top, it's fine to simple use the shape of the gear as a starting point to add pd-features. But if it is not at the top the gear should behave like an addidive/subtractive feature. So a solution would be to always add a property "pd_feature_type" to the gear if it is inserted into a body. 3 different types should be available:

- additive (default) -> takes shape of tip and creates a boolean union operation, or returns the shape if no tip is available
- subtractive -> takes the tip and subtracts the gear
- common -> takes the tip and creates a common operation with the gear

But all this should not be part of the gear workbench and instead be handled by the part-design workbench.

[chrisb]

Due to the non trivial shapes such as bevelled gears, it is not possible to use only the shape and leave it to pad and pocket to add or subtract.
Hopefully somebody with more insight into PartDesign can help. Ickby, of course, knows the PartDesign mechanisms very well, but also TheMarkster as author of ThreadProfile comes to mind.

ping

ping

[TheMarkster]

ThreadProfile objects are basically Draft 2d objects, which gives them automatically compatibility with Part Design, much as you can simply drag and drop a Draft BSpline into PD and use it as you would use a sketch. The workbench automates sweeping the profiles along the helices as a convenience to the user, but all of that can be done manually within Part Design.

The Gear objects, on the other hand, are parametric solids. I don't know of any solids created in other workbenches that can be used inside Part Design Body objects except as BaseFeatures, which limits them to only 1 per Body.

[chrisb]

Thanks for the information. For the sake of clear concepts it may be reasonable to rollback to the previous version where gears had to be used as BaseFeatures.

[looo]

Thanks for the information. For the sake of clear concepts it may be reasonable to rollback to the previous version where gears had to be used as BaseFeatures.

Yes I think so too. The current situation will lead to more confusion. I guess it's best to work on the base-feature to allow other types of pd-operations (like I said in the previous post). So all we need is:

- Add a property "operation" to the base-feature which can be "base", "additive", "subtractive", "common".
- Another idea is to handle the feature that is added to the body via base-feature as a child of the base-feature.

Is anyone familiar with the base-features?


Btw. the introduction of additive /subtractive primitives in part-design is (in my eyes) a bad approach. First, there is no chance to add all of the possible geometries. So only the basic types will be directly available. And secondly, it is really a duplication of part-functionality. If there would be a smarter integration of part-features in part-design, there wouldn't be any need for additive/subtractive features. In addition, we also need all the tools for a common operation (as we see with bevel-gears).

[looo]

The BaseFeature can be used as a profile of a pad-operation in a part-design body. So although the BaseFeature is always inserted at the top of the body (tree-view) it is not necessary to use it as a base-object (If base is referring to the base (top) of the body). So using the BaseFeature as a Feature acting as a boolean-operation on the tip to me sounds like a feasible option.

Maybe someone can explain what holds us back from further integration of Part-Object into Part-Desing Bodies. Part-Design is really lacking functionality to compete with the Part-Workbench. To avoid further duplication of functionality I think it's best to work on the interface between Part and Part-Desing (BaseFeature).