Please more posts of this quality, rich of contents on the topic, and not only about.
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!
Re: The need for a default assembly workbench
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
A2p has an issue in my workflow (which I consider a very common and needed feature)...
if you need to export an assembly generated by A2p to STEP format, you may have as result shells instead of real watertight solids...
This is why I left to use A2p even if the interface is very friendly.
This is an issue which is not present in A3 or A4 assembly.
Re: The need for a default assembly workbench
Hello, there was already an attempt to merge A4 and A2p: viewtopic.php?t=52720
At the time, it seemed hopeful for the default workbench being discussed in this thread. I've been reminded of this while reading this topic and thought that knowing why it wasn't achieved might add something to the topic at hand.
At the time, it seemed hopeful for the default workbench being discussed in this thread. I've been reminded of this while reading this topic and thought that knowing why it wasn't achieved might add something to the topic at hand.
Re: The need for a default assembly workbench
Nice overview, this is very helpful. I wonder how much of the speed/memory issue can be resolved simply by writing the solver in C++ (which we'd be able to do for a Workbench that is distributed with FreeCAD).
Re: The need for a default assembly workbench
Have you ever working with assemblies professionally? Then you are gonna realize that manipulating a part inside a assembly is also very important. So features like sheet-metal cuts and cuts after metal casting are very important features. And that counts too for clearance / interference checks, and also for painting for instance and engraving something after it is assembled. You know, ordinary things.
But, I agree totally with @chrisb, please stay on topic.
@sliptonic Wonderful post. I like it
@chennes
Please think about Nim, since Nim has roughly the same speed of C++, but doesn't have all the cruft of C++. Once all the header files are wrapped you are gonna work in a language that looks very much like a Python that is more down to earth.Nice overview, this is very helpful. I wonder how much of the speed/memory issue can be resolved simply by writing the solver in C++ (which we'd be able to do for a Workbench that is distributed with FreeCAD).
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
Hi,
I am very happy to see this discussion. I tried switching to FreeCAD a couple of years ago and the plethora of conflicting assembly solutions prevented me from doing so. Recently I have started to get back into FreeCAD to give it another try.
I think there has been quite a lot of good discussion on what a default assembly workbench might look like. However, another important question is how to get there. @Zolko's idea regarding defining a common data schema is a good place to start.
According to the documentation Std_Part is supposed to be the container for assemblies. This leads to the following questions:
1. Is that documentation sufficient to use it as a common definition?
2. Do existing workbenches have requirements that cannot be satisfied by the existing Std_Part?
3. What needs to be done such that all assembly workbenches use Std_Part as the container?
I am very happy to see this discussion. I tried switching to FreeCAD a couple of years ago and the plethora of conflicting assembly solutions prevented me from doing so. Recently I have started to get back into FreeCAD to give it another try.
I think there has been quite a lot of good discussion on what a default assembly workbench might look like. However, another important question is how to get there. @Zolko's idea regarding defining a common data schema is a good place to start.
According to the documentation Std_Part is supposed to be the container for assemblies. This leads to the following questions:
1. Is that documentation sufficient to use it as a common definition?
2. Do existing workbenches have requirements that cannot be satisfied by the existing Std_Part?
3. What needs to be done such that all assembly workbenches use Std_Part as the container?
-
- Posts: 125
- Joined: Sat Feb 21, 2015 5:56 pm
Re: The need for a default assembly workbench
@ppemawm, @Zolko — that's really useful feedback, thank you!
@ppemawm, what are the top reasons for you to choose LCS over other means to achieve the same result?
@grd, personally, I think the list of requirements is perfectly on topic. In fact, I'd be interested to see more of those lists. Pet peeves are unavoidable, but finding common ground is important. Otherwise the entire point of designing something that works for 80% of use cases simply won't fly.
@ppemawm, what are the top reasons for you to choose LCS over other means to achieve the same result?
@grd, personally, I think the list of requirements is perfectly on topic. In fact, I'd be interested to see more of those lists. Pet peeves are unavoidable, but finding common ground is important. Otherwise the entire point of designing something that works for 80% of use cases simply won't fly.
Re: The need for a default assembly workbench
Of course I would like to see ppemawm to stay tuned!! But my post was not directed towards him, but to others (like you) to encourage them to voice their needs for assemblies in such a very clear way. Example: you could have made your desires much clearer without hiding them in a direct question about ppemawm's modeling experience.
Don't spoil your posts by your own spam. The programming language is an implementation detail and not relevant to a user. Speed can be, reliability can be, size can be. The language not.Please think about Nim,
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
I try to say it in another maner, less happy and with no joy.
It seems some FC users are looking for a default assembly wb and talk about it in this thread. I just say:
- asm3 already exists
- asm3 works
- slovspace slover is gplv3 but PlaneGCS slover is already used in FC
- asm3 can use several solvers as input
- if asm3 can take Plane GCS as input, it could be a good candidate as a 2D default assembly workbench, with solvespace solver optionaly.
My 2 cts.
Re: The need for a default assembly workbench
I only choose LCS since it is the method to connect body and part links in Assembly4 with which I am familiar.prokoudine wrote: ↑Tue Mar 21, 2023 7:22 pm what are the top reasons for you to choose LCS over other means to achieve the same result?
"It is a poor workman who blames his tools..."