Assembly solver and recompute system

[triplus]

I like the direction in which the debate is going. Maybe i only see it a bit differently here:

There is no value of using python to implement what would mimic the standard implementation 1 to 1.

I would see some value in that if the results would be substantially easier and faster to communicate and achieve (it could serve as a good intermediate step).

I have a strong feeling that I will have to mess with C++ to some extent to make a Py assembly workbench. In particular, I want instance objects, and I'm afraid I will have to create one in C++. Then I would want to extend selection system, to make it possible to figure out the whole path to selected element (like Assembly->Instance003->Part005->Body002.Edge1). And I still struggle to understand, how to deal with multiple instances of a single object.

And how does @hamish do it? It does look like to me he figured out how to make an instance object to be used in the assembly. Selection i guess works. Having multiple instances of the same part/feature is possible (duplicate feature).

And thinking about this leads me to another question. Due to all the changes made and effort invested it is possible to move and rotate the part. But do we actually want to do that in assembly directly or we will end up using only the resulting "instance feature" (multiple times) in assembly? This "instance feature" would have its own placement anyway?

And, as noted by triplus, I indeed want to try to roll out such a system as a python addon (codename assembly3 ).

It depends. If it will be communicated and after perceived as the correct way to go you could still go after assembly1.

[ankou29666]

The problem I'm facing with Assembly2 is that, everytime I make any change to a part's geometry, it completely breaks the assembly when updating it. And the whole job has to be done again which is pretty tedious and infuriating. You cannot assemble two parts with FreeCAD in just two clicks as it can be done with SketchUP.

Why ? I haven't looked neither FreeCAD's nor Assembly2's source code, but I've looked into a .FCstd file to see how it's done inside it.
And my guess is it's due to this kind of bullshit :

Let's consider a naiive organization:

Code: Select all

+ Part
+ Part001
+ Assembly container
   + instance of Part
   + instance001 of Part
   + instance of Part001
   + constraint
   + constraint001

(like Assembly->Instance003->Part005->Body002.Edge1).

When I talk about bullshit, I don't mean about the organization (I don't care much about the internals), I mean about the use of "Part005", "Edge123" and "FaceXYZ" elements naming.
Let's assume that I put a plane constraint between Part005.Face052 and Part012.Face103.
Let's assume now that I make a change in Part012's geometry and the face previously numbered 103 now becomes 126.
Just guess what happens in the assembly when updating it.

That's the problem : Assembly2 relies on stuff (pseudo-random numbering of the elements) that cannot be and thus never should not have been relied on, as FreeCAD doesn't seem to supply the neccessary stuff for Assembly2 to properly deal with the changes.

I never faced any error message stating any error with impossible constraints when doing my updates, I don't know if i've been lucky until now or if there's some trick in Assembly2 trying but failing to deal properly with these issues.

I'm not saying this solution is the best one, but in my opinion, one good solution would be in each part's file to manually set names to the faces / edges involved in the assembly leaving to user's responsability to verify these namings after each change in a part. So that Assembly2 can rely on manual names rather than quite-random ones.

Or if there's a catch to solve this issue, then I apologize for posting here.

[DeepSOIC]

...

Hi! See this:
https://forum.freecadweb.org/viewtopic.php?f=8&t=21471
and this:
https://forum.freecadweb.org/viewtopic. ... 10#p167169

and all other endless discussions about toponaming.

TL/DR: it is the way it is, and we haven't done much about it so far. For now, you have to live with it.

[ankou29666]

TL/DR: it is the way it is, and we haven't done much about it so far. For now, you have to live with it.

I know, I just wanted to point out to both FreeCAD's and any AssemblyX's maintainers a serious issue that would be interesting being solved. I'm trying to be constructive !!!
In my case, I think it will end up in performing the assembly with the help of macros, searching for the shapes I want to assemble by their coordinates.
That will do it waiting for the should-be-easy GUI way to be fully operational and reliable.


I've skimmed through your two topics (off topic with assembly issues), and as I had replied you here, I persist believing that toponaming sounds a really complicated and unnecessary stuff just to manually set an already existing value that is arbitrarily pseudo-random. I haven't understood much of those toponaming stuff (haven't found any topic that properly explains what it's actually supposed to be and to do, FreeCAD's documentation, yet another thing we have to live with(out) ), but at least concerning the assembly problems, it really looks like labyrinthine system, uselessly complicated to do barely nothing.
I understand it may be otherwise for other purposes, but for the Assembly case, it looks like there's just an optionnal "name" property missing in the concerned objects (edges and faces) along with the mechanics (searching for that name into the tree) for those elements to be used by these manual names rather than the pseudo-random ones.

[triplus]

Hi @ankou29666.

When input parameters change the result is different. Therefore if you use a box as a base (by using a vertex, edge or a face of the box) to add (assembly) relation. If you after turn the box in a cylinder. The result simply can not be the same and the relation needs to be redefined.