Assembly3, A2plus, Assembly4? Get united!

Discussion about the development of the Assembly workbench.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Assembly3, A2plus, Assembly4? Get united!

Post by realthunder »

bambuko wrote: Sat Jul 10, 2021 3:48 pm If it were not to be adopted as a "chosen solution", what would this mean for the work I have done until now?
I realise that all three assembly workbenches are not official and are really "experimental", but to be honest I am using Assembly 3 as a working tool and not as an experiment to play with, so would hate to suddenly find that my models no longer work with the latest version of FreeCAD :oops:
Well, just consider how much effort I've spent and am continuously spending on developing FreeCAD, I think you are on the safe side ;)
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
bambuko
Veteran
Posts: 2160
Joined: Thu Oct 24, 2019 12:53 pm
Location: UK, England, North Devon

Re: Assembly3, A2plus, Assembly4? Get united!

Post by bambuko »

Zolko wrote: Sat Jul 10, 2021 4:38 pm ...
Thank you for detailed reply (and sympathies ;) )
As a user (rather than a contributing developer) I do realise that I get what what I "pay for" and I am full of respect for what you guys are doing - thank you!
I am also quite well aware that my choices leave me totally dependent on one guy - I know I've made a right choice (for me), but it is possibly more vulnerable position when compared with a team supporting main branch?
I am not suggesting that development should be driven by my concerns - just trying to understand what the risks and consequences of my choice are.


realthunder wrote: Sun Jul 11, 2021 7:06 am ... just consider how much effort I've spent and am continuously spending on developing FreeCAD, I think you are on the safe side ;)
I have no doubt about my choice (and your commitment) - big thank you!
I am using Link branch and Assembly3
you can also download ... and try it here
excellent Assembly3 tutorials here
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: Assembly3, A2plus, Assembly4? Get united!

Post by Zolko »

chrisb wrote: Sat Jul 10, 2021 10:52 pm
Zolko wrote: Sat Jul 10, 2021 3:03 pm I think that the main problem is data structure, more than pure functionality.
Fully agreed!
thank-you. So I will go a step further in describing this:

An assembly shall be a standard App::Part (Std_Part) with, may-be, some additional properties/goodies. One particular such goodie shall be a group (App::DocumentObjectGroup) called "Constraints", to store all the constraints between elements of the assembly. This is how SolidWorks behaves also.

BUT: because a name must be unique in a FreeCAD document, there can only be 1 unique Constraints group. Meaning that there can be only 1 assembly container in a FreeCAD document, whereas there can be multiple App::Parts. Therefore, this would impose an artificial limitation ... but which is ALSO the situation in all other CAD software : no existing CAD system allows to have multiple assemblies in a single file. This means that this limitation is actually an industry-wide practice, so no practical limitation at all.

EDIT: actually, I'm not sure about this

To enforce this uniqueness, I propose to give the App::Part that is meant to be an assembly a special name, at creation time: this would make it impossible to create another assembly in the same file. Asm4 calls this particular App::Part "Model" but we could choose another name ("Assembly" ? Thinking of it, calling it "Assembly" makes more sense than "Model".). We could even change the ViewProvider for the App::Part that it returns a different icon if its name is that particular chosen name.

An Assembly (of type App::Part = Std_Part) would then automatically contain a group called Constraints at its root, and anything else that a standard part can contain, including other standard Parts, but also PartDesign Bodies. It can ALSO contain links (App::Link) to other App::Part containers, thus forming nested assemblies, but also to PartDesign::Body containers forming regular parts.

In this way, a FreeCAD file could have many Parts and Bodies per file, but only 1 Assembly. All objects parts in this assembly shall have a property called "AssemblyType" set "to Part::Link" which indicate ... hold, no, that doesn't work. The assembly object - App::Part - shall have this property added, so that it can be checked that it's of the correct type if it itself included into a higher level assembly. All parts within the assembly shall have then a property called SolverId, that tells what solver to use. For Assembly4 I propose to set it to "Placement::ExpressionEngine".

This data structure would closely ressemble to other main CAD software, like NX, where an assembly can contain parts but also sketches and datum objects. It would be better than what Catia V5 offers. BUT, VERY IMPORTANT: FreeCaD would offer a possibility that no other CAD package can do: assemblies in 1 file, where the main assembly and its sub-parts are in 1 file, all the while being a regular assembly with multiple instances of the same parts.

To summarise: a FreeCAD assembly is a standard App::Part called "Assembly" having a PropertString added called AssemblyType and set to "Part::Link", and shall have a goup called "Constraints".

Code: Select all

def makeAssembly():
    assembly = App.ActiveDocument.addObject('App::Part','Assembly')
    assembly.Type='Assembly'
    assembly.addProperty( 'App::PropertyString', 'AssemblyType', 'Assembly' )
    assembly.AssemblyType = 'Part::Link'
    assembly.newObject('App::DocumentObjectGroup','Constraints')
makeAssembly.png
makeAssembly.png (265.26 KiB) Viewed 2943 times


and for each object inserted into the assembly that should be placed by some solver:

Code: Select all

obj.addProperty( 'App::PropertyString', 'SolverId', 'Assembly' )

If this property is not set or empty, it has a free/manual placement.

kbwbe wrote:ping
Do you think that this assembly data structure could be compatible with the A2+ solver ? We could parse the assembly tree, and each time we encounter a part with SolverId set to "A2+" (or whatever) we fetch the corresponding constraints from the Constraints group, all other parts being considered fixed, and then launch the A2+ solver.

realthunder wrote:ping
Would it be possible to adapt the Assembly3 workbench to use this data structure ?
try the Assembly4 workbench for FreCAD — tutorials here and here
User avatar
jonasb
Posts: 162
Joined: Tue Dec 22, 2020 7:57 pm

Re: Assembly3, A2plus, Assembly4? Get united!

Post by jonasb »

Zolko wrote: Sun Jul 11, 2021 11:14 am An assembly shall be a standard App::Part (Std_Part) with, may-be, some additional properties/goodies.
This is also a thing I really like on Asm4: Using what's there and making the best of it.
I've followed quietly the few discussions that took already place around this topic and I fully agree with this position.
Zolko wrote: Sun Jul 11, 2021 11:14 am ... One particular such goodie shall be a group (App::DocumentObjectGroup) called "Constraints", to store all the constraints between elements of the assembly.

BUT: because a name must be unique in a FreeCAD document, there can only be 1 unique Constraints group. Meaning that there can be only 1 assembly container in a FreeCAD document, whereas there can be multiple App::Parts. Therefore, this would impose an artificial limitation ... but which is ALSO the situation in all other CAD software : no existing CAD system allows to have multiple assemblies in a single file. This means that this limitation is actually an industry-wide practice, so no practical limitation at all.

EDIT: actually, I'm not sure about this

To enforce this uniqueness, I propose to give the App::Part that is meant to be an assembly a special name, at creation time: this would make it impossible to create another assembly in the same file. Asm4 calls this particular App::Part "Model" but we could choose another name ("Assembly" ? Thinking of it, calling it "Assembly" makes more sense than "Model".). We could even change the ViewProvider for the App::Part that it returns a different icon if its name is that particular chosen name.
Here I do not agree (as of now; maybe I just miss some deeper understanding).

Why do we need this "artificial limitation" and an imposed naming? I very much like the ability to have single-file assemblies. And it would be very handy, too, to have more than one in a single file, e.g. to nest them: Imagine I design a little cabinet. I'd like the main assembly/Part named "Cabinet", not "Model". Then I'd like to design the hinge as assembly too (named "Hinge"), and use three of them in the "Cabinet". Sure, the more complex the model gets, the better is the multi-file approach. But this is a choice I'd like to take as the designer.
From a user's perspective, I don't see why it should be possible to have the sides, top, button and shelfs together with the assembled Cabinet in the same file, but the hinges must be separate. Or, in order to have them in the same file, the hinges must not be pre-assembled but build from ground up three times.

So, speaking about a general data structure for assemblies: It's ok (all though sad) if the Asm4 WB makes the decision to only allow single-level assemblies in a single file. But this should not be imposed by the underlaying data structure. This would mean no other assembly mechanism could ever implement this in the future. Or it has to invent it's own data structures again, but this is the situation we're trying to solve, right?
In my eyes, a certain workflow may be imposed by the tooling. Imposing it though the underlaying data structures may bite you later.
Zolko wrote: Sun Jul 11, 2021 11:14 am All objects parts in this assembly shall have a property called "AssemblyType" set "to Part::Link" which indicate ... hold, no, that doesn't work. The assembly object - App::Part - shall have this property added, so that it can be checked that it's of the correct type if it itself included into a higher level assembly.
Isn't this enough to recognise a Std::Part as assembly? I mean, if it has a property "AssemblyType", then why do we need to impose a special name (like "Model" or "Assembly")? Why do we need to limit a single Std::Part per file to have this property?

Same for the constraints: If a certain solver needs those (e.g. Asm4 does not, AFAIK) I would prefer if that solver sets them up as needed, e.g. using a group with a solver-specific property like "A2Plus_ConstraintsContainer=True".
However, I must confess that I have not put my nose deeper into constraint-based assemblies like A2+ or Asm3.

I could also imagine other more specialised "solvers" that place the parts under their control more directly, e.g. some hypothetical Stemfie-solver, a Lego- or Brio solver, ...
Zolko wrote: Sun Jul 11, 2021 11:14 am All parts within the assembly shall have then a property called SolverId, that tells what solver to use. For Assembly4 I propose to set it to "Placement::ExpressionEngine".

[...]

Do you think that this assembly data structure could be compatible with the A2+ solver ? We could parse the assembly tree, and each time we encounter a part with SolverId set to "A2+" (or whatever) we fetch the corresponding constraints from the Constraints group, ...
When not imposing a single group with a special name (see above), the respective solver would be responsible to finding what ever it needs in addition. E.g. looking for a group with the property "A2Plus_ConstraintsContainer=True".
Zolko wrote: Sun Jul 11, 2021 11:14 am ... all other parts being considered fixed, and then launch the A2+ solver.
I think this part of the proposal works only when working with time-invariant solvers. However, when time variant solvers come into play (e.g. from the "Dynamics" BW using MBDyn), I think we need some hierarchy of executing the solvers. Or just assemble first using the static solvers, then fire up MBDyn. I cannot imagine more than one dynamic solver at the same time anyway.
josegegas wrote: Tue Jun 01, 2021 3:36 am ping
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Assembly3, A2plus, Assembly4? Get united!

Post by chrisb »

I agree that we should not impose restrictions on the level of the data structure. It doesn't seem wrong to have multiple assemblies in the same file.
It is a different question if such a feature is sensible to be used.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: Assembly3, A2plus, Assembly4? Get united!

Post by Zolko »

jonasb wrote: Sun Jul 11, 2021 8:20 pm
Zolko wrote: Sun Jul 11, 2021 11:14 am BUT: because a name must be unique in a FreeCAD document, there can only be 1 unique Constraints group. Meaning that there can be only 1 assembly container in a FreeCAD document, whereas there can be multiple App::Parts. Therefore, this would impose an artificial limitation
Here I do not agree (as of now; maybe I just miss some deeper understanding).
...
Why do we need this "artificial limitation" and an imposed naming?
1) education and best industrial practices. If - it's a big IF - we want to attract Universities to use FreeCAD, we can only do it by adopting general industry practices. If all other CAD systems have only 1 assembly per file, we should do the same.

2) coding inconvenience: hard-coding stuff is much easier than having multiple options with the corresponding error checking. Since FreeCAD is limited in contributor time, we should go for the easiest solution

3) This being open source, please make your own proposals. Talk is cheap.
try the Assembly4 workbench for FreCAD — tutorials here and here
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Assembly3, A2plus, Assembly4? Get united!

Post by chrisb »

Zolko wrote: Sun Jul 11, 2021 11:12 pm Since FreeCAD is limited in contributor time, we should go for the easiest solution
I dare to contradict: No compromises with the data structures. An assembly workbench doesn't have to handle everything and if it is easier or due to other reasons necessary to limit things, so be it, but the data structure should be clear. That's what I understood is your intention too.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Assembly3, A2plus, Assembly4? Get united!

Post by adrianinsaval »

Zolko wrote: Sun Jul 11, 2021 11:14 am BUT: because a name must be unique in a FreeCAD document, there can only be 1 unique Constraints group. Meaning that there can be only 1 assembly container in a FreeCAD document, whereas there can be multiple App::Parts.
Why make the name of the group the defining factor? an additional property could be added: constraintGroup=true to differentiate a regular group from a constraints group, and error is thrown when the wb tries to parse a Part container with more than one group with constraintGroup=true in the same level (except assembly 4 that doesn't care if I'm not mistaken). I don't think it's sensible to limit to only one assembly in the same file, what about nested assemblies? I get that you would usually use links but it's not unthinkable to make a nested assembly in the same file.
Overall, I like your ideas Zolko and I think your going in the right direction, this is what is needed to start converging.
jonasb wrote: Sun Jul 11, 2021 8:20 pm Why do we need this "artificial limitation" and an imposed naming? I very much like the ability to have single-file assemblies. And it would be very handy, too, to have more than one in a single file, e.g. to nest them: Imagine I design a little cabinet. I'd like the main assembly/Part named "Cabinet", not "Model". Then I'd like to design the hinge as assembly too (named "Hinge"), and use three of them in the "Cabinet".
He most likely means the internal name, you would be able to name your assembly whatever you like for the displayed name.
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Assembly3, A2plus, Assembly4? Get united!

Post by chrisb »

Just for my better understanding: If an assembly is a special Part, then it can be used not only in other assemblies, but also for boolean operations as well? That makes it very powerful.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
easyw-fc
Veteran
Posts: 3629
Joined: Thu Jul 09, 2015 9:34 am

Re: Assembly3, A2plus, Assembly4? Get united!

Post by easyw-fc »

Zolko wrote: Sat Jul 10, 2021 3:03 pm But it all begins by saying that assembly containers are FreeCAD core App::Part (Std_Part) objects. This is actually also compatible with the Manipulator WB (I think).
It should work...
I didn't test intensively because I don't use often Assemblies a part the one from kicadStepUp... but there I use Part and Links so it should be compliant.
Post Reply