Assembly3, A2plus, Assembly4? Get united!

[herbk]

Hi Chris,

I don't mind where these parts live, but I find it rather appealing to have direct access to standard parts during assembly.

This is why I fell instantly in love with Links!

only linking does only work if an assembly and all it's parts is stored at the same machine.
On bigger projects you don`t have this.
If you get sub assemblys from other sources (e.g. co workers) you need to get full data structure (folders and subfolders) where the contended parts of the sub assembly are stored.

[chrisb]

- Container for design elements and Containers (currently Body or Assembly)

Body is in the sense discussed here not a container, because it holds exactly one solid. Instead you missed the Std Part container, Which can already now serve for assemblies, if all subparts are in the same file. I haven't tried Part container together with Link, but it should already be a powerful combo.

[Zolko]

I haven't tried Part container together with Link, but it should already be a powerful combo.

That's Assembly4

[Zolko]

only linking does only work if an assembly and all it's parts is stored at the same machine. On bigger projects you don`t have this.

I don't know how big projects you're talking about, but those quite big I'm working on — thousands of pieces — all parts are located on the local machine, with a remote repository to synchronize workstations. We had tried to work in a shared database directly, but because of the network lag this proved to be inefficient. Also, using the same files creates locking problems.

If you get sub assemblys from other sources (e.g. co workers) you need to get full data structure (folders and subfolders) where the contended parts of the sub assembly are stored.

Yes, that's a repository. I had used SVN very successfully for that. Everybody had read access to everything, but only the responsibles for a subsystem had write-access to that directory. People could still change locally parts that they were not allowed-to, but they couldn't commit those changes.

[BassMati]

- Container for design elements and Containers (currently Body or Assembly)

Body is in the sense discussed here not a container, because it holds exactly one solid. Instead you missed the Std Part container, Which can already now serve for assemblies, if all subparts are in the same file. I haven't tried Part container together with Link, but it should already be a powerful combo.

That might be the case! I have only looked briefly into the Part Workbench, mostly because I was familiar with the Sketch based design approach, an there is this yellow thing named "Part" in the Part Design Workbench, which can contain several Part Design Bodies.

[BassMati]

Hi Chris,

I don't mind where these parts live, but I find it rather appealing to have direct access to standard parts during assembly.

This is why I fell instantly in love with Links!

only linking does only work if an assembly and all it's parts is stored at the same machine.
On bigger projects you don`t have this.
If you get sub assemblys from other sources (e.g. co workers) you need to get full data structure (folders and subfolders) where the contended parts of the sub assembly are stored.

Actually, I did have distributed file system scenarios in mind (I try to think big, but simple first). Example: Developer A has built a design which contains a partial model tree to be shared. The files may, or may not be in the root design file or folder. For exchange, the partial tree must be moved to a separate file(s) first, if not already so. Then Developer B can link to the root object of the partial model tree in his own design.

Of course, references to entities outside this model tree must be accessible in the same way on both developer machines.

Currently, this can be done with Realtunder's Assembly 3 Preview (I am biased, I'm a bin fan, did you notice?). Unresolved references can easily be identified and corrected. Even the other way works, replacing links with a copy of the link target. This is a very useful feature, considering you are working with distributed designs and libraries in your company, and then want to continue to work off-site.

I consider the idea of working with Links seamlessly across file boundaries most important, although it is not directly related to design assembly.

[BassMati]

… all parts are located on the local machine, with a remote repository to synchronize workstations. We had tried to work in a shared database directly, but because of the network lag this proved to be inefficient. Also, using the same files creates locking problems.

Exactly this came to my mind when I thought about organizing the libraries. I came up with a recipe based on Links (again…). Each external (standard) part is "imported" into the project in the form of a link in folder at the top of the file. When I need a standard part in my project file, I create a Link to the "import link", not directly to the library somewhere in the net. In other words, I use an extra layer of indirection for shared parts.

When I have to modify a shared part (e. g. correct mistakes, add some polish, etc.), I create a local copy, update the "import link" to the copy, and work with that copy until it is finished and tested. When done and approved, I can overwrite the original library file with my new version and change the "import link" to point to the updated file on the network or wherever.

(This technique also works fine when I go working off-site.)

This approach minimizes the write access windows, and is suitable for one or possibly a handful of developers. But there still remains the risk of concurrent update conflicts: When multiple developers work on the same entity, one could easily overwrite the work of another.

With the help of a version control system (SVN, Git,...), these update conflicts can be detected, and managed on beforehand. So, yes, a version control system is highly recommended. Perhaps Git with its distributed repository philosophy could help to overcome the network lag?

But I am drifting off-topic. Sorry for that.

[chrisb]

I have only looked briefly into the Part Workbench, mostly because I was familiar with the Sketch based design approach, an there is this yellow thing named "Part" in the Part Design Workbench, which can contain several Part Design Bodies.

The Part container does not belong to a certain workbench, neither Part nor PartDesign.

[BassMati]

While reading in Zolko's thread "Assembly Without Solver" (https://forum.freecadweb.org/viewtopic.php?f=20&t=32843), I came across the fact that I may have had a different idea of what "assembly" is: Simply putting stuff together at some mating points, perhaps with degrees of freedom for movement is space. The storage location of stuff, whether in the same, or a different (library) file, was not important to me (thanks to use of Realthunder's Links, which I also use heavily within a single file).

I feared that making a distinction introduces unnecessary complexity into the code base, better handle everything uniformly.

Here they start exchanging arguments: https://forum.freecadweb.org/viewtopic. ... 43#p274644

[Zolko]

While reading in Zolko's thread "Assembly Without Solver" (https://forum.freecadweb.org/viewtopic.php?f=20&t=32843), I came across the fact that I may have had a different idea of what "assembly" is: Simply putting stuff together at some mating points, perhaps with degrees of freedom for movement is space. The storage location of stuff, whether in the same, or a different (library) file, was not important to me (thanks to use of Realthunder's Links, which I also use heavily within a single file).

I'm not sure I understand the use-case but may-be I'm missing something: I made an update to the Assembly4 WB to remove an active limitation I had put in, and it is now possible to make assemblies with App::Parts being in the same document. All the rest being equal (LCS, Placement, ExpressionEngine...). You can thus make an Assembly4 Model, put there a master sketch with LCS mapped to some points/vertices, have multiple App::Parts each with its LCS in the same document/file, and link them to the master sketch, making a self-contained 1-level assembly (it's not possible to have more than 1 level with such a scheme).

Why not. The use-case ? ... hum... may-be a switch, that would have 5 parts, and could be assembled to have 2 positions: ON and OFF, and all in 1 file. Dunno