Part, PartDesign and Assemblies

About the development of the Part Design module/workbench. PLEASE DO NOT POST HELP REQUESTS HERE!
Zolko
Posts: 208
Joined: Mon Dec 17, 2018 10:02 am

Part, PartDesign and Assemblies

Postby Zolko » Wed Jan 23, 2019 10:29 am

Hello,

this is a fork of another thread on this forum (Relevance of "Feature is not in a part" error message) because some very important points have been raised, and I would like to add my 2 cents. I hope I'm not too late to the party. Here are some relevant quotes:

abdullah wrote:
Sun Dec 09, 2018 1:14 pm
The other issue is that we have no clue yet, or at least I have no clue, how assemblies will look like. For example, whether they will operate on part containers or not. This could make what today is just seen as useless very valuable.
NormandC wrote:
Sun Dec 09, 2018 8:56 pm
The intent of ickby was clear in creating the Part container: it was supposed to be the basis for an assembly container.
ickby wrote:
Fri Dec 14, 2018 3:40 pm
So either someone writes down how it should be and alignment is created by discussion, or it will be settled by someone finishing the implementation that is just used afterwards.
abdullah wrote:
Fri Dec 14, 2018 3:58 pm
Now there is also realthunder's assembly branch.
First, I think it's very important to have 2 different containers, in a hierarchical level, one for bodies and one for parts. IMHO the FreeCAD developers have done it mostly right. The names might not be well chosen — easy confusion between Part and PartDesign — but the principle holds. A physical part can hold different bodies, either because the single part is made of different materials — look at your toothbrush — or because it's made with booleans, meaning that temporarily there are several bodies. So the higher level container will contain all those lower level containers, which in turn will contain atomic functions. Historically, calling them "Part" and "Body" seems like a good choice. If PartDesign was renamed BodyDesign, for example, it would lift some of the confusion.

But the most important part comes from the assemblies.

I have played with realthunder's App::Link implementation, and we managed to come up with a working solution for assemblies. I think it's a very practical and elegant solution, but it's not 100% what people imagine how assemblies should work in a traditional CAD system. You can see results here and here. It's very manual at the moment, a proper GUI would be necessary. This is not realthunder's Assembly3 workbench, it doesn't use it at all, but it uses realthunder's App::Link stuff. From what I understood, the Assembly3 is a demonstrator on top of App::Link. I think that merging the App::Link, with or without Asm3, should be a priority for v0.19

With trial-and-error, I think we have come a long way and can propose a well working assembly architecture. What I propose is that the App::Part be indeed the assembly container, that can contain either directly a PartDesign::Body, or several ones, to form a physical part, or App::Link links to other App::Parts and then it's an assembly. Can also hold Datum objects, Sketches, ... This is quite exactly how Siemens NX works, and quite unlike Catia V5. FreeCAD would be in the top-of-the best league. Additionally, each App::Part should contain a "Constraints" group to store constraints if it is used as assembly. Here is how the hierarchy would look like:

Code: Select all

Model (App::Part)              = Part or Assembly
  │
  ├─ Constraints (App::DocumentObjectGroup)
  │    ├─ PLM_Model2 (App::Placement)
  │    ┊
  │
  ├─ LCS_0                     ┐
  ├─ DatumPlane                │
  ├─ Sketch                    │
  ├─ LCS_1                     ├ references
  ├─ DatumAxis                 │
  ├─ LCS_2                     │
  ├─ ...                       ┘
  │
  ├─ Body (App::PartDesign)    = geometries
  │    ├─ Solid_1
  │    ├─ Solid_2
  │    ┊
  │
  ├─ Model2 (App::Link)        = another App::Part
  │    │
  │    ├─ Constraints
  │    ┊
  │    ├─ LCS_0
  ┊    ┊

And here in FreeCAD.

asm_Model.png
asm_Model.png (290.35 KiB) Viewed 1019 times

Files are attached for testing. They include my macros (they're only 1-liners mostly). I've put those macros in the toolbar to automate the process. This only works with realthunder's LinkStage3, there is a freshly released AppImage. All comments are welcome.
Attachments
Asm_Model.zip
(231.85 KiB) Downloaded 10 times
Zolko
Posts: 208
Joined: Mon Dec 17, 2018 10:02 am

Re: Part, PartDesign and Assemblies

Postby Zolko » Mon Feb 11, 2019 11:39 pm

Well, please hold back your enthusiasm, after the storm of silence following my initial proposal, I've still gone through with the idea, and you can now download some scripts from my GitHub account and try this out, and you can even have the luxury to read some explanations.
User avatar
dulouie
Posts: 71
Joined: Tue Oct 03, 2017 4:14 pm

Re: Part, PartDesign and Assemblies

Postby dulouie » Sat Feb 16, 2019 1:06 pm

I like the way you do assembies with LCS. It's the same concept as mate's on onshape.
Iit's a pity that there's not so much interest here. Assemblies are one of the major topics. Maybe it's the wrong subforum? Partdesign development has stopped and the audience here is small.
Brutha
Posts: 133
Joined: Mon May 04, 2015 1:50 pm

Re: Part, PartDesign and Assemblies

Postby Brutha » Sun Feb 17, 2019 12:26 pm

Hi,

Just to add my thoughts, since I had a bit of a play with Assembly 3 the other day.
What I propose is that the App::Part be indeed the assembly container, that can contain either directly a PartDesign::Body, or several ones, to form a physical part, or App::Link links to other App::Parts and then it's an assembly.
From my playing around, this seems exactly right, and would feel quite intuitive I think.

Cheers

Brutha