Assembly3, A2plus, Assembly4? Get united!

[jpg87]

To

...

...

...

and others !

First of all I must warn that as a simple user who understands nothing about internal problems in software programming, all terms like "App :: Standard Part, App :: DocumentObjectGroup, ..." are totally foreign to me.
However, I still believe that the opinion of ordinary users cannot be completely overlooked.

Since each user has their own story and their own habits, what I say below is only my opinion.
When I started using the 1st FreeCAD assembly workbench (A2 if I am not mistaken), I was very satisfied to find the habits I had acquired in other software (Solid Concept, Solid Edge , Catia V5, Solid Works): the direct pointing with the mouse of surfaces or other geometric entities and the use of geometric constraints, to remove step by step different DOFs between objects, in order to build kinematic chains in mechanisms.
Unfortunately the development of this workbench was at a standstill.

Subsequently, I discovered the Realthunder Assembly 3 workbench, which offered the same type of constraints. I was very quickly won over.
From my point of view, this is a very dynamic approach (a few clicks or drag-and-drop) which allows you to quickly set up constraints without any preparation if desired, or with some more rigorous preparations for a result to keep, but with an almost kinesthetic approach.

Then came Assembly 4 workbench from Zolko, which proposed to no longer use a solver. Why not ? I admit that this approach would suit me more for static positioning of parts (although you can create mechanism animations) than for articulated mechanisms.

I still think that these are two approaches that can be complementary, and that it must remain in the order of the user's choice. So a FreeCad file "should" (easy to say for someone incapable of programming !) :
- be able on reading the file to detect whether it contains information requiring the use of a solver and to ask if the user wishes to continue in this way;
- be able to make inactive all the constraints related to the user of a solver by temporarily conserving (optional) the relative positions of the objects (which already happens in Assembly 3);
- be able to make all the positions linked to Assembly 4 inactive (while also temporarily keeping the relative positions of the objects as an option) if the user prefers to use an assembly by geometric constraints.

For the use of future tools (which I strongly hope for) such as kinematics and dynamics analyzers with construction of curves of positions, speeds, accelerations, efforts ... I would personally prefer an approach based on geometric constraints like in Assembly 3.

PS: I can not find any reason to have in a file only one assembly.

[Zolko]

So a FreeCad file "should" (...) be able on reading the file to detect whether it contains information ...

here lies the problem: FreeCAD cannot read A2+ and Asm3 files natively. All your remarks are valid, but are useless if you can't read the file to begin with.

When I started using the 1st FreeCAD assembly workbench (A2 if I am not mistaken), I was very satisfied to find the habits I had acquired in other software (Solid Concept, Solid Edge , Catia V5, Solid Works)

PS: I can not find any reason to have in a file only one assembly.

do these other CAD systems allow more than 1 assembly per file ? What about A2+ and Asm3 ? It's a genuine question, I had never seen it, but it might be possible.

[drmacro]

I apologies upfront if I've not followed enough of this diligently...

By 2 assemblies in one file.

Do you mean like, one file that includes an assembly of a Boeing 747 and an assembly of a Airbus A320?

Or an assembly of a Boeing 747 with all it's sub-assemblies?

[Zolko]

By 2 assemblies in one file... Do you mean ...

good catch: I mean both cases.

BUT: what is an assembly ? If you consider nested App::Part then it's already possible today. What I mean by "assembly" is an App::Part that also contain links (App::Link) to other objects. That's what I meant by :

Code: Select all

assembly.AssemblyType = 'Part::Link'

So there shouldn't be any limit on nested parts, but only 1 that can contain links. The point is: once we accept a property AssemblyType, nothing prevents some people to implement other types ... as long as they set this flag properly

[chrisb]

what is an assembly ?

An assembly could be seen as something similar to a Boolean operation: It takes some objects and creates a new object out of them. It is of course more complicated than a boolean, because the additional information about how to assemble has to be considered as well.

[Zolko]

what is an assembly ?

An assembly could be seen as something similar to a Boolean operation: It takes some objects and creates a new object out of them.

SolidWorks opposes assemblies and multi-body parts:

https://blogs.solidworks.com/tech/2014/ ... works.html

This assembly contains 19 parts, some unique, some with multiple instances. As an assembly, this results in several files that need to be managed. 1 for the assembly and 1 each for the unique part files within this assembly.

So for me an assembly is when 1) you have links to other parts; links because you can have many instances of the same part, therefore they can't be copies (or clones). And 2) the placements of these parts, relative to each other and to the main assembly, is dynamic/relational, and not manual/fixed. Meaning that if 1 part is changed, the objects that depend in it are updated too.

[realthunder]

SolidWorks opposes assemblies and multi-body parts:

https://blogs.solidworks.com/tech/2014/ ... works.html

The reason why those CAD limits one assembly per file (at least for SW here) is because they have different types of files, each has a different internal structure for their purpose. But FreeCAD Document has a general file format that is designed to hold any type of objects. You can think of other CAD's assembly file as the assembly object in FreeCAD.

The quoted SW article talks about the difference of assembly and multi body part is mainly about how they track their child components. For an assembly, the components will be instances of other Parts or sub-assemblies. For a multi body part, they are bodies. Now, the difference in tracking child components also exists in FreeCAD, and it was actually the source of my complaint back when I started to work on App::Link. PartDesign Body is in fact designed like a Part in other CAD, which imposes various restrictions on the link scope of child components, hence, the infamous link out of scope warning message in FreeCAD. In FreeCAD, the link scope restriction logic is implemented in App::Part (actually GeoFeatureGroupExtension, but let's just simplify things a bit for the sake of discussion), and PartDesign Body inherits the logic from it. Here is where the problem is. FreeCAD also wants to use App::Part as an assembly container, but an assembly is not supposed to track its child components the same way as a Part. An assembly does not require exclusive ownership of its child (actually grandchild to be more specific) components, which are meant to be reused in other container. That SW article explained the difference in tracking in more details, just that when you read about the term 'file', think of a corresponding type of 'object' in FreeCAD.

Anyway, after I've developed App::Link, the main problem with App::Part as an assembly container can be worked around, with a little overhead, so no real problem for me there.

[adrianinsaval]

do these other CAD systems allow more than 1 assembly per file ? What about A2+ and Asm3 ? It's a genuine question, I had never seen it, but it might be possible.

I think CATIA doesn't, but here this is an unnecessary artificial limitation, just like the single body rule in PD, it gives no actual benefit but only drawbacks in order to make everyone follow the developer's philosophy and preferred way of doing things.
As other's have mentioned, this limit is not needed with FreeCAD's very flexible document structure, the strict separate document types of those software is probably what make them do that.

[adrianinsaval]

FreeCAD also wants to use App::Part as an assembly container, but an assembly is not supposed to track its child components the same way as a Part. An assembly does not require exclusive ownership of its child (actually grandchild to be more specific) components, which are meant to be reused in other container. That SW article explained the difference in tracking in more details, just that when you read about the term 'file', think of a corresponding type of 'object' in FreeCAD.

Anyway, after I've developed App::Link, the main problem with App::Part as an assembly container can be worked around, with a little overhead, so no real problem for me there.

Do you think is worth adding a special generic assembly container in main FreeCAD and the external assembly workbenches would adapt to it?

[Zolko]

Anyway, after I've developed App::Link, the main problem with App::Part as an assembly container can be worked around, with a little overhead, so no real problem for me there.

great news. So we can try to make the App::Part as assembly containers converge. When creating an assembly in Asm3 and Asm4, I get the following

Asm3.png (205.48 KiB) Viewed 2714 times

Asm4.png (208.3 KiB) Viewed 2714 times

You specify a solver for the assembly, but I think it should be specified at the components level. Some people might have their own physical solver for their problem, and would like to use FreeCAD for 3D illustration. In this case, they will use their solver for the main components, but will add secondary parts (like screws) for illustration: these will then use built-in solvers.

What do you think ?

(BTW: I couldn't figure out how to add parts into the assembly)