Part Container, Problems and Solutions

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
chrisb
Posts: 26941
Joined: Tue Mar 17, 2015 9:14 am

Part Container, Problems and Solutions

Postby chrisb » Thu Apr 12, 2018 8:33 pm

There are some open issues concerning the Part container which give rise to different help requests in the Help Forum. Many of them origin from the fact that operations don't respect the placement of these containers. Examples range from the position of ShapeBinders to recently ocurring issues with the placement of dimension lines.

On the other hand there are addon workbenches like Manipulator Workbench or Part-o-Magic or Lattice which provide solutions for those problems. This shows that it is possible to solve - at least most of - the problems.
I would like to see these solutions in FreeCAD Master and would invite the authors and others to discuss the possibilities - and hopefully finally implement them.
That would well justify a version 0.18!
easyw-fc wrote:ping
DeepSOIC wrote:ping
ickby wrote:ping
peterl94
Posts: 1000
Joined: Thu May 23, 2013 7:31 pm
Location: United States

Re: Part Container, Problems and Solutions

Postby peterl94 » Thu Apr 12, 2018 9:37 pm

Can you be more specific? Do you have examples that you can link to? Also, do you have examples of what problems are solved by Manipulator Workbench, Part-o-Magic or Lattice?
chrisb
Posts: 26941
Joined: Tue Mar 17, 2015 9:14 am

Re: Part Container, Problems and Solutions

Postby chrisb » Thu Apr 12, 2018 10:49 pm

freecad-heini-1 might have additonal usecases and perhaps a video?
freecad-heini-1 wrote:ping
ickby
Posts: 2976
Joined: Wed Oct 05, 2011 7:36 am

Re: Part Container, Problems and Solutions

Postby ickby » Fri Apr 13, 2018 5:35 am

Many of them origin from the fact that operations don't respect the placement of these containers.
There is no simple solution, even though there are workarounds in different places. The current situation is created very deliberatly, and can only be changed in conjunction with a assembly workbench archirtecture. So e.g. if realthunders assembly is used, he can find a solution within his architecture for respecting placements of parts for operations. If anyone else createas a assembly workbench, he can derive a solution. Butwithout knowing the details of how assemblies in FreeCAD will be computed in the future, the current situation must stay, no way around.
chrisb
Posts: 26941
Joined: Tue Mar 17, 2015 9:14 am

Re: Part Container, Problems and Solutions

Postby chrisb » Fri Apr 13, 2018 7:03 am

Oops, I forgot to ping
realthunder wrote:realthunder
freecad-heini-1
Posts: 7177
Joined: Tue Jan 07, 2014 11:10 am
Contact:

Re: Part Container, Problems and Solutions

Postby freecad-heini-1 » Fri Apr 13, 2018 7:20 am

Realthunder greated a new special shapebinder and some improvements for to avoid topo naming issues.
I hope that his work including assembly3 will be integrated into Freecad 0.18 master.
chrisb
Posts: 26941
Joined: Tue Mar 17, 2015 9:14 am

Re: Part Container, Problems and Solutions

Postby chrisb » Fri Apr 13, 2018 7:32 am

ickby wrote:
Fri Apr 13, 2018 5:35 am
But without knowing the details of how assemblies in FreeCAD will be computed in the future, the current situation must stay, no way around.
Looking at the models uploaded and from my own experience I think we don't have to wait, the future is already here. Part containers are already used for the assembly of bodies. And I can see at least one way around the issues, which is to let the user decide how he would like to have it. A checkbox in the GUI to switch between the current implementation and a mode "respecting parents/Parts/... positions" is how the user sees it. On the implementation side it should be possible as well, as we see from the existing addons.
realthunder
Posts: 1713
Joined: Tue Jan 03, 2017 10:55 am

Re: Part Container, Problems and Solutions

Postby realthunder » Fri Apr 13, 2018 7:34 am

ickby wrote:
Fri Apr 13, 2018 5:35 am
There is no simple solution, even though there are workarounds in different places. The current situation is created very deliberatly, and can only be changed in conjunction with a assembly workbench archirtecture. So e.g. if realthunders assembly is used, he can find a solution within his architecture for respecting placements of parts for operations.
My solution to this problem is in fact to change the FC selection core, such that every user selection, either in the tree view or the 3D view, can provide complete hierarchy information of the selected object. Other workbenches require this hierarchy information can obtain it through the extended Gui::Selection api. For those don't, Gui::Selection will auto resolve the hierarchy down to the actual object selected, in order to maintain backward compatibility. My new SubShapeBinder uses this hierarchy information to synchronize across coordinate system by calculating the relative placement when the user double clicks it. The action of double click gives the selection context, i.e the object hierarchy.
Try Assembly3 (latest version 0.11) along 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
User avatar
easyw-fc
Posts: 2886
Joined: Thu Jul 09, 2015 9:34 am

Re: Part Container, Problems and Solutions

Postby easyw-fc » Fri Apr 13, 2018 8:06 am

ickby wrote:
Fri Apr 13, 2018 5:35 am
Butwithout knowing the details of how assemblies in FreeCAD will be computed in the future, the current situation must stay, no way around.
chrisb wrote:
Fri Apr 13, 2018 7:32 am
Part containers are already used for the assembly of bodies.
Manipulator WB is already used to assembly simple objects, Part and Body containers... it can be already used as a basic Assembly (without constrains and without external links) until Assembly3 will raise up into FC0.18
Aligner, Mover and Caliper can already handle Part and Body containers

Image
other examples here
https://github.com/easyw/FreeCAD-tutorials
https://www.freecadweb.org/wiki/Manipulator_Workbench

Unfortunately ECAD/MCAD collaboration with KiCAD has been recently broken by the adoption of OCC7.2
https://forum.freecadweb.org/viewtopic.php?f=10&t=28052
https://forum.freecadweb.org/viewtopic. ... 26#p227106
and on KiCad forum
not-able-to-create-step-models-with-stepup-and-fcad-0-17
ickby
Posts: 2976
Joined: Wed Oct 05, 2011 7:36 am

Re: Part Container, Problems and Solutions

Postby ickby » Fri Apr 13, 2018 9:23 am

From this thread I think I should clarify what the problem is and how it relates to assembly.

It is easy to calculate the correct placements with multiple hirarchies. Adopting tools to do that is no issue, there is even a python method available to calculate global Placement of objects right now. So e.g. making a shapebinder that works as expected is super simple.

BUT: The consequence of such things is that we make a geometry dependend on placement of other parts. E.g. a shapbinder in body1 links to geometry in body2. The linked shapebinder in body1 would change when placement of body2 is changed, and than the geometry of body1 is recalculated (that is what everyone wants from the shapebinder). Formally we make geometry dependend on placement.

Now imagine how assembly constraints work: You link geometric feature together with a certain relation, and from this a placement for Parts is calculated to fullfill this relation. E.g. you make two planes coplanar. So for any system of assembly constraints we can state: By definition placement depends on geometry

The Problem: We created a nice circular dependency. When placement depends on geometry (constraints) and geometry depends on placement (Shapebinder) we cannot solve the problem anymore. After recalculating either the constraint is not fullfilled correctly or the shapebinder is not correct anymore.

I'm not saying there are absolutely no compromises one can think of, however: who ever creates assembly constraints need to circumvent this problem somehow with very specialized solutions adopted for his architecture. For now we can prevent this loop only by not allowing it to happen in the first place, hence: we forbird to make geometry dependend on placement of the Part hirarchy (because only parts will be moved by assembly as a baseline). That is to enable assembly contraints in the future.