I will agree the desirable ultimate outcome is that we have assembly capabilities with a solver by default, but this does not mean that we can't have one without it as a first step.
The need for a default assembly workbench
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
Be nice to others! Read the FreeCAD code of conduct!
- adrianinsaval
- Veteran
- Posts: 5548
- Joined: Thu Apr 05, 2018 5:15 pm
Re: The need for a default assembly workbench
Fixing broken links is feature that in reality is independent of any assembly wb, I'm not saying is not a good idea but is not really needed for assembly and it neither needs an assembly wb to be implemented.
Re: The need for a default assembly workbench
That have nothing to do with assemblies.
Greetings
user1234
Re: The need for a default assembly workbench
It totally has if I intend to use them as the main method to attach parts to each other.
See it this way, it is common in some companies to prefer attachments only to the first coordinate system's elements in the tree (the most stable one at the top of the tree), but if such a coordinate system is able to move in space, the idea of "stable" turns into a matter of trust in the CAD operator from whom you received a file.
Take in count that a .FCStd file in an assembly may turn into a subassembly later on, if for X reason a local C.S. is not aligned to the global C.S. trouble may happen. And it might turn into a big trouble if a have to check into a very packed assembly why there is a misalignment and distrust every file I receive because of a misplaced C.S.
Re: The need for a default assembly workbench
Having just coded an assembler for my BodyBuilder macro, I see this:
An assembler is made of two separate things:
1) The GUI code that allows the user to select/adjust objects to attach.
2) The engine I will call it, it would be the code that runs every time the assembly is modified and objects move.
I would then come up with two test assembly models:
1) A 20 piece static model,
2) A simple dynamic model, maybe a lever with a bucket, something like that.
I would count how many mouse clicks, keyboard smacks and also get some idea of build time for the two test assemblies. Let the most experienced build the assemblies to gauge how fast an assembly is built. This is so-so important because the GUI could be simplified later.
I would ask of the Assembler developer if they could containerize the engine (that runs at assemble change), this would show good code structure and could be a module. The size of the code is irrelevant but the speed at which it process is the most important part, to do advanced simulations and later start adding a solver which might run the engine 100 times to solve, it better be fast. Every CPU cycle counts.
Standardizing the data structure, I would instead ask that just the engine be installed with a documented data structure, then multiple developers can have their shot at making the best GUI possible.
My 2 cents.....
An assembler is made of two separate things:
1) The GUI code that allows the user to select/adjust objects to attach.
2) The engine I will call it, it would be the code that runs every time the assembly is modified and objects move.
I would then come up with two test assembly models:
1) A 20 piece static model,
2) A simple dynamic model, maybe a lever with a bucket, something like that.
I would count how many mouse clicks, keyboard smacks and also get some idea of build time for the two test assemblies. Let the most experienced build the assemblies to gauge how fast an assembly is built. This is so-so important because the GUI could be simplified later.
I would ask of the Assembler developer if they could containerize the engine (that runs at assemble change), this would show good code structure and could be a module. The size of the code is irrelevant but the speed at which it process is the most important part, to do advanced simulations and later start adding a solver which might run the engine 100 times to solve, it better be fast. Every CPU cycle counts.
Standardizing the data structure, I would instead ask that just the engine be installed with a documented data structure, then multiple developers can have their shot at making the best GUI possible.
My 2 cents.....
Re: The need for a default assembly workbench
@sliptonic Very, very good idea!
I can also add some things to the large list:
1. The assembly workbenches are NOT compatible with each other!
2. This makes it hard for implementing something on top of a assembly (such as implementing a PDM, or with what you are doing ATM).
3. No-one is gonna say that you can better use assembly [2, 3, 4] so you can end up with a weird Frankenstein solution.
4. Sheet-metal cuts for instance should also be implemented and that counts too for surface treatments and painting.
5. (off topic) And add materials for once and for all.
I also however agree with Zolko about the XKCD problem. It is a problem!
My "solution" (looking at Pro/E, SolidWorks and NX) would be to just use A3 and start improving the things, also maybe implement the ideas of Zolko. (preferably written in Nim because then you have the speed of C++)
I can also add some things to the large list:
1. The assembly workbenches are NOT compatible with each other!
2. This makes it hard for implementing something on top of a assembly (such as implementing a PDM, or with what you are doing ATM).
3. No-one is gonna say that you can better use assembly [2, 3, 4] so you can end up with a weird Frankenstein solution.
4. Sheet-metal cuts for instance should also be implemented and that counts too for surface treatments and painting.
5. (off topic) And add materials for once and for all.
I also however agree with Zolko about the XKCD problem. It is a problem!
My "solution" (looking at Pro/E, SolidWorks and NX) would be to just use A3 and start improving the things, also maybe implement the ideas of Zolko. (preferably written in Nim because then you have the speed of C++)
Last edited by grd on Thu Mar 16, 2023 10:59 am, edited 1 time in total.
About Nim. Latest Release 2.0.2. Here is Nim in 100 seconds and a Nim package. There are Qt and OCCT packages.
Re: The need for a default assembly workbench
Please let's not make this a general wishlist, but stay on topic.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: The need for a default assembly workbench
You are right but all the commercial platforms that I know can do this I already said that I think that A3 comes the nearest to these platforms (maybe A2P too). When you are discussing something I think that all the ideas should be mentioned, not only the ones that are "easy", but also the ones that are "hard". My list only completes the list that has been made.
About Nim. Latest Release 2.0.2. Here is Nim in 100 seconds and a Nim package. There are Qt and OCCT packages.
- sliptonic
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: The need for a default assembly workbench
I've updated the first post with a link to part two of the series. That's a exploration of Assembly 2
Re: The need for a default assembly workbench
Thanks for these blog posts - it certainly helps to bring someone up to speed with the history and evolution of the assembly WBs in FreeCad. I am very much looking forward to further developments.