View Issue Details

IDProjectCategoryView StatusLast Update
0003149PartDesignBugpublic2020-01-06 06:19
Reporterickby Assigned Toickby  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status assignedResolutionopen 
Product Version0.17 
Target Version0.19 
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.
FreeCAD Information

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)

SimonLitt

2020-01-06 06:19

reporter   ~0013985

Hi!
When I mirror a pad,the body of the part becomes empty.
When I delete a copy, I cannot return the pad back to the body.
Error message is: Object can only be in a single GeoFeatureGroup

Sometimes when creating a sketch, the message drawing during migration appears, and when choosing automatic, an empty body is created, and everything settles as before.

When I make a mirror copy of the body - everything is fine. But so far I have understood it, I made a lot of mistakes in the drawings. Now, in order to change something, I need to make copies of the sketch and create the parts again.

[url=https://youtu.be/aRHqHNmfftc ]youtube screen record[/url]
Full console output


$ freecad
FreeCAD 0.18, Libs: 0.18RUnknown
© Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2019
  ##### #### ### ####
  # # # # # #
  # ## #### #### # # # # #
  #### # # # # # # # ##### # #
  # # #### #### # # # # #
  # # # # # # # # # ## ## ##
  # # #### #### ### # # #### ## ## ##

'ascii' codec can't encode characters in position 13-17: ordinal not in range(128)
Part::Mirroring / Part__Mirroring: Links go out of the allowed scope
Part::Mirroring / Part__Mirroring: Links go out of the allowed scope
Part::Mirroring / Part__Mirroring: Links go out of the allowed scope
Exception (Mon Jan 6 08:34:06 2020): Object can only be in a single GeoFeatureGroup
Exception (Mon Jan 6 08:34:07 2020): Object can only be in a single GeoFeatureGroup
Exception (Mon Jan 6 08:34:48 2020): Object can only be in a single GeoFeatureGroup
Exception ignored in: <bound method WebView.__del__ of <__main__.WebView object at 0x7fa1c5e362b0>>
Traceback (most recent call last):
  File "<string>", line 18, in __del__
AttributeError: 'WebView' object has no attribute 'webPage'
Sketcher::SketchObject / Sketch: Links go out of the allowed scope
Exception (Mon Jan 6 08:34:57 2020): Object can only be in a single GeoFeatureGroup
Exception (Mon Jan 6 08:35:00 2020): Object can only be in a single GeoFeatureGroup
Exception (Mon Jan 6 08:35:04 2020): Object can only be in a single GeoFeatureGroup
Exception (Mon Jan 6 08:35:08 2020): Object can only be in a single GeoFeatureGroup
Sketcher::SketchObject / Sketch001: Links go out of the allowed scope
$

console

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
2020-01-06 06:19 SimonLitt Note Added: 0013985