Assembly3 preview

Discussion about the development of the Assembly workbench.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
ceremcem
Posts: 226
Joined: Sun Jan 07, 2018 11:10 am

Re: Assembly3 preview

Post by ceremcem »

wsteffe wrote: Tue Jan 08, 2019 2:31 pm I think that the maintainers of FreeCAD projects are free to merge the LinkStage3 branch. It is just that they don't want.
Realthunder asked to evaluate the possibility of this merge more than 6 moths ago (30 June 2018) and I do not have yet seen any reply from the main the FreeCAD project leaders.

So I do not think that it would be a good idea stopping the development of ASM3 branch to wait for a merge which probably will never happen.
I totally agree. However, @realthunder hasn't stopped (or even slowed down) development of Asm3 until it's been reviewed. He's been adding features (the Python interpreter is the killer one, IMO), fixing his and the upstream's bugs. What I understand is that he says his branch has to be reviewed in order to perform the possible replacements (Parts with Assembly containers and such).


Regarding the keeping track of references in either main assembly file or the part files: It's technically impossible to properly design/manage a re-usable library infrastructure if you stick with modifying the dependencies (the part files) regarding to their use places. You would never change a library code when you use the library in your code, would you? KiCAD has tried that and obviously failed.
m.cavallerin wrote: Wed Jan 09, 2019 10:40 am
You mean you want this to prevent accidentally deleting an element in lower assembly? That does make some sense. Let me think about it.
Yes exactly!
If I correctly understand the problem, it's a problem of breaking change in the library part. If you are the author of PART_A and use it both in PRODUCT1 and PRODUCT2, then delete something in PART_A while you are working on PRODUCT2, then PRODUCT1 becomes broken. Is that correct? If yes, I'll continue my proposal.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Assembly3 preview

Post by triplus »

Nice discussion conducted in the past couple of days. More of that for sure will help progress things further a bit faster. Note that there are likely further considerations involved, on the long run:

Image

https://forum.freecadweb.org/viewtopic. ... 20#p279148

Such assembly structure is rather standard for PartDesign oriented use cases. Areas like architecture, transportation ... likely won't be able to cope with such approach directly. But i do imagine would like to use some FreeCAD assembly, Link, LCS ... capabilities. Therefore underneath all this PartDesign focused discussions, there should still be some generalization going on.

As for bringing Assembly 3 closer to FreeCAD upstream. More will need to be done on all sides. To break the ice i would suggest a PR to emerge early in FreeCAD 0.19 development cycle, addressing core Link functionality:
Link.png
Link.png (21.4 KiB) Viewed 2267 times
In my opinion there was a chance FreeCAD 0.18 would already be Link enabled, but that didn't happen, due to various reasons involved. Hopefully in FreeCAD 0.19 development cycle we will be able to tackle it and make FreeCAD 0.19 Link enabled.
m.cavallerin
Posts: 115
Joined: Wed May 30, 2018 6:59 pm

Re: Assembly3 preview

Post by m.cavallerin »

Hi,

I had a quick reading at other discussion and I found out that skilled people are already working on that, so I quit about proposal about programming, but I'm glad to see that this is a MUST for the development of FC.

May I suggest that in further high level discussion about this topic would be that FreeCAD can't withstand to be too much "open-minded" needs for everyone?

My feeling is that FreeCAD has to finally make the "big jump" and to choose where to stay: merging branches that cover similar topic?

Thanks to all developers for all the work.

Regards.

Michele.
User avatar
bill
Posts: 376
Joined: Fri Jan 09, 2015 9:25 pm

Re: Assembly3 preview

Post by bill »

ceremcem wrote: Wed Jan 09, 2019 9:09 pm Regarding the keeping track of references in either main assembly file or the part files: It's technically impossible to properly design/manage a re-usable library infrastructure if you stick with modifying the dependencies (the part files) regarding to their use places.
Limited changes/editing a part in a sub-assembly should be possible as long as one doesn't violate a CONSTRAINT, which is effectively a part-to-part-to-assembly interface control (physical) definition; No? This is why in a purely LCS-defined assembly environment it is a limit; I would think. Simply position does not provide this benefit.
User avatar
OakLD
Posts: 131
Joined: Fri Jan 12, 2018 7:38 pm
Location: Brno

Re: Assembly3 preview

Post by OakLD »

I read the discussion along and I wonder, why is the link information stored in part files and not the assembly file? There has to be a serious reason for that, for it's not the standard way to design such data structures. If I understand correctly the last post, this is because there's an attempt to change a link if there is a change in it's part file affecting the link? This would make a sense to me.

I think (guessing from behavior) that all 3D CAE SW I ever worked with store the information in the assembly file (which in all cases was also a file with a structure different from part, which is not the FC concept) and on openning they performed a check and in case of troubles they interact with the user on resolving them. Those CAE store design history in the part (FC tries to do the same, I believe).
From the code point-of-view, if you have the proper history information, you can then perform the very same action on the links in the assembly at the time of openning it, compared to the ASM3 approach, where youn do the action at the moment of changing the part and affecting the link at the "same" time.

I'm not trying to say which way is better, for I have too little insight in the code. But perhaps we should know the idea behind the design.

I also wonder, what is the reason for the need of all component parts being opened with the assembly? We discussed that a bit about 60+ pages back and I think Realthunder said it will be eventually got ridden of, but what is this caused by? I'm suspecting that the links stored in part file might be partly the reason, but still, this wouldn't prevent you to read the compnent files (or better, their relevant fractions, without history and such) into the memmory and work from there (without cluttering the user's workspace, the tree).
I think it's OK for development, but a show-stopper for a finished Assembly WB. Just with my mid-sized assemblies during testing of the last release, I had often some 30+ files opened and it's already a mess...
Regards,

Oak
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Assembly3 preview

Post by realthunder »

OakLD wrote: Thu Jan 10, 2019 9:18 pm I think it's OK for development, but a show-stopper for a finished Assembly WB. Just with my mid-sized assemblies during testing of the last release, I had often some 30+ files opened and it's already a mess...
When you finished working with a lower level part/assembly, you can freeze it, so that its children parts in external files are no longer needed when used in higher level assembly. Once frozen, the part/assembly cannot create any new elements. You should define interfacing elements before freezing, but you can also make later amendment by simply unfreeze it. See here for an example. It is a 16-file-assembly. Once the parts at the top level assembly are frozen, the next file open only loads 4 files.

The latest AppImage already has this feature, but not the context menu option. You can manually change the "Freeze" property of an assembly.

Now, this is one of the benefit of storing the element link information inside a part rather than the assembly. The element of a "Part" is an abstraction of the actual geometry used by upper "Assembly" for constraining. That geometry may come from even lower level "Part". When a "Part" is frozen, its lower "Parts" will not be loaded next time, so the original geometry information is not there. But thanks to element abstraction, upper "Assembly" can work just fine.

The other benefit is that for any geometry element missing problem, the damaging effect is localized. Say you unfreeze a "Part" and find out that one of the element in its lower child "Part" is missing. You don't need to change anything in this unfrozen "Part", or any of its higher "Assemblies". Just fix the lower child, and everything will back to normal.

The real problem raised by m.cavallerin that caught my attention is when the user accidentally delete an element in the child "Part" and cannot remember which geometry element it is supposed to link to. If there are intermediate elements, then it contains a local copy of the geometry which can server as a reminder to the user of the missing element. But if there is only two levels of assemblies, and level one element is gone, no geometry information is left, and the user may be lost.
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
wsteffe
Posts: 461
Joined: Thu Aug 21, 2014 8:17 pm

Re: Assembly3 preview

Post by wsteffe »

realthunder wrote: Fri Jan 11, 2019 12:44 am you can freeze it, so that its children parts in external files are no longer needed when used in higher level assembly. Once frozen, the part/assembly cannot create any new elements.
In most other commercial CAD (I am sure about Catia but I think that also other work in the same way) you do not need to open the part/sub-assembly file in order to add a contraint on it. In my view the fact that in FC, you may not do that (when the new constraint involves the creation of a new element) is a strong penalization which is not acceptable even if it brings the localization benefit mentioned here:
(
realthunder wrote: Fri Jan 11, 2019 12:44 am The other benefit is that for any geometry element missing problem ...
.

Regarding the first benefit:
realthunder wrote: Fri Jan 11, 2019 12:44 am When a "Part" is frozen, its lower "Parts" will not be loaded next time, so the original geometry information is not there. But thanks to element abstraction, upper "Assembly" can work just fine.
I think it is simply not true this benefit is brought by the ASM3 choice of "storing the element link information inside a part". It is the opposite because: 1) also in Catia (which stores links in the assembly) the assembly works well when the parts are not opened ("opened" to me is the same as "loaded" but please correct me you think that there is a difference). 2 In Catia it works even better and you may add constraints/links without defreezing anything.
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Assembly3 preview

Post by realthunder »

wsteffe wrote: Fri Jan 11, 2019 9:00 am In most other commercial CAD (I am sure about Catia but I think that also other work in the same way) you do not need to open the part/sub-assembly file in order to add a contraint on it. In my view the fact that in FC, you may not do that (when the new constraint involves the creation of a new element) is a strong penalization which is not acceptable even if it brings the localization benefit mentioned here:
Okay, Catia can create a constraint on a part in a separate file without loading it, so how does Catia assembly knows about the Parts geometry? Does It store the part's geometry inside the assembly? That's very unlikely. The fact that there is no UI showing the Part is loaded, does not mean the application did not read the file.

Remember that A3 allows you to use any feature as constraining element, even historical feature in a body, a sketch, or datum. Without loading a part, how can an assembly know the geometry information about those "internal" features? The Elements declared in the "Part" are to publish those features. Once a Part is frozen, it will not load those "internal" feature next time, and it is those elements that provide upper assembly with the geometry information.

Besides, please remember that A3 does not only store link information inside a Part, the assembly constraint contain links too, and it is stored with the assembly. It is like a plug and socket. The plug is the element link under constraints stored inside assembly, and the socket is element declared inside a part.
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
Jee-Bee
Veteran
Posts: 2566
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: Assembly3 preview

Post by Jee-Bee »

realthunder wrote: Fri Jan 11, 2019 9:20 am Okay, Catia can create a constraint on a part in a separate file without loading it, so how does Catia assembly knows about the Parts geometry?
No it load when adding it. You don't need to have it open in a seperate window that's all
Jee-Bee
Veteran
Posts: 2566
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: Assembly3 preview

Post by Jee-Bee »

see example video of ptc Creo: https://www.youtube.com/watch?v=EOjLyJf3-FE
Post Reply