Monster Kossel version 3 - LinkDaily + Assembly3

[jpg87]

...

I finally reappear!
I've had quite a bit of trouble with sketches that have lost their reference plane. I wanted to fix them, but it was endless. So, as your problem was at the assembly level, I redid this one from the step files.
The result is here:
https://www.dropbox.com/s/rd4tb5fqt5j8y ... st.7z?dl=0

I proceeded in a very different way to take advantage of the multiplicity of blocks while simplifying the work. There are of course other approaches. I am at your disposal for any additional explanations necessary.

MonsterKossel.jpg (151.36 KiB) Viewed 1466 times

[goeland86]

Thank you! I will take a look at what's going on with the sketches and reference planes.

And it's always helpful to see how someone else puts things together, so I appreciate the help. I'm a self-learner, which means I pick up bad habits a lot more than good ones

[jpg87]

...

I forgot to specify that I worked with the same version as you:
OS: Windows 10 Version 2009
Word size of FreeCAD: 64-bit
Version: 2022.111.30764 (Git)
Build type: Release
Branch: LinkDaily
Hash: ef3092bcbca5475eff4eb7ff7933eb3e9bbbe4b9
Python version: 3.8.6+
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.6.0
Locale: French/France (fr_FR)

Besides, I don't understand: this morning I'm trying to reopen your files and I have no more problems. I probably installed the daily version after my first attempts and probably hadn't tried opening the files again with the newer version.
Anyway, I just reopened your file "MonsterKossel_assembly" :
When recalculating the constraints, I have some errors, even before testing the problem you cited above.

You've done a tremendous job, and I even wonder how the solver didn't crash sooner!

This is why the approach that I have proposed allows you to limit the number of constraints per packet, since a sub-assembly behaves like a single block, and the solver only recalculates the constraints of the level which is active.

ArborescenceMonsterKossel.jpg (145.19 KiB) Viewed 1371 times

PS: I saw that you also used Assembly 2+.
May I ask you why you are now at Assembly 3? Is it just to compare them?
The whole thing is a huge job!

[goeland86]

This is why the approach that I have proposed allows you to limit the number of constraints per packet, since a sub-assembly behaves like a single block, and the solver only recalculates the constraints of the level which is active.

That's very good insight in helping the system become more manageable.

PS: I saw that you also used Assembly 2+.
May I ask you why you are now at Assembly 3? Is it just to compare them?

The reason I'm switching from A2Plus is because there's more development going on from what I can tell. And also if I understood correctly, there are fixes happening that resolve some of the topological naming issues in the branch?

The whole thing is a huge job!

It's a huge printer! And I still need to add all the fasteners to the assemblies!

I'll rebuild the assembly using sub-assemblies to hopefully make things easier to manage. I want the MonsterKossel to become a reliable delta printer framework, not just a one-shot printer. Parameters on the input will eventually be: bed diameter, vertical print volume. The rest I want to have automatically calculated dimension-wise, so as to make building a custom large-format printer easy. It's part of my business plan, to offer custom-sized printers with minimal hassle or changes to the parts required.

[jpg87]

I want the MonsterKossel to become a reliable delta printer framework, not just a one-shot printer. Parameters on the input will eventually be: bed diameter, vertical print volume. The rest I want to have automatically calculated dimension-wise, so as to make building a custom large-format printer easy. It's part of my business plan, to offer custom-sized printers with minimal hassle or changes to the parts required.

Hats off!
I will come back to see the project.

[goeland86]

Hmm. Something's still not quite right. Same daily version. Much fewer elements to assemble, I still get an odd bug when trying to align washers & screws from the Fasteners workbench with a part design workbench part. What could be the issue? The file that gives me trouble is here:
https://github.com/goeland86/MonsterKos ... mbly.FCStd
Referenced file is available at https://github.com/goeland86/MonsterKos ... meda.FCStd

This should hopefully help identifying the problem. It works for the first 2-3 alignments on one hole of the part design part. But it fails on the second (i.e. doing an axial constraint linking one of the M3x14, 3 washer inner faces and one of the holes in the part design workbench.)

If I create individual constraints between pairs of elements it works as well. But then I get issues when doing planar constraints to get the washers to "pile up" correctly. Will submit screenshots if it helps clarify the issue.

[jpg87]

Something's still not quite right.

Hello,
I opened your PrecisionPiezoAndromeda file in the LinkStable version to test: sketch 001 loses its attachment reference to the face. This does not happen in the Daily version.
This brings me to some general remarks (don't be offended if you already know everything I'm going to say, it's just related to my humble experience) :
- In the current state of things, personally I rather use reference planes (DatumPlane) instead of existing faces. This complicates the work a bit but minimizes the risk of loss of reference.

RefPlane.jpg (117.62 KiB) Viewed 1226 times

This plane is created from the XY plane and its distance (in z) from XY is related to the thickness of the pad:

Code: Select all

<<Pad>>.Length

- Personally always, I use symmetries in sketches whenever possible, and it's better to use Sketcher_ConstrainCoincident, Sketcher_ConstrainPointOnObject, Sketcher_ConstrainHorizontal, Sketcher_ConstrainVertical constraints, rather than zero distances.

Sketch.jpg (68.28 KiB) Viewed 1226 times

The 14 mm dimension is named "Width" in order to use it in the following sketch to attach it to the edge of the 1st volume.

Sketch1.jpg (77.32 KiB) Viewed 1226 times

Notes regarding assembly in the next post...

[jpg87]

...

As for the assembly,
- inserting the Bodies in part containers is useless, on the other hand it will be necessary to name the bodies explicitly.

- It is essential to fix an object that will serve as a reference for the following and will prevent the whole thing from wandering according to the constraints.

- To position a screw in its housing, a single constraint is sufficient by relying on a circle of the plane under the head of the screw and a circle of the entry plane of the hole receiving it :
See on my page http://help-freecad-jpg87.fr/020_ass_outils_contr.php Locked constraint, PlaneCoincident constraint and Attachment constraint.

The interest of the Attachment constraint is twofold: not only does it not make the solver work, but it can be cleverly installed after positioning two objects to replace the constraints used instinctively when possible, precisely in order to relieve the solver.

Name Elements.jpg (184.91 KiB) Viewed 1216 times

Edit:
Another general remark: when several identical screws or bolts are involved in the same technical function, it is usual to represent only one of them to simplify life!

[jpg87]

The complete assembly my way.

CompleteAssembly.jpg (175.39 KiB) Viewed 1200 times

[goeland86]

Thanks for the tips.

I was aware of the datum plane methodology, but I have such complicated parts to draw out that I feel it would get way too confusing to create new planes all the time. It was part of my reasoning to move to the LinkDaily branch - thinking it would begin to resolve the topological naming problem... If it's not ready to that point yet, I'll adapt.

With regards to the assembly using only one instead of multiple elements, well... I was hoping to have all elements in place so as to properly build out the BOM with the correct quantities for the final project. And that's usually where the constraint solving failures occur, when I have repeats, or copy-pastes of the Fastener WB parts involved... I'm not sure if it's a bug or not at this stage.