Assembly3 preview

Discussion about the development of the Assembly workbench.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
wsteffe
Posts: 461
Joined: Thu Aug 21, 2014 8:17 pm

Re: Assembly3 preview

Post by wsteffe »

realthunder wrote: Wed Jan 09, 2019 9:18 am You mean you want this to prevent accidentally deleting an element in lower assembly?
Regarding this point I would vote for link in the assembly. I do not like the idea that a part file changes just because somebody has included that part in an assembly.

Additionaly you have to consider that, as correctly pointed out by m.cavallerin, a part may be used in many assemblies and that each usage may refer to the same geometry in a different way or may refer to different geometries.

So in each assembly there should be a different set of link elements related to that part. When a linked geometry disappears each assembly should have the chance to readjust the associated element according to his needs without interfering with other assemblies. Therefore, in my opinion, this element should belong to the assembly and not to the part.
User avatar
saso
Veteran
Posts: 1920
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: Assembly3 preview

Post by saso »

Yes, but the best way is to have both. In assembly you set the "normal" links, I guess we could call them implicit, and in Part you set the "preferred" (explicit) linking elements, many cad programs have this for example Catia - Publication, NX - Product Interface,... (this is how I mostly see what asm3 elements should actually be) And they make the assembly more robust. But not to mix now this with asm3 links :)
Last edited by saso on Wed Jan 09, 2019 3:33 pm, edited 1 time in total.
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: Assembly3 preview

Post by Zolko »

saso wrote: Wed Jan 09, 2019 3:27 pm and in Part you set the "preferred" (explicit) linking elements, many cad programs have this for example Catia - Publication, NX - Product Interface,...
Amen to that: +1
try the Assembly4 workbench for FreCAD — tutorials here and here
wsteffe
Posts: 461
Joined: Thu Aug 21, 2014 8:17 pm

Re: Assembly3 preview

Post by wsteffe »

wsteffe wrote: Wed Jan 09, 2019 3:16 pm I would vote for link in the assembly
I have changed my mind. There is a third possibility which may be better:

The link would stay in the part file but they would belong to the referring assembly.
Each assembly would have a privare set of elements saved in the part file. He and only he would have the right to change and readjust his elements.
So nothing changes from with respect to my previous choice (elements in the assembly).

On the other side, it would be sufficient to have the part opened, for FC to recognize and warn against deletion of a geometry used in an assembly.
wsteffe
Posts: 461
Joined: Thu Aug 21, 2014 8:17 pm

Re: Assembly3 preview

Post by wsteffe »

saso wrote: Wed Jan 09, 2019 3:27 pm implicit, and in Part you set the "preferred" (explicit)
Ok implicit vs explicit links is important distinction which I also would like to see implemented. But this is different than what I meant.
I was speking about a link classification based on ownership which should grant to the assembly that created them the rights to change/readjust them.
User avatar
saso
Veteran
Posts: 1920
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: Assembly3 preview

Post by saso »

wsteffe wrote: Fri Jan 04, 2019 11:10 am Ok I may agree on that. But here the point is the mixing of history based modeling (which make use of sketches and related 2D constraints) with the 3D constrains of assembly module. In NX you may use 3D constraints to align a couple of faces. Then you may stretch the geometry containing the first face and by doing that you are stretching also an other geometry because the two faces must stay aligned.
But, before doing that, I you have to switch to the non ordered mode which deactivates the history tree.

Anyway I think that probably in FC the 3D constraints may coexist with the history tree because they can be used only the define relative positions of different bodies and not to deform the geometry as in NX.
Ok, this is going a bit back to the discussion about the constraints between the geometry in the Part and constraints between the Parts in the Assembly... I know what you mean, the thing is that this (constraining geometry in the Part) is indeed not the "normal" way of doing things, the "normal" workflow in the Part is to have everything mapped and fixed, for example you start from the origin, or set a point or an lcs and then you create an datum plan from it and a fully constrained sketch on that datum plane, and an extrude/pad from the sketch and a fillet on it,... so in the end everything is already fixed. So for example also in Catia, from what I know, this works only if you have some geometry that is not fully constrained, here is an example of this, and yes in Catia the sketcher constraints are used for this https://www.youtube.com/watch?v=QbQg52jV6uY

Personally I am not so much interested in this, but it is how I see the asm2+ and asm3 are already working so if we already have this, we could keep it, if we manage to make it work additionally to the more "normal" way :)
Last edited by saso on Wed Jan 09, 2019 4:25 pm, edited 3 times in total.
User avatar
saso
Veteran
Posts: 1920
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: Assembly3 preview

Post by saso »

wsteffe wrote: Wed Jan 09, 2019 3:40 pm The link would stay in the part file but they would belong to the referring assembly.
Each assembly would have a privare set of elements saved in the part file. He and only he would have the right to change and readjust his elements.
I am not sure I like the idea of the Assembly file continuously making changes to its Part files for probably no good reason :| A database storage instead of files is the way to go for this, as you have said and there have also been discussion in the past about this. Also In FC we want to keep the current ability to be able to do the complete project inside a single file (additionally to be able to save every Part to each own file), so in this case when you have everything inside one file it should also not be a problem.
User avatar
saso
Veteran
Posts: 1920
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: Assembly3 preview

Post by saso »

realthunder wrote: Sun Jan 06, 2019 9:41 am
saso wrote: Sun Jan 06, 2019 9:08 am Lets get back to the programming analogy and say we are talking about implementing a class, and that the PDN Part is an implementation of the class that is somewhat ok but does not support private members and your implementation of the class now adds this, this is still a class and for the time of testing we can have both but eventually one will have to be removed. And if you don't think that PDN Part should be removed, then we should fix it and not be creating new ones.
Ah, this. I wrote asm3 workbench to prove that my Link implementation is ideal for use with assembly/part, and that App::Part is lacking critical function. The upstream hasn't response to my opinion yet. I can't just remove App::Part right now.

And this is also why this, where the "linking structure", instead of the "part/assembly containers", is used for the imported step also makes absolutely no sense to me.
Similar reason as above, asm3 is currently an external python only workbench. It is not in FC source tree, while the STEP importer is inside source tree, so it cannot use asm3 container. The container used there is called LinkGroup, which is also used to implement the asm3 container.

The whole situation all comes down to the fact that I am still waiting for upstream to review my branch.
I understand and I think it is ok for now that we are still testing different implementations, what I wanted to say was only that eventually we will have to make a decision, I really don't think that it would be good or make sense to just continue with all this different ways of doing the same thing. Also I wanted to show that I am not in any way attacking you or your work with my arguments, I am just trying to find a way how it would work and make sense to me.
User avatar
saso
Veteran
Posts: 1920
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: Assembly3 preview

Post by saso »

Just a note to make the picture more complete, beside A2+ and A3, Yorik is in his BIM WB also implementing a version of a "Part container" and x-ref (external file linking)...
wsteffe
Posts: 461
Joined: Thu Aug 21, 2014 8:17 pm

Re: Assembly3 preview

Post by wsteffe »

saso wrote: Wed Jan 09, 2019 4:22 pm I am not sure I like the idea of the Assembly file continuously making changes to its Part files for probably no good reason
I think it could be acceptable if the the data/elements which may be changed by assemblies are kept well separate from part data.

One possibility could be to have a small database that is associated with the part file and stored in a separate file.
This database would always be loaded when the part file is loaded by PartDesign module which could have only read permission because it just need top know if a goemetry is used by an assembly to prevent accidental deletion. The database should be loaded by an assembly importing that part and in this case with read/write access limited to his private region of data.

That solution would preserve/assure:
1) Invariance of the part file
2) Locality of the data: no need of a company-wide database.
3) Safety against accidental removal of shared data in a part file.
Post Reply