assembly without solver

[fosselius]

if the linked Model is at the correct place but badly oriented, select the constraint associated with it, and edit the App::Placement property called "Offset"

How does using offset constraint differ from using the model/part or body placement? (Other then naming and location in comboview)

[triplus]

I read the discussion and i still see a (placement related) solver involved, expression engine? Technically therefore this isn't an assembly without involving any solver? Anyway i could quote a few things and i just selected one.

There are no geometries that are defined, only datum objects, therefore a "traditional" assembly approach with geometrical constraints would NOT (edit) work here. Once such an assembly is made, the sub-assemblies in their respective sub-directories can be handed out to different designers, and they can develop their model in parallel, and as long as they don't delete or rename the interface LCS-s, the assembly will always be consistent.

All your examples are basically too complex to base an initial discussion on them. Lets say two designers need to design two boxes. Boxes should be assembled after, one being placed on top of another. What would be the standard procedure involved, doing it your way. LCS feature as an interface in i guess an empty Part container would be provided, one for each designer. And involving the expression engine, to i guess take care of placement, would need to happen.

Can you demonstrate such use case in Assembly 3 build?

[fosselius]

Think storage shelf, you know the width, height, number of racks in the shelf. You have labled sections (LCS) in the shelf, you do not know what object/box that will be stored there, but you got a rough outline.
You order boxes to be put in the shelfs different sections from different stores with different leadtimes. What you store might vary over time.

Given this, having an LCS to attach the parts to will enable you to have a well specified top assembly, even if objects within the assembly is missing or change over time.

Now think about a train, its often well specified from the start, you know length, with, height, number of chairs, floorplan, but you have no 3d objects, those will be added/modified over time.

[triplus]

I asked for boxes related example as it would likely expose some shortcomings. That is some cons and limitations when assembling by relying only on an assembly solver providing "coincidence constraint".

As for the rest sure, this is therefore basically a thread about "interfaces". On how to set up a bunch of empty containers and use their interfaces to get some "assembly structure" up front.

@Zolko therefore found the missing piece he was looking for buried in the code. That is you can add and use a CS to an empty container and use such CS up front, as an interface, to define an (empty) assembly structure. But this isn't all that new concept. True CS feature was missing, but other datum features were already available. Making them selectable and usable for such potential purposes. Some of that happened as a part of Assembly 3 effort in the past.

As for @saso i am not sure if this is the sort of interfaces he is talking about. He is likely more leaning in the direction of perceiving Part containers as nodes. Nodes having "interfaces" one can use to connect them and form an assembly structure up front. This i guess is still rather abstract stuff and will need to be more clearly defined in the future. But i am guessing the ultimate goal would be being able to connect lines in between nodes in a graph alike user interface.

[triplus]

Reference:

https://forum.freecadweb.org/viewtopic. ... 21#p285621

[Zolko]

All your examples are basically too complex to base an initial discussion on them.

I don't understand: I tried to provide some simple examples, made from just 4 parts, were they too complex ? Did you try to open them ?

Can you demonstrate such use case in Assembly 3 build?

• take a piece of paper, draw your boxes (yes, I'm not kidding)
• decide what are the functional elements of your boxes (corner, middle-point, hole ...)
• once that's done, fire-up FreeCAD (but really only after you have done the previous points !)
• new document → new part → new sketch → draw sketch such as where you would want the previously decided reference points to be. If necessary, make several sketches
• save your document as asm_2boxes
• new document → new part → new body → new sketch → draw a rectangle of approximate size → extrude that rectangle → save document as box 1
• create some LCS where you think you want your previously decided reference points to be
• repeat for box 2
• in asm_2boxes, insert box1, place according to the LCS
• repeat for box 2
• now that you know how your boxes are going to actually be assembly this way, modify them. Create new LCS if necessary. Don't design any details until you're satisfied with the way the boxes fit together.
• swap between assembly and part to check that you are going into the right direction
• Go into more detail of the boxes' design, and, if necessary, create a new (second) body, which is going to be your real part.

[Zolko]

How does using offset constraint differ from using the model/part or body placement? (Other then naming and location in comboview)

I'm not completely sure actually. What I understand is that an object can have 1 placement. Either that placement is static, given by numbers, parameters, or it is driven by a formula, the expression engine. Since we use here an expression engine for the placement, we can't use the static (though parametric) placement anymore. Therefore, when placing an object with the expression engine, the 2 LCS — the one from the part and the one from the assembly — are superimposed. But when the 2 LCS have different orientations, we'll get a part that is placed at the correct location but with the wrong orientation. Look at some previous examples to demonstrate this.

That's why it's necessary to introduce an intermediate placement (called therefore Offset) to , well, offset the part LCS with respect to the assembly LCS.

But you're right, I think I have overcomplicated that stuff, I think now that it should be possible to make this simpler, even to the point that bog standard App::Parts can be used for assembly (but still with the App::Link stuff). I'll try to find time to modify my macros to do just that. Unfortunately, my cool time at work is finished, project go ahead full steam now.

[triplus]

I don't understand: I tried to provide some simple examples, made from just 4 parts, were they too complex ? Did you try to open them ?

Yes, on both accounts.

But you're right, I think I have overcomplicated that stuff ...

I share the same sentiment.

yes, I'm not kidding

Fair enough. Will go through the procedure tomorrow.

[emills2]

Problem and Questions:
i just read through the entire thread, and i'm not clear on where to find the current/relevant pieces of the latest proposed system.

it seems one needs:
- realthunder's asm3. is the current preview, Preview 0.9.1, 2019.02.02 appropriate?
- fosselius' GUI portion. or is this in asm3?
- zolko's script/macro?


Thoughts:
it seems, at cursory glance that the matter of having places to store text, object links, etc would be relatively straightforward with new python features. and python features make it really easy for lots of people to try things out. no compiling, no branches, no merging.

long term of course, FreeCAD should have a full constraint solver. but i agree with saso and zolko (i think), that it is not appetizing to try to work with something that clearly violates the basic rules of assembly documents.

basic rules like:
1 - assemblies should refer to, and not contain, their members. otherwise, they are just a complicated models.
2 - an assembly should not care if one of it's members is a part or an assembly (sub-assembly in the context of the first mentioned assembly). the only limitation being that an assembly cannot contain itself as a sub-assembly, at any sub-level.
3 -a clear unique identifier for the assembly, and a mechanism to to retrieve the same identifier for all members (whether simple parts or subassemblies). this is my addition to the conversation here. Don't forget BOM stuff, you actually need it to verify the 'no self containing loops' rule.

all a constraint solver does is calculate the final placement for a particular member of the assembly. it is completely separate from the data structure of the assembly. as zolko points out, the data structure itself has value even without the solver, since in 99% of real world use cases, the user can provide the placement solution. not a delta robot placement solution, but that is a separate concern.

taking it to the next extreme, an assembly document that does the three things above, but doesn't even allow repositioning is still incredibly valuable, because at least it is a database of the assembly design from which you can extract BOM, total mass, etc. no one would call that a full assembly system but still useful.

next layer: add the repositioning feature per zolko's spec, and if you have proper linking it'll pull in his LCSs, and any new features.

next layer: add a solver, and if the solver is well implemented, it'll have no problem accessing and manipulating the placement property. the existing LCSs can be easily converted into assembly constraints.

personally i would just use sketches instead of an entirely new object for LCSs, or make sketches valid as LCSs. sketches have a placement property so it is cake to slap one (from a part) on top of another (in an assembly).

the gif below is a silly thing i made for fun a long time ago. but i shows sketches controlling a 3D curve, sketches placed along that curve controlling more curves, sketches placed along those curve controlling more curves...so you can reach an arbitrary set of sketches in full 3D

a complex nested series of sketches like that at the top level of an assembly could then have parts positioned on them (through zolko's LCS system), and the possible 3D assembly complexity jumps through the roof. before we even have a solver

transition to 0.17 03 - 00.gif (267.84 KiB) Viewed 253 times

[Zolko]

Problem and Questions:
i just read through the entire thread, and i'm not clear on where to find the current/relevant pieces of the latest proposed system.

you're right. Though it's still work in progress, it is somewhat usable for the adventurous, and some scripts and GUIs do work now. Unfortunately, I don't know how to bundle them in a user friendly way. I'll post the latest scripts here tomorrow.

Thoughts:
it seems, at cursory glance ...

you have summarized the current situation quite well, hopefully this means that we're getting somewhere.