Assembly3, A2plus, Assembly4? Get united!

[drmacro]

Thanks

As for using different files for each part, that's the standard approach for assemblies I think

I don't know in general. I'm trying to use it for woodworking and the ability to have parts in the same project file in Assembly4 was really convenient. There isn't much complicated parts to work with in that case and having to have splits into files would be an overhead.

In industry where there are many parts for a product, and many vendors for parts, vendors for sub-assemblies, and revisions of them all, storing in a single file quickly becomes unwieldy. Creating BOM's, revision BOM's, etc. becomes an issue.

For smaller projects or personal use probably not an issue.

Also, back in the 1960's everyone thought having a console TV/stereo/radio was the in thing...until they realized when one part died and the repairman had to take the console to the shop, they now had no TV, stereo, or radio until it returned.

My point here is that having one file get corrupted and losing the entire project is something to think about.
Of course proper backup regimens can make all the difference.

[ppemawm]

Assembly 4 has the advantage that it doesn't use any solver...

Actually, Assembly4 is intended to be used with an assembly skeleton or master sketch which locates all of the parts. The LCS are attached to the master sketch to avoid the topological problem. In that sense, the sketch becomes the solver which can simulate most types of constraints such as pin connection, slider, etc. If one part is moved, all parts will respond according to the sketch constraints. This is especially useful for top-down or in-context design of new assemblies that must articulate. Please see Zolko's example here: http://downloads.zzaero.com/CVJoint_deflection.mp4

In industry where there are many parts for a product, and many vendors for parts, vendors for sub-assemblies, and revisions of them all, storing in a single file quickly becomes unwieldy.

Then how would you propose the top-down or in-context design of one-off or new prototype assemblies? It is unwieldy only as much as you are disorganized. Bottom-up assembly is not the only game in town.

[drmacro]

Then how would you propose the top-down or in-context design of one-off or new prototype assemblies? It is unwieldy only as much as you are disorganized. Bottom-up assembly is not the only game in town.

Maybe I should rephrase: without enforcing an organized approach, it can become unwieldy.

A large project like a jet or cruise ship could be bottom up or top down, given the needed organization. In projects of that magnitude a rather strict document management system is in place to handle the organization.

[vocx]

...
Assembly3 seems to be bundled with the app image from the releases, at least for Linux.
https://github.com/FreeCAD/FreeCAD/rele ... g/0.19_pre

The AppImage maintainer decided to bundle Assembly3 into the AppImage so that more people could test it.

Assembly4 can be installed by the Addon Manager, so it can be tested in every platform without issues. On the other hand, Assembly3 requires an external solver that can't be included into FreeCAD because it has an incompatible license (GPL3). So, the AppImage maintainer is just trying to help out those who want to start using Assembly3, but that doesn't mean it's officially supported.

As said, no assembly workbench is currently official, but the intention is that users help determine what works best, and whether the ideas of one can be incorporated into the other, in order to get to that goal of having an official assembly workbench.

Assembly3 introduced the App Link object and an improved expressions engine, and then Assembly4 picked those new features to develop its own concept without using a dedicated constraint solver. So Assembly4 built on the core features introduced by Assembly3 during its development.

As for A2plus, this workbench is essentially a continuation of the concepts introduced by the older and obsolete Assembly2, which was the first assembly workbench that got significant use by the community. A2plus works in a more traditional way, and it's perhaps getting too old. Ideally, all good parts of each workbench are collected into a single system, but this may take a while.

[roerich_64]

Thanks

As for using different files for each part, that's the standard approach for assemblies I think

I don't know in general. I'm trying to use it for woodworking and the ability to have parts in the same project file in Assembly4 was really convenient. There isn't much complicated parts to work with in that case and having to have splits into files would be an overhead.

In industry where there are many parts for a product, and many vendors for parts, vendors for sub-assemblies, and revisions of them all, storing in a single file quickly becomes unwieldy. Creating BOM's, revision BOM's, etc. becomes an issue.

For smaller projects or personal use probably not an issue.

I am with you, drmacro.
In the past i show how simple it is to handle huge data with many vendors with A2plus:
https://forum.freecadweb.org/viewtopic.php?f=36&t=34101

You can go through the model:
https://forum.freecadweb.org/viewtopic. ... 20#p287542

You can copy and paste the subs to the master and nothing is broken...
You have to copy the directory of the updated parts to the right place in the tree and make an update in his master. That's it.
And you can create with one klick a summary table of all parts...
Bests
Walter

[roerich_64]

A2plus works in a more traditional way, and it's perhaps getting too old.

I cannot underline this opinion ...
like a2plus, all asm-WB's dance around the well-known toponaming problem. Only when the toponaming problem has been solved should you continue to think about assembling.

Then you will see that the A2plus continues to act at the forefront.

Bests
Walter

[Zolko]

Currently we have at least these three Assembly workbenches... For the FreeCAD community it would be phantastic to see you walk into one direction!

As I said before, I think that the main problem is data structure, more than pure functionality. Also, before thinking about merging all assembly workbenches into one, we should aim for interoperability, meaning that files from 1 WB can be opened in others. The "other" WB might not have the full functionality but at least it should not throw scary errors.

For that to advance, I inform hereby that the Assembly4 data format will be the following.

• root container of TypeId App::Part, called Model at creation time
• each assembled part will have the 2 following properties set in a property group called "Assembly":
• AssemblyType, will be set to Part::Link for Assembly4 assemblies. This means that assemblies are combination of pure/core App::Part containers linked either directly or through pure/core App::Link interfaces. No fancy objects. This allows to open an assembly even if the corresponding WB is not installed.
• SolverId, will be set to Placement::ExpressionEngine for objects placed ... well, with their Placement property calculated by their ExpressionEngine. This means that other solvers can be used. For example, it should be possible to use a Python-based physical solver by parsing the document tree, and each time an object with the corresponding SolverId is encountered - like SolverId='Placement::PhysicsEngine' for example - then that solver calculates the Placement of that object.

Thus, anyone can test whether an object/assembly combination is of the Asm4 type with the following tests:

Code: Select all

def checkModel():
    if App.ActiveDocument::
        model = App.ActiveDocument.getObject('Model')
        if model and model.TypeId=='App::Part':
            return model
    return None

Code: Select all

def isPartLinkAssembly(obj):
    if not obj:
        return False
    if hasattr(obj,'AssemblyType') and hasattr(obj,'SolverId'):
        if obj.AssemblyType == 'Part::Link' or obj.AssemblyType == '' :
            return True
    return False

But it all begins by saying that assembly containers are FreeCAD core App::Part (Std_Part) objects. This is actually also compatible with the Manipulator WB (I think).

ping

ping

ping

[bambuko]

I am more than happy to leave the discussion of the best way forward to those much better qualified than I am, but...
when talking about future options I would love to know/understand (from a point of view of simple user) what would be the consequences for those of us who made an "unlucky" choice?

I (for example) selected Assembly 3. I like it simply because it suits the way I work.

If it were not to be adopted as a "chosen solution", what would this mean for the work I have done until now?
I realise that all three assembly workbenches are not official and are really "experimental", but to be honest I am using Assembly 3 as a working tool and not as an experiment to play with, so would hate to suddenly find that my models no longer work with the latest version of FreeCAD

[Zolko]

I (for example) selected Assembly 3. I like it simply because it suits the way I work.
...
would hate to suddenly find that my models no longer work with the latest version of FreeCAD

yes, of course, this is THE central question. The short answer is: I think "we" should be able to write a script that would convert your existing models to the proposed data structure without any loss, but only realthunder can answer for sure.

The longer answer is more nuanced:

1) you have chosen a fork of FreeCAD (with some/many goodies, I don't blame you because I had done the same), that is using an external solver with incompatible license (LGPL -vs- GPL), and using a custom data structure (and not the App::Part that was designed long time ago as the basis for assemblies). So ... tough, you have my sympathies

2) some of these things are probably manageable, but they will only be managed if we try to manage them: that's the object of my post. If we keep our heads buried in the sand, then no unique assembly workbench will magically materialize. How exactly that assembly workbench will be will depend on the people that make it happen. You're welcome to bring your expertise

3) I (and many here also) do this on my free spare time, so you get what you pay for

4) I don't think that the objective of open-source CAD is the price, but it's the avoidance of vendor lock-in with free and open and documented data structures. If you switch to a data-structure that only a single person somewhere on Internet can maintain, then you get a de-facto vendor lock-in too. Again, you get what you pay for

[chrisb]

I think that the main problem is data structure, more than pure functionality.

Fully agreed!

I (for example) selected Assembly 3. I like it simply because it suits the way I work.
...
would hate to suddenly find that my models no longer work with the latest version of FreeCAD

yes, of course, this is THE central question. The short answer is: I think "we" should be able to write a script that would convert your existing models to the proposed data structure without any loss, but only realthunder can answer for sure.

Having migration scripts would be of course great, but the development should not be driven by such considerations. The future data structure should be indeed be what we concentrate on and not some existing old structures.

If a migration script cannot cope with some models there is always the possibility to keep the current version with its addons to edit old files.