Assembly3 preview

[realthunder]

- what to select in TechDraw to get projected views? I tried various possibilities without success.

5. Drawing - probably the most serious problem at this stage is that the assembly cannot be placed into drawing (or did I failed to do it correctly?). "Assembly" would allow to start "Insert ortographic projections..." command, but would result in an empty views.

It just occurred to me that I forgot to mention an easy solution that is working in my current release. Select any assembly you want to export to TechDraw, change the property 'BuildShape' to 'Compound'. That's it. Now the assembly will dynamically build a compound shape very time it is recomputed. TechDraw will work with an assembly just like any other shape.

6. Merging - is there or would there be a way to merge particular parts ("bodies") into one body, when assembled this way? One reason for that I can imagine is a FEM analysis, where one wants to assess a body with ribs and brackets as a one solid thing...

Can body be used for FEM analysis? Because body does have a 'Shape' property that is automatically set to the tip feature's Shape. There is similar feature in assembly container, as mentioned above. If FEM insists on single solid, then you can try to set 'BuildShape' property to 'Fusion', although that will make assembly recompute a lot slower. Does FEM support CompSolid? I'll add that if so.

[easyw-fc]

Can body be used for FEM analysis? Because body does have a 'Shape' property that is automatically set to the tip feature's Shape. There is similar feature in assembly container, as mentioned above. If FEM insists on single solid, then you can try to set 'BuildShape' property to 'Fusion', although that will make assembly recompute a lot slower. Does FEM support CompSolid? I'll add that if so.

I'm going to ping @bernd

FreeCAD FEM supports ...
ping ...

[OakLD]

This sounds like a bug. It would be better if you can post a file to demonstrate the problem. And maybe some screencast to show your steps.

I will try to test it more and give some feedback. You have probably noticed, that in the meanwhile user jpg87 experienced the very same thing...

2. Positioning

You can either a) turn off auto recompute, and use mover to (roughly) pre-align the part to your desired configuration, and then hit recompute button, or b) turn on auto recompute, and use mover to rotate the part. When rotate pass some threshold, it will flip. What the software does behind the scene is that, it will move the part with your mouse, and call the solver. If the solver fail (which is made silent and hidden from user), the part position will be reset. So the end user won't see the movement, but it does move behind the scene, kind of like method a), and I believe that is how SolveSpace handle this, too.

I tried that sometimes with mixed results, I failed to identify the case with solver silently giving up. Now I know it's a valid workflow, I test it this way.

3. Tree - Assembly --> Parts --> Constraints --> Constrained Elements

You suggestion will not work well in nested assemblies. Remember that a 'part' can be repeatedly used in many different places, say a screw. The screw has the same geometry element for constraining with others, but each instance will certainly connect to an element of a different part. In other word, one of the elements in the constraint will be different each time the instance is used, so it cannot be grouped with the 'part'.

There's a little misunderstanding, perhaps. The parts shown in mockup tree are not source parts, but of course their instances (as well as parts in your Parts container); you can see there STIFFENER and STIFFENER001 and similar cases. Thus, "STIFFENER.Face2" is short (visual representation only) for a more complicated link like perhaps "Parts.Link0009.Pad.Face2" (the same you store in the real link).

There's another "issue" with this model: The constraints shown become duplicated. They're placed at both parts they're constraining. But this is OK, most users are used to that from another CAD/CAE packages and again, it is only visual representation of the parts, constraints and their elements. There's always just one real constraint behind the two constraints shown.

The logic of my assembly's grouping is this. The constraint group groups the configuration of its owner assembly. The element group groups which element the owner assembly can be constrained with other higher level assemblies. The proper way of doing assembly, IMO, is to put each part object into an assembly container, even though the part itself do not need any assembling. Because in A3, assembly container serves a double purpose of part container.

I think that your design is pretty neat and totally agree with placing parts into assembly containers.

Then, the part author should manually specify which geometry element this part can be connected to, and give them meaningful names.

Here, my humble opinion differs. I agree that without naming each constraint, the current tree quickly becomes very difficult to use, because one cannot find the constraint he needs (I had big problems with the small tree for the relatively small assembly shown above). I wouldn't introduce manual naming; why to spend time on something, which is not nessecary You could force naming convention like i.e. <constraintName_Part1-Part2>, but I think it wouldn't make things completely clear. When you'll have 50 or 100 constraints, it wil become a nightmare to look for the one you want to edit. I'd say it's way easier, when it's grouped under a part instance node.

Repeat this process to create composite parts that contain sub-assemblies. When assembling, only connect the parts at their declared elements. I probably should add a property to optionally enforce this behavior (i.e. let the part author decide). The above workflow is not strictly enforced, in case the user just want some quick single hierarchy assembling. But for mult-hierarchy assembling, it will quickly become hard to track without some 'rules', or 'workflows', or whatever.

I'm completely lost, perhaps I'm missing some point. From the previous discussions, I got a sense that to achieve multi-level assemblies, simply assemblies could be placed within another assembly container (I didn't test it in detail yet), it would receive same constraints as parts (though technically, the object path would be more complicated) and I see no obstacles in the proposed tree. It is not necessary for a user to know, that the assembly he constrained with 3 constraints are in reality 3 constraints applied to 3 different parts.
IMHO, from past front-end experience I think that, CAD/CAEs consider inserted (sub)assembly as a "solid" or "locked" object and don't try to resolve subassembly constraints in the same context (mathematically meanin the same formulae), as the parent assembly. I'm not sure how FC handles that, but from your explanation I have a notion that you put all the constraints from all the levels into one context (so solver would try to handle all the constraints in one solution). Is this the case and the reason of your concern?
Again, what I propose is a visual representation (front-end) anyway, it wouldn't change a thing on the design... I think in the low/object level (back-end) it is necessary to do it the way you did or likewise.

Finally, there is a way to trace the element to its owner part. When A3 workbench is active, right click the element of the constraint in the tree view, and choose 'Link actions -> Select linked object'. This will locate the element in the sub assembly's element group. In case there are more hierarchy down below, use 'Select linked object' again to go down. If you want to jump straight to the final geometry model object that actually owns the geometry element of the constraint, then choose 'Link actions -> Select final linked object'.

Thanks, this works for selecting a link.

4. "Redundant Constraints" message

If you see this message, then there is definitely redundancy. It is not always intuitive, but if you carefully count the DOFs, you'll see. But yeah, I probably should not make that as a warning message.

Well, you're right, I counted them and with typical 3x PlaneAlignment setup, 2nd pane alignment has 1 redundant DOF constraint and 3rd has 2 redundants. I'd still suggest to hide the message in this valid case, because it's the mainstrem realworld workflow...

5. Drawing

I'll add that support in Techdraw later.

Great and in the meanwhile, the workaround is to merge it as you pointed out in the point 6 below. Works fine!

6. Merging - is there or would there be a way to merge particular parts ("bodies") into one body, when assembled this way? One reason for that I can imagine is a FEM analysis, where one wants to assess a body with ribs and brackets as a one solid thing...

Switch to Part workbench. Select the assembly you want to merge in the tree view. In the Main window menu, select 'Part -> Create a copy -> Create simple copy'. You will get a single Shape of that assembly.

Works like charm!

One more thing I wonder about is the necessity to open all the drawing, whem making an assembly. I think, while it's OK for development, it would be a real complication for regular use. I believe that all the CAE SW I worked with (SolidEdge SolidWorks, Catia) are able to load from each component only relevant information, a sort of STEP representation of the part, without history, internal relations and constraints, etc. This is loaded only into RAM and is not exposed to user other than as a part model in the assembly. A "refresh" button then reloads the STEP-like representation and re-applies the constraints. I can't imagine other way, specifically I can't image a feasible way to handle i.e. multi-level assembly with 100 parts in total as it is now (with opened files, full history, possibly all the details like drawings, FEA analysis, path solutions,...).
I just wonder, if you considered it when designing the assemblies object model or what is the long-term plan?

[realthunder]

There's a little misunderstanding, perhaps. The parts shown in mockup tree are not source parts, but of course their instances (as well as parts in your Parts container); you can see there STIFFENER and STIFFENER001 and similar cases. Thus, "STIFFENER.Face2" is short (visual representation only) for a more complicated link like perhaps "Parts.Link0009.Pad.Face2" (the same you store in the real link).

That will require yet another container for each part added to the assembly, further complicate the hierarchy, especially if there are nested assemblies. How would you like to be able to expand the element item of the constraint to reveal its owner part? Will that make the relationship easier to see?

One more thing I wonder about is the necessity to open all the drawing, whem making an assembly. I think, while it's OK for development, it would be a real complication for regular use.

Yes, this is a problem, and is not easy to solve. But I'll definitely work on it later. Maybe make assembly container able to dynamically load or off load part details depending on whether the tree is collapsed or expanded.

[OakLD]

It just occurred to me that I forgot to mention an easy solution that is working in my current release. Select any assembly you want to export to TechDraw, change the property 'BuildShape' to 'Compound'. That's it. Now the assembly will dynamically build a compound shape very time it is recomputed. TechDraw will work with an assembly just like any other shape.

Oh, great, the other workaround through "Simple Copy" worked, but this one seems like it can be a semi-permanent solution. I'll try it.

6. Merging

Can body be used for FEM analysis? Because body does have a 'Shape' property that is automatically set to the tip feature's Shape. There is similar feature in assembly container, as mentioned above. If FEM insists on single solid, then you can try to set 'BuildShape' property to 'Fusion', although that will make assembly recompute a lot slower. Does FEM support CompSolid? I'll add that if so.

I guess I always did a boolean fusions. It's just that I was unable to apply it to the parts in the Assembly tree. The "Simple Copy" works well there and I'll test the "Build Shape" in the nearest oportunity too, to be able to compare them.

Thanks for suggestions!

[Jee-Bee]

6. Merging

Can body be used for FEM analysis? Because body does have a 'Shape' property that is automatically set to the tip feature's Shape. There is similar feature in assembly container, as mentioned above. If FEM insists on single solid, then you can try to set 'BuildShape' property to 'Fusion', although that will make assembly recompute a lot slower. Does FEM support CompSolid? I'll add that if so.
[/quote]
Fem is not good at handling bodies. as work around you can use the deepcopy macro. When more users need partdesign parts probably at some point it will implemeted. @Bernd the main programmer is more or less an architecture guy...

3. Tree - Assembly --> Parts --> Constraints --> Constrained Elements

You suggestion will not work well in nested assemblies. Remember that a 'part' can be repeatedly used in many different places, say a screw. The screw has the same geometry element for constraining with others, but each instance will certainly connect to an element of a different part. In other word, one of the elements in the constraint will be different each time the instance is used, so it cannot be grouped with the 'part'.

There's a little misunderstanding, perhaps. The parts shown in mockup tree are not source parts, but of course their instances (as well as parts in your Parts container); you can see there STIFFENER and STIFFENER001 and similar cases. Thus, "STIFFENER.Face2" is short (visual representation only) for a more complicated link like perhaps "Parts.Link0009.Pad.Face2" (the same you store in the real link).

There's another "issue" with this model: The constraints shown become duplicated. They're placed at both parts they're constraining. But this is OK, most users are used to that from another CAD/CAE packages and again, it is only visual representation of the parts, constraints and their elements. There's always just one real constraint behind the two constraints shown.
quote]

I don't know if this is best place to quote...
I have added how creo handle the structure of parts in an assembly.

creo_structure.PNG (12.79 KiB) Viewed 1855 times

For every part it create a placement-set (it is possible to switch between sets in a assembly) in the set it handles just the type of placement. For me as user i care about the constrain in placement not between which objects the relations are.
I haven opened the tree now but by default all placements are collapsed.

[OakLD]

That will require yet another container for each part added to the assembly, further complicate the hierarchy, especially if there are nested assemblies. How would you like to be able to expand the element item of the constraint to reveal its owner part? Will that make the relationship easier to see?

But you always have all the instances of all parts in the tree. That's the case of all the CAE I have used and what I don't get is, that even in ASM3 you have a container for each instance of the part (unless I misunderstood something and used ASM3 it incorrectly).
In any case, I think you always want to see a tree of assemblies and components, while if I understood you correctly, you want all the components from different assembly levels mixed in one container? Perphaps, if you have a screenshot of such multi-level tree, it might help me to understand. I'll try to post comparison of this in differnt CAEs; I see there's a new screenshot with Creo tree here...

One more thing I wonder about is the necessity to open all the drawing, whem making an assembly. I think, while it's OK for development, it would be a real complication for regular use.

Yes, this is a problem, and is not easy to solve. But I'll definitely work on it later. Maybe make assembly container able to dynamically load or off load part details depending on whether the tree is collapsed or expanded.

Good you've considered it, I guessed it's a rather complicated task.
Unfortunately, my programming experience ends at 2D (VB.NET GDI), so just an idea - wouldn't be possible, to trigger (upon insert or update of the assembly) creation of sort of "Copy Simple" object (or another compound, in any case an object without history and other stuff) and constrain this within the assembly?

[realthunder]

even in ASM3 you have a container for each instance of the part (unless I misunderstood something and used ASM3 it incorrectly).

That is not the case in asm3. The following picture show that Assembly001 has three parts. Cube001 is simply added as it is, no extra container for it. The second part, Assembly, is also added as it is, and it happens to be a sub-assembly. The third part, Link_Assembly, is linked to Assembly, or, we can say it is an instance of Assembly, which has the exact same hierarchy when you expand it. The PlaneCoincident001 in the parent assembly is for the relationship of Cube001 and Assembly, while the PlaneCoincident constraint in the sub-assembly is for Cube and Cylinder in the Assembly.

Screenshot from 2018-06-22 23-11-10.png (33.75 KiB) Viewed 1801 times

Following your suggestion, we would have to create a container for each part object, and add a constraints group there, something like

Code: Select all

Assembly001
   | -- Constraints001
   |        | -- PlaneCoincident001
   |
   | -- Elements001
   | -- Parts001
          | -- CubePart001
          |       | -- Constraints002
          |       |         | -- PlaneCoincident001
          |       |
          |       | -- Cube001
          | 
          | -- AssemblyPart
          |         | -- Constraints003
          |         |         | -- PlaneCoincident001
          |         |
          |         | -- Assembly
          |                 | -- Constraints
          |                 |        | -- PlaneCoincident
          |                 |
          |                 | -- Elements
          |                 | -- Parts
          |                        | -- CubePart
          |                        |        | -- Constraints004
          |                        |        |        | -- PlaneCoincient
          |                        |        | -- Cube 
          |                        |           
          |                        | -- CylinderPart
          |                        |        | -- Constraints005
          |                        |        |        | -- PlaneCoincient
          |                        |        | -- Cylinder 
          |                 
          | -- Link_AssemblyPart
...

I'll try to post comparison of this in differnt CAEs

Yes, please. I may get some ideas there. Also please include some description of each item means what.

[realthunder]

I don't know if this is best place to quote...
I have added how creo handle the structure of parts in an assembly.

Could you please give some brief description of the meaning of those Sets items? Are these constraint applying to the bodies inside its owner part, or for inter-relationship between the sibling parts?

[OakLD]

That is not the case in asm3. The following picture show that Assembly001 has three parts. Cube001 is simply added as it is, no extra container for it. The second part, Assembly, is also added as it is, and it happens to be a sub-assembly. The third part, Link_Assembly, is linked to Assembly, or, we can say it is an instance of Assembly, which has the exact same hierarchy when you expand it. The PlaneCoincident001 in the parent assembly is for the relationship of Cube001 and Assembly, while the PlaneCoincident constraint in the sub-assembly is for Cube and Cylinder in the Assembly.

Following your suggestion, we would have to create a container for each part object, and add a constraints group there, something like

Well, bellow is your example (for a direct comparison) and the proposal together.

AssyRealThunder.PNG (35.59 KiB) Viewed 1782 times

Proposal.png (27.3 KiB) Viewed 1782 times

It's apparent that there's not much difference here, especially due to the special case of the linked assembly. I'm not sure what exactly should be the purpose of this and why and how you'd achieve to share PlaneCoincident001, I think you'd have to have at least 1 more constraint. Anyways, this is not typical assembly, I'd use something like the one I posted above, which I'd say is really "average" by all measures (in mechanical enginering). I'd say an average assembly contains 5 to 10 parts (or subassemblies) and min 2 constraints per part.
I'll do a comparison of the tree of this assembly too, but not sure it's gonna be Today. We'll see, if we can make anything of that. I don't want to waste your pressure time on legthy discussions, I'll try to get to the point or give it up, if there wouldn't be much benefit...