View Issue Details

IDProjectCategoryView StatusLast Update
0003149PartDesignBugpublic2019-05-09 18:35
ReporterickbyAssigned Toickby 
PrioritynormalSeveritymajorReproducibilityhave not tried
Status assignedResolutionopen 
Product Version0.17 
Target Version0.19Fixed in Version 
Summary0003149: Duplicate body creates a mess
Descriptionhttps://forum.freecadweb.org/viewtopic.php?f=3&t=15949

While experimenting on how Part-o-magic withstands object duplication, I found a bug in PartDesign.
1. New Part, New body
2. New sketch. Draw rectangle. Close.
3. Pad the sketch.
4. Select Body and menu Edit->Duplicate... When asked whether to duplicate dependencies, click Yes.
The body is duplicated.
But.
Problem No.1. Body is not added to active Part. OK, that can be fixed manually...
Problem No.2. and all looks fine, until one dives into dependency graph. There, a total mess can be seen.

Graph problem No.1: Duplicates of Sketch and Pad were added to original body, as well as to the copy of body.
Graph problem No.2: Pad001 references Pad (that is, gets fused to it).
TagsNo tags attached.

Relationships

related to 0003768 confirmed FreeCAD Losing Origin and/or Geofeatures 

Activities

wmayer

2017-10-01 21:01

administrator   ~0010232

With the implementation of scoped links the issue has been fixed. There is only a minor issue left because when duplicating the body this error comes up:

Exception (Sun Oct 01 22:51:58 2017): Object can only be in a single GeoFeatureGroup  
Traceback (most recent call last):
  File "<string>", line 1, in <module>
<class 'Base.FreeCADError'>: Object can only be in a single GeoFeatureGroup


The question is if it can be avoided to raise the error message.

DeepSOIC

2017-11-20 10:29

developer   ~0010436

IMO the bug is still very big.

a) when I duplicate a body, a message pops up, if FreeCAD should duplicate dependencies.
If I answer No, the contents of the body is not duplicated; errors in report view, and the new Body shares an Origin object with the old body. This is a mess.

b) the original Body (which I deactivated before copying) got activated back. I expect that the active object should not change.

c) the action of the "copy dependencies" question applies the old logic of isolated PartDesign of 0.16, which partly explains point a). What I expect: "No" = body should be copied with all its contents duplicated, but none of the objects outside of the body should be duplicated. "Yes" - same, but with all dependencies not in body too (e.g. master sketches). This might get really tricky if for example there is a shapebinder of a partdesign feature from another body.

Bicycle Repair Man

2019-05-09 18:30

reporter   ~0013096

Last edited: 2019-05-09 18:35

View 3 revisions

I can verify, that this bug is still present in some form in the 0.19 daily build from today (May 9th 2019).

1. Please open "Duplicate_Part.FCStd" - This design has one master spreadheet to parameterize all parts.
2. Select Part "Rahmen"
3. Edit -> Duplicate Selection
4a. Answer "No" to "copy dependencies"
- In this case only the Part itself without any content is duplicated. To me, this is an unneeded state and I fully agree with DeepSOIC's suggestion c) to solve this.
4b. Answer "Yes" to "copy dependencies"
- The Part and its contained objects are duplicated, BUT
the duplicate references the original spreadsheet: Reference in Rahmen001 -> Rahmen_vorne001 -> Position.x now points to "Spreadsheet.w_rahmen" which is the original Spreadsheet. This should be "param001" (or "Spreadsheet001" if neccessary).
Similar to Rahmen001 -> Rahmen_vorne001 -> Length that points to "param.h_nut" which is also the original spreadsheet

In any case, my suggestions are
- The original part should stay unaltered
- Independent of saying "Yes" or "No" to copy dependencies, I expect that all objects within the selection (also recursively) appear in the resulting object tree. Anything else is not a duplicate.
- If saying "No" only objects within the selection tree should be duplicated (but still recursively). That would mean, that the duplicate references the master spreadsheet exactly the same way like the original.
- If saying "Yes" also dependecies outside the selection tree (e.g. master spreadsheet) should be copied and correctly referenced by the duplicate objects (again, also recursively through the tree)

Many thanks for bringing this great tool to us!
Best Regards,
Stephan

OS: Linux Mint 19.1 (X-Cinnamon/cinnamon)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.
Build type: Release
Python version: 3.6.7
Qt version: 5.9.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: German/Germany (de_DE)



Duplicate_Part.FCStd (85,368 bytes)

Issue History

Date Modified Username Field Change
2017-08-07 05:43 ickby New Issue
2017-08-07 05:43 ickby Status new => assigned
2017-08-07 05:43 ickby Assigned To => ickby
2017-10-01 21:01 wmayer Note Added: 0010232
2017-10-01 21:07 Kunda1 Description Updated View Revisions
2017-10-01 21:08 Kunda1 Description Updated View Revisions
2017-11-20 10:29 DeepSOIC Note Added: 0010436
2018-01-30 17:55 wmayer Target Version 0.17 => 0.18
2019-01-13 17:03 wmayer Relationship added related to 0003768
2019-02-23 20:22 wmayer Target Version 0.18 => 0.19
2019-05-09 18:30 Bicycle Repair Man File Added: Duplicate_Part.FCStd
2019-05-09 18:30 Bicycle Repair Man Note Added: 0013096
2019-05-09 18:33 Bicycle Repair Man Note Edited: 0013096 View Revisions
2019-05-09 18:35 Bicycle Repair Man Note Edited: 0013096 View Revisions