BUGS - new PartDesign with Body and Datum features

[jriegel]

We have to deactivate moving features in Bodies!

[ickby]

We have to deactivate moving features in Bodies!

Sure, but the problem is the transformed part (Assembly::ItemPart). The visual representation of the thing changes, but not the underlying shape. So if a user creates a sketch on that body by selecting a face, the sketch plane will be different then the selected plane.

Jan, annother thing I noticed: We already talked in IRC about the problem of transformed sketches (and that they skrew the assembly). The discussion ended with the statement, that sketches can't be transformed. This holds in the current implementation (any change to the placement gets reverted instantly), however, if one chooses a initial plane other than xy as reference, the sketch is rotated! As I don't see this transformation from assembly workbench,therefore all geometries I extract are wrong for this case.

What do you think how to proceed on that?

[jriegel]

For PartDesign its only save at the moment to refer objects (planes) inside the same body.
For revering outside geo we lack the tools at the moment. We need tools there which traverse the whole assembly tree and give the relative or absolute position to the Body the new sketch is in...

For the moment we can check if geo is outside the Body and warn the user...

[logari81]

I think this is the same problem that I had solved with the invObjLoc trick in all partdesign features at that point. We had said that we could remove invObjLoc provided that we force that all features under a Body feature are "untrasformed".

BUT!!! this is not completely correct, features cannot be "untransformed", e.g. if you make a sketch in the YZ plane it will be transformed anyway. What we actually wanted to say is the following:
"we place all features under a body feature with respect to the Body feature placement."

This means that where a features appears in the assembly will be defined by Body_Placement * Feature_Placement.

Making the features "untransformed" means that we hide Feature_Placement property or we make it read-only.

Then we need to decide if we keep invObjLoc or not:
A. if we use the same OCC global coordinate system for the assembly and the individual bodies, then we need to keep invObjLoc, with
TopLoc_Location invObjLoc = BodyFeature->getLocation().Inverted();
instead of
TopLoc_Location invObjLoc = this->getLocation().Inverted();
B. if we use different OCC global systems for the assembly and the individual bodies then we can kill invObjLoc. But then, whenever we want to do OCC operations in the assembly, e.g. check overlapping between parts, we need to bring the parts into a common OCC coordinate system.

The way Body feature was implemented makes A not a possible option, because BodyFeature->getLocation() cannot be implemented in the part design features. The body is a child of its features, so the features cannot use its placement in internal calculations. So we stay with option B.

Option B in other words means that the Placement of the Body feature acts "on-top" of the placements of the contained features, both in a single file or an assembly file.

I haven't checked how close to B is the implementation of jriegel, ickby and jrheinlaender so far but this is a very important design decision for the assembly. Please make sure you know what you are doing and try to make sure that we all talking about the same thing. Is anyone that doesn't understand why invObjLoc was used and how it works?

[jriegel]

(A) is generally impossible, cause there is no "World Coordinate" system in CAD anyway. The product/assemblies are always directed acyclic graphs not trees. There fore the same Part/Body can be used in different Assemblies or is reachably on different Paths on the Assembly graph. For handling relativ positions between bodies we need a special Tool set. This tool-set will be mostly in the Assembly work-bench with some parts in the Base system. This means the PartDesign has to concentrate on Body local modeling! Inter Body dependencies has to be handled with e.g. Assembly features or an explicit interface. This Tools would e.g. be:

* Adding a path notation to the Selection, because the same Body can show up on different postions in the 3D View. If the user select a Body its only unique if we also collect the Assembly/transformation path above.
* Tools to calculate the displacement of Bodies/Parts to each other in a given coordinate frame (e.g. active Assembly).
* defining interfaces (for geo, parameters, ..) to allow modules/workbenches to work Part-local.
* All the tools have to be proper interfaced to python, since I think most of the meta work on Assembly graphs will be done with Python (BOM, build positioning, importing catalog parts,....).

Some of the concepts I want to be in Assembly seam at the moment a bit unneeded. But my main goal is the multi-model design, where all Parts and SubAssemlies are in own files. That will open FreeCAD for really big complicated design-projects and the whole PDM world. And in this scenario its very important to keep a single Body/Part as local as possible, cause maybe the other bodies are not even loaded......

[ickby]

Hm is start to see the picture.

The thing is: to bring all the stated requirements together in a sensible manner a good design is required (which you have apperently already in your head) , especially for assembly and for the base system stuff. Currently I don’t have enough insight into FreeCAD to go for it, and to be honest, I would like to focus on the solver implementation (still lots of work to do!). However, I would also love to see a nicely working assembly module . Therefore my next actions depend on your timeframe, jriegel (or someone else’s if he wants to step in):

1. If you have some time available in the near future to implement your desing ideas and I wait and do some tiny solver integration stuff later. That would be the fastest way.

2. If you’re plans don’t include assembly for the next few months I would start creating a design document and hopefully come up with something useful. We would then discuss the design before I go for the implementation. This process would of course take very long.

What is your opinion about that?

[jriegel]

My plan for the near future is for sure integrate Assembly into master. The biggest point there fore is anyway the PartDesign changes. The skeleton on Assembly is already working
and we can add features if we have time.

I could write down a huge design documentation, but mostly its a better idea to use the time coding, lay out a frame. Hopping someone pick up and helping do some details.
Mostly it worked quit well. Good example is the Sketcher. After feting the initial version running (with sketchflat) Logari and other step in and did an amazing job! There was no change I had so much time to do it.

So I will go soon for Master with the new stuff, what will cause some heat for you Ickby
I think there will be a lot discussion about solver behavior in under-constraint systems. Your solver, at the moment, force to a fully constraint system, which is in non trivial designs, a lot to do. We had this discussion already...

I think for the near future a RepRap Mendel in one file (~30 Parts) is a good use case for Assembly. Maybe we can get there till the 0.14 release...

[ickby]

that sounds good

[NormandC]

I think for the near future a RepRap Mendel in one file (~30 Parts) is a good use case for Assembly. Maybe we can get there till the 0.14 release...

Count me in! I've been waiting for the assembly module to complete this RepRap FreeCAD assembly: https://github.com/normandc/Lulzbot-TK-0

And I'm currently working on a FreeCAD assembly of the Prusa i3 Vanilla.



Off topic: I was able to import most printed parts directly from the .scad files. The OpenSCAD importer works very well!

[jrheinlaender]

For PartDesign its only save at the moment to refer objects (planes) inside the same body.
For revering outside geo we lack the tools at the moment. We need tools there which traverse the whole assembly tree and give the relative or absolute position to the Body the new sketch is in...

You have me confused. What is your concept of a Body and a Part? You are talking of Bodies inside the assembly, but in my understanding Bodies are in Parts (documents, as created in the PartDesign workbench) and Parts are in the Assembly. In that case I don't see problems with referencing features between Bodies providing they are in the same Part. Referencing Bodies in other Parts is not allowed in my PartDesign implementation at the moment.

Jan