Assembly3 preview

[saso]

On the other hand, there are special code inside topo naming algorithm (especially for history back tracing and coloring) to deal specifically for external linked object. It will be more difficult to rip out that part of code than the other way round, because I did develop Link first.

I understand your argument here and can agree with you, but is this the case for both the "Part geometry" toponaming as for the "sketcher" toponaming? As I remember this were developed separately, I would ask you to please consider to get in at least the sketcher toponaming and exports (7 and 8 from my list), because if you take a look around the forum you will see that many different users are missing this functionality, you have it ready, but because it is not merged in the master users are searching and trying to implement different solutions and this again comes to the point of my main complain.

[Zolko]

App::Part has a restriction that one object can only be in one part group at any time, this simplifies coding a lot, but causes trouble for assembly, precisely because of the link to group situation. When multiple links to the same group are added to a parent group, the same child object of that linked group now appears multiple times. App::Part cannot distinguish that.

I don't understand: as it is today, App::Link and App::Part are perfectly suited to do assemblies and assemblies of assemblies (*), without the need for LinkGroups. That's what Asm4 does and it just works as it should (and as it works in other CAD systems).


(*) and assemblies of assemblies of assemblies.

[realthunder]

I understand your argument here and can agree with you, but is this the case for both the "Part geometry" toponaming as for the "sketcher" toponaming? As I remember this were developed separately, I would ask you to please consider to get in at least the sketcher toponaming and exports (7 and 8 from my list), because if you take a look around the forum you will see that many different users are missing this functionality, you have it ready, but because it is not merged in the master users are searching and trying to implement different solutions and this again comes to the point of my main complain.

Sketch geometry ID and export is what got me started on tackling the topo naming issue. However, once I got the whole topo naming framework more or less done, I went back and reimplement the sketch export stuff using the same framework, and I have since modified sketch several times to improve external geometry, etc. It is really an integrated part of the topo naming framework now.

[realthunder]

I don't understand: as it is today, App::Link and App::Part are perfectly suited to do assemblies and assemblies of assemblies (*), without the need for LinkGroups. That's what Asm4 does and it just works as it should (and as it works in other CAD systems).

Because App::Link uses global link scope to bypass App::Part scope control. You should know that most of the additional code of App::Part comparing to a regular group is link scope control. Besides, you are using my modified selection framework to deal with multiple instances of the same object, without which you can't disambiguate them under an App::Part. The things is, the way you are using App::Part right now is to bypass almost everything that makes it an App::Part. And my suggestion to App::Part modification was exactly that the link scope control is not necessary (actually harmful) for assembly use case. The downside of not doing scope control is that the code becomes more complicated, but then we are not dealing with a simple problem in the first place.

[realthunder]

FYI, my PR thread is https://forum.freecadweb.org/viewtopic. ... 58#p321158

[BassMati]

Axial Move Part Problem

Good morning board!
I don't want to distract too much from the planning, but I'd like to bring your attention to the Asm3 Axial Move Parts tool, which I believe is used to move an assembly relative to its parent assembly. While I can edit the Placement properties directly, or use the Placement Task tool, the Move Parts tool is way more intuitive. However, the mover does not always move the selected assembly, but the second-highest assembly in an tree of nested assemblies.

The simplified model tree:

---- Assembly 001
-------- Assembly002
-------- Assembly003

If I move assembly 2 or 3 in this configuration, everything is fine. The position of the selected assembly is modified as expected. However, in the following configuration,

Assembly000
---- Assembly 001
-------- Assembly002
-------- Assembly003

moving assembly 2 or 3 changes the position properties of assembly 1. In effect, both assemblies 2 and 3 are moved.
The same when assembly 4 or 5 is moved in the following configuration.

Assembly000
---- Assembly 001
-------- Assembly002
------------ Assembly004
-------- Assembly003
------------ Assembly005

In all these situations, the position of assembly001 is modified instead of the selected assembly.

Observation: No matter what element (Assembly, Body, Feature) was selected in the model tree when the Axial Move Parts tool was invoked, the Mover showed up at the origin of assembly 1. But when a Origin was selected the mover appeared at the origin of the related sub-assembly. That seemed to do the trick, however still the position of Assembly001 was changed, but not the position of the selected sub-assembly.

By the way: The Transform Task of a Body element works as expected.

Am I missing something here…?

Best Regards
Ulrich

Preview 0.10.2 2019.07.03 on Windows 10 x64

[realthunder]

Axial Move Part Problem

I'll add an "active assembly" concept in future release to make it easy working with deep nested assemblies. Meanwhile, you can do this with the two-selection trick. Select your part first as normal, then CTRL select the parent assembly (within which you want to move your part) in the tree view, and then click Axial move button. In fact, you can use this trick on any action to disambiguate the nested assembly, e.g. adding constraint.

[BassMati]

Axial Move Part Problem

you can do this with the two-selection trick

Great - that's a life saver! Works perfectly! Thanks a lot!

[Kunda1]

Where are all the As3 enthusiasts when testing the big App::Link merge at https://forum.freecadweb.org/viewtopic. ... 7&p=325888 ?

[realthunder]

Where are all the As3 enthusiasts when testing the big App::Link merge at https://forum.freecadweb.org/viewtopic. ... 7&p=325888 ?

Right, asm3 actually works in the LinkMerge branch. I'll soon make some changes so that it can be installed through the add-on manager.