[Problem] Assembly: duplicate parts are renamed

[pierreporte]

Is there an existing issue for this?

• I have searched the existing issues

Problem description

When inserting more than one of the same part in an assembly, the name is changed in the tree. For example, the part called “bolt” in its file will be displayed “bolt”, “bolt001”, “bolt002”, etc. The name of parts shouldn’t change. The instance number should be displayed separately in a distinct manner.

In Catia, it would be displayed like this: “bolt (bolt.1)”, “bolt (bolt.2)”, etc.

In Solidworks, it would be displayed like this: “bolt<1>, “bolt<2>”, etc.

When the name of the part changes, the instance number doesn’t.

Full version info

0.22 with PR #10764
Tested width Ondsel ES 2024.1

Subproject(s) affected?

Assembly

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[pierreporte]

Interesting forum post about this: https://forum.freecad.org/viewtopic.php?p=742461#p742461

According to user1234 on the forum, this is more of a Core issue, not Assembly. Though it’s the right behavior for features inside a part. @PaddleStroke at what level should this be addressed?

[PaddleStroke]

Yes this is a core issue. It's probably a big work so not sure someone will want to tackle this right now :)

[pierreporte]

My comment for #12141, make me thinking about an important detail for instance numbers. This number is incremented by levels only and not for the whole view. Here is an example of an assembly with several sub-assemblies, with only one part with multiple instances at every levels:

• Root assembly
  • Sub-assembly 1 (instance 1)
    • Part (instance 1)
    • Part (instance 2)
  • Sub-assembly 2 (instance 1)
    • Part (instance 1)
    • Part (instance 2)
    • Part (instance 3)
  • Part (instance 1)
  • Part (instance 2)
  • Sub-assembly 1 (instance 2)
    • Part (instance 1)
    • Part (instance 2)

[pierreporte]

Related forum thread: https://forum.freecad.org/viewtopic.php?t=87499

[pierreporte]

@martinproks this could interest you.

[martinproks]

@pierreporte

Thanks,
Your right, booth of the issues (#12139 and #12141) You have written are pointing to the same problem I'm trying to open at the discussion on forum.
But it is not just about assemblies, it is general approach of FreeCAD to naming and showing object labels in tree.
I'm more and more thinking, big step forward could be change default setting. Try Edit-Preferences and according the image.
Next try to make some assembly wit repetitive parts and repetitive fasteners.

[martinproks]

Sorry one more:
the setting does not change "mangling" of labels. But You can rewrite it back to label You want.
First three screws I rewrite the Label, the last one I left as it was after inserting into assembly.

[pierreporte]

@shaise The fasteners wb sems to support instances of parts. Dy you thing that the solution could be used for links to generic parts in FreeCAD? They are required for the BOM feature.

[shaise]

@pierreporte , AFAIK It does not actually support instances. There is a fastener caching system that prevents regeneration of an already generated fastener by just making a copy of the original cached one. It is still a full copy, not a link.

[martinproks]

@shaise The fasteners wb sems to support instances of parts. Dy you thing that the solution could be used for links to generic parts in FreeCAD? They are required for the BOM feature.

Hi,
The image I have send was from fasteners_mp library, not from fastener WB. It has been mentioned as demonstration of possibility to rename object.Label if You set ON the Allow duplicate object labels in one document. I did not mean by this to point out that fasteners WB makes just objects without STD_PART (instance) wrapper.

But yes, this could be good an helpful, if the part object with filled parameters will be there. Links are one benefit, parameters are second benefit. For parameters example look to image (screw from fasteners_mp library)

vs. informations from the same(EDIT: sorry, not the same, this is not hexagon but star, sorry) pure screw from fasteners WB

[pierreporte]

@PaddleStroke Do you plan to implement instances for your BOM feature?

[PaddleStroke]

Currently it is like so, you have a part :
Part (label = Part, Name = Part)

If you make a link of it you have :

Part (label = Part, Name = Part)
Part001 (label = Part001, Name = Link)

Make one more link of it :
Part (label = Part, Name = Part)
Part001 (label = Part001, Name = Link)
Part002 (label = Part002, Name = Link001)

The names must be different of course, and their value is not so important.

So basically current situation seems very similar to catia and sw. It's just the syntax that changes. <1> instead of 001.
The difference if I understand correctly, is that freecad just set the labels, then there's no connection to the original label. What you want is that the links have the same labels as the original object.
So if you rename 'Part' to 'Bolt' it also change the labels of all the links to it?
Then on top of that add an instance number.

There are two ways this could be done I guess :
A - When an object is re-labeled, you change the names of all the links to it. This could be tricky because that would mean mofifying external files.

B - The displayed names for links is not the link label anymore, but it fetches the linked object label instead. This way changing the label of the component would not modify external files.

I think B is the correct way to handle this. However it has some drawbacks :

• What if you actually want to customize the label of a link? Say you make a link then change some 'copy on change' properties. Then perhaps your M6 x 20mm screw is a M6 x 30mm screw and you want to be able to name it like so.
  Then one possibility would be to use the linked object label only if the link does not have any copy on change modifications.

Anyway this is a substantial change to core. So @wwmayer you probably want to weight in.

[pierreporte]

The current situation is actually pretty different from other CAD program in that, while the displayed label is different, which is necessary to distinguish the instances, FreeCAD considers them as completely different. It is proved by the screenshot posted in #14198:

Instances should be the way to avoid this problem. A solution could be having some common attribute stored in each link to a specific target. I don’t know how it should work when the target is inside the current file. The BOM feature would count the number of parts (or sub-assemblies) that share this common information to determine the quantity. It could also be the index of an array.

What is displayed in the tree view is a different problem and there is an issue about this: #12141. The idea is that the label in the tree view is a formatted string that can’t be edited manually. Its content is fetched from the attributes of linked parts and sub-assemblies, and of course instance number. So to change anything, the user must edit the link target. All instances pointing to this same target would have their label changed. The way attributes should be modified by the user could be discussed in #12136 which is about implementing part attributes in the first place.

Solution A goes in the right direction. Links are shortcuts to the part and it is legitimate to edit them in context. Because links are links, it makes no sense to change just one instance: solution B isn’t right. What could be allowed, though, is to change manually the instance number. Catia allows it: by default it’s a number incrementing from 1 but you can use custom text (very useful for connectors that you can thus name e.g. J0123 to better identify them). This would be only for the parent assembly it is done in.

Let’s consider your M6x20 screw example. It is stored in screw.fcstd. Its attributes internal are:

Attribute	Value
name	Screw M6x20
filename	screw.fcstd

FreeCAD is set so that the tree view label is formatted like this for the children of an assembly:

`{name} [{instance_number}]`.

Three instances of this part in an assembly creates this:

Tree view label	Instance	Target
Screw M6x20 [1]	1	screw.fcstd
Screw M6x20 [2]	2	screw.fcstd
Screw M6x20 [3]	3	screw.fcstd

FreeCAD knows that all these links have the same target so the BOM shows a quantity of 3. Now, the user wants to make the screw longer. When they are done, they change the name attribute to Screw M6x30 (in a standalone tab or in context). Then, the tree view updates:

Tree view label	Instance	Target
Screw M6x30 [1]	1	screw.fcstd
Screw M6x30 [2]	2	screw.fcstd
Screw M6x30 [3]	3	screw.fcstd

With variant links, it would be like the target gives choice of the configuration to insert, each one having a specific name attribute. The label is formatted using the exposed attribute value. The above table could have an extra column for the configuration name. Then it depends on if the configurations should be considered different parts or if they are different display state (think a tube that can be straight or bent). Both are valid though.

All this discussion about attributes is getting too far for this issue though. @pieterhijma could have relevant input on this topic (attributes of course but instances as well).

[pieterhijma]

Interesting discussion! My two cents: Document Object have a Name that must be unique and this is enforced. Document objects also have a Label that shows up in the tree view. By default the labels are made unique (enforced) by appending 001, etc. but there is a preference where you can disable this and in that case labels do not have to be unique any longer.

Appending 001, etc. is FreeCAD's way to indicate that it is an instance of something else, either a copy or a link. In general, FreeCAD doesn't care in what manner different instances are made unique, so the solid works or catia schemes could easily be implemented in a macro or so. We also have to take into account that a label can be a target of an expression, so if a document object has label "My label" and the object is referred to in an expression as <<My label>>.Length, then changing the label will change the expression as well unless the expression is in an external file that is not open. So, changing labels is not completely without potentially breaking models.

There is also Label2 that is hidden by default and does not show up in the tree (I believe), but this could perhaps also be used to differentiate instances.

Regarding BOM and counting, for links it is easy to detect whether there are multiple instances because of the LinkedObject property. For variants, it will be more difficult. For copies, it's a bit more complicated. Each document object has a unique _Object UUID property. When a user makes a copy of a document object, this document object will have a _Source UUID property with the value of the _Object UUID of the document object from which the copy was made. Additional checks are necessary to verify it is actually the same part.

I think what would be nice in terms of BOM functionality is a button that allows you to change labels according to a user-defined scheme where the user can select for links and copies whether the base label of the source object should be adopted.

[martinproks]

Hi,

It is not good idea to think, the object2.Label = 'Washer001' is just second piece of object.Label = 'Washer'. Imagine real situation: first object.Label = 'Washer 10 iso 7089' and second object will be automatically labeled anotherObject.Label = 'Washer 10 iso 7090'. Two hours later You do not know if both of them are the same and just automatic re-labeled, or if each of them is really different. How any (BOM) tools should know it?

Another variant - look to Std Part (also called App Part or instance) parameters and make tree window more user customizable - allow more user controlled columns, not just Label2 (marked as DESCRIPTION).

Std Part.Name - unique name in one document
Std Part.Label - unique value at default setting of FreeCAD - this is the visual and BOM problem
Std Part.Label2 - marked as DESCRIPTION in tree window
Std Part.Type - a description for this object. By default, it is an empty string
Std Part.Id - an identification or part number for this object. By default, it is an empty string
and more like Material, License, ... https://wiki.freecad.org/Std_Part

Then You can let the .Label as it is now and focus on .Type and .Id for BOM tools and assembly tree. But not-instance objects does not have these parameters. It is pointing to start think about splitting model tree from Assembly tree...

[FlachyJoe]

By default the labels are made unique (enforced) by appending 001, etc. but there is a preference where you can disable this and in that case labels do not have to be unique any longer.

So Assembly could inform the user and change this preference at load (and set it back at unload).

[PaddleStroke]

The current situation is actually pretty different from other CAD program in that, while the displayed label is different, which is necessary to distinguish the instances, FreeCAD considers them as completely different. It is proved by the screenshot posted in #14198:

You miss understand this screenshot. Pieter inserted several time the same object, but they are not linked in anyway. Even if the solids are identical, the objects are separated and the BOM tool has no way to know it should add them up (fastener's BOM can because it implemented some custom properties in fasteners objects to recognize identical objects, but this is not the way to handle things). This is a problem of the fastener workbench and of the user. The user/wb should insert the fastener only once, then use links to create copies. Then the BOM tool would have known it's the same and added the quantity.

The instances mechanism is the same as the BOM tool, it cannot guess that 2 objects are identical if you create twice the same object without any connection between them. To work it must use App::Link.

We also have to take into account that a label can be a target of an expression

This is very problematic then. Expressions should use name as labels can be edited no? But Names are not user friendly as they're not user facing... Maybe the expressions should display/accept the labels in the UI but internaly replace them by the names

[pieterhijma]

It is not good idea to think, the object2.Label = 'Washer001' is just second piece of object.Label = 'Washer'. Imagine real situation: first object.Label = 'Washer 10 iso 7089' and second object will be automatically labeled anotherObject.Label = 'Washer 10 iso 7090'. Two hours later You do not know if both of them are the same and just automatic re-labeled, or if each of them is really different. How any (BOM) tools should know it?

Oh yes, I didn't anticipate this problem.

[pieterhijma]

We also have to take into account that a label can be a target of an expression

This is very problematic then. Expressions should use name as labels can be edited no? But Names are not user friendly as they're not user facing... Maybe the expressions should display/accept the labels in the UI but internaly replace them by the names

Yes, this would perhaps be better, but it is not so easy to accomplish. From the top of my head, we would need to maintain for a sub-expression whether it was created using a label or with a name. In case of the former, we show the user the label subexpression instead of the name. Internally it uses the name only. Hm, perhaps doable, but we should also take backward compatibility into account.

I checked to be sure if I'm correct: If there are two files file1 and file2, both with a Cube and you refer from file2 to the cube from file1 in an expression, like for example <<file>>#<<Cube>>.Length and you change the label of the cube in file1 from Cube to CubeNewLabel, the expression in file2 will automatically update to <<file>>#<<CubeNewLabel>>.Length. This is not true if file2 is not open and if you open file2 after the label change, it is broken in the sense that it cannot resolve the expression because it cannot find the document object with label Cube any longer.

This has been the case forever, I believe, and I'm not aware of complaints of this behavior so far. I assume that users understand that this can happen when making use of labels across files in expressions.

[martinproks]

Hi,

@PaddleStroke : The instances mechanism is the same as the BOM tool, it cannot guess that 2 objects are identical if you create twice the same object without any connection between them. To work it must use App::Link.

This could be done just at case "Assembly: All in one monolithic file". Then You can add instance from file just one time and rest of them link across whole assembly tree.

Imagine "Assembly: Separate instance = separate file". It is common for industry cooperative work. Each instance - (sub)assembly or component - has its own file and each file could be edited by another person independently. Each instance could be easy used in other project - just use or link the file with the instance. In this case You will have multiple added instances (for example screw or any possible one) at multiple levels. At this moment, it does not make sense to enforce law: "insert once and use link for all".

And what about people who are using mixed approach: smaller sub-assemblies in monolithic files, bigger assembly at higher level follow "separate sub-assembly = separate file". This approach is the most problematic, but still relatively correct I think.

You have to count with multiple added identical files on each level. You have to take into account:

• links are the same instances as source
• multiple added files contains the same instances - check filename or another method?
• Fasteners WB elements - how to deal with copies? Wrap them to the Std Part and use parameters .Type or .Id?

[pierreporte]

The instances mechanism is the same as the BOM tool, it cannot guess that 2 objects are identical if you create twice the same object without any connection between them. To work it must use App::Link.

@PaddleStroke Do you mean that multiple links to a component stored in an external files are counted as different components? Do you have to create a link to a component already in the parent assembly, be it stored in the document or a link itself? I can test your PR to get the answer myself.

The common workflow is described by @martinproks. Users create instances using Assembly_InsertLink.

Imagine "Assembly: Separate instance = separate file". It is common for industry cooperative work. Each instance - (sub)assembly or component - has its own file and each file could be edited by another person independently. Each instance could be easy used in other project - just use or link the file with the instance. In this case You will have multiple added instances (for example screw or any possible one) at multiple levels. At this moment, it does not make sense to enforce law: "insert once and use link for all".

@martinproks I think that there is a misunderstanding there. Instances are not components and are not stored in external files. Instance is not a synonym for part, it’s a generic term for assembly and part. Instances are the different 3D models (part or assembly) inserted in an assembly from a single component. Let me correct your comment:

This could be done just at case "Assembly: All in one monolithic file". Then You can add component from file just one time and rest of them link across whole assembly tree.

Imagine "Assembly: Separate component = separate file". It is common for industry cooperative work. Each component - (sub)assembly or part - has its own file and each file could be edited by another person independently. Each component could be easy used in other project - just use or link the file with the component. In this case You will have multiple added components (for example screw or any possible one) at multiple levels. At this moment, it does not make sense to enforce law: "insert once and use link for all".

[...]

• links are the same components as source
• multiple added files contains the same components [...]
• [...]

[pierreporte]

Just to make it clear, copying and pasting an instance of a component should create a new instance: a link to the original target, not to the copied one.