Messing around with the topo-naming issue
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Messing around with the topo-naming issue
Here is an interesting example. The filename says it: open the file and change in the first sketch the diameter of the hole in the center from 3mm to 5mm.
The post will then move from one hole to another.
The post will then move from one hole to another.
- Attachments
-
- topoNamingFailChangeCenterDiameterTo5.FCStd
- (16.19 KiB) Downloaded 18 times
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Messing around with the topo-naming issue
I'm not discounting what happens to the plate, the holes do get renumbered, but in sketch001 there is an extra circle, remove Circle #3 and the sketch becomes under constrained. Maybe there should be check in Sketcher for duplicated elements.
I have noticed that the sketch (if not constrained correctly) can have an impact on face renumbering, I don't know why.
I have noticed that the sketch (if not constrained correctly) can have an impact on face renumbering, I don't know why.
Re: Messing around with the topo-naming issue
The third circle is a reference to external geometry. Without it the parametric behaviour is partially lost, but that's what it's all about!freedman wrote: ↑Sat Dec 19, 2020 12:48 am I'm not discounting what happens to the plate, the holes do get renumbered, but in sketch001 there is an extra circle, remove Circle #3 and the sketch becomes under constrained. Maybe there should be check in Sketcher for duplicated elements.
I have noticed that the sketch (if not constrained correctly) can have an impact on face renumbering, I don't know why.
Change in Sketch001 the radius at the left lower corner from 14mm to 20mm, and you can see what I mean: the hole of the post no longer matches the hole of the base.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Messing around with the topo-naming issue
I see, good example. It would seem (after seeing this) the topo-naming fix is two-fold.chrisb, The third circle is a reference to external geometry. Without it the parametric behavior is partially lost, but that's what it's all about!
1) External geo needs to be replaced by a dimension link (between sketches). When a sketch is opened it would show the linked dimensions. This way they would be stored in the sketch and stay resident.
2) Repositioning the sketch on it's correct face. If the correct face can't be found then prompt the user to select one.
Would that be a total solution?
Re: Messing around with the topo-naming issue
That's what we are advocating all the time in order to avoid the topological naming issues. But it doesn't really solve them. If you want to derive the information automatically you will have to trace back all geometric operations. Think of the curve you get when you intersect two cylinders; and you could continue with further complicated operations. Such curves cannot be mapped directly to a sketch.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Messing around with the topo-naming issue
I'm using this code to find all numbered faces and the output is shown below. Does anyone know a way to isolate the feature associated with each face. What I would like to see is:
"Face3, Pad001".... something like that but everything is relative to the last feature. I understand that as I enumerate thru I get the list relative to the Tip but is there a way to get the individual features (the faces are on) as I enumerate thru.
Thanks
"Face3, Pad001".... something like that but everything is relative to the last feature. I understand that as I enumerate thru I get the list relative to the Tip but is there a way to get the individual features (the faces are on) as I enumerate thru.
Thanks
Code: Select all
def on_move(self):
doc = FreeCAD.ActiveDocument
for obj in doc.Objects:
if hasattr(obj,'Tip') :
if hasattr(obj.Tip,'Name') :
break
for i, fac in enumerate(obj.Shape.Faces): # Going through all faces of the object
facName = 'Face{:d}'.format(i+1) # Building face name from its index
print('{}'.format(facName))
Gui.Selection.add
Face1
Face2
Face3
Face4
Face5
Face6
Face7
Face8
Face9
Face10
Face11
Face12
Face13
Face14
Face15
Face16
Face17
Face18
Face19
Face20
Face21
Face22
Face23
Face24
Face25
Re: Messing around with the topo-naming issue
see if this help:
It will expose in the console all the properties of a face object.
But I can't point out what are you asking for.
Regards
Carlo D.
Code: Select all
print(dir(obj.Shape.Faces[0]))
But I can't point out what are you asking for.
Regards
Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
Re: Messing around with the topo-naming issue
I think you hit here the first topological naming barrier. My guess is that you don't want the feature associated with each face, because that is trivial: All faces are associated with the last feature. I guess you want to know which feature introduced a certain face for the first time.
In that case when you investigate a face you get a number for it and everything would be easy enough if you could search the feature where this number was introduced. But due to toponaming that could be a completely different face.
So you have to investigate the geometry, but that may not even exist anymore, look at this: This object was created in two steps: in the first step it was only a cube. But the interesting question is: when was the selected face introduced? It now has the number 10, which didn't even exist in the previous step.
If you can find out what any human sees immediately: "the selected face is basically the same as the top of the cube", you are probably close to solving the toponaming problem.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Messing around with the topo-naming issue
Thanks onekk, I have been looking for that "dir" statement.
I should have been a bit more clear on my use, it was late. My plan:
In each sketch store a copy of placement ( I update placement at some point) and the Label of the feature the sketch is connected to. I understand the renumbering of faces but regardless of face numbering the target feature name is still valid because the sketch was attached to a feature. So lets say sketch001 is attached to Pad001.Face3, I don't really care what face the sketch is connected to (at this point) I just want to know that I reconnect the sketch to Pad001, and then get a list of Faces of Pad001. On a recompute, face renumbering can occur, that's fine because I want the current list of the faces for each feature so I can reattach the sketch to it's feature. I will figure out the face attachment next.
I have a macro that can detect an error, it also will allow the user to move a selected sketch to different faces. That's where I need the list, I want to be able to take that sketch and move it to all the different faces of the feature it was originally attached to.
Let me know if there is something missing in my logic.
Using chrisb pic I want a list like this:
Maybe I need to work backwards up the chain, get the face # and then get the feature name. I haven't been able to do it with "getParentGeoFeatureGroup" as yet. I have been able to create this list but to do it I have to set "Tip" and loop thru the whole doc for every feature and then run more code. I was hoping for a faster approach.
Thanks
I should have been a bit more clear on my use, it was late. My plan:
In each sketch store a copy of placement ( I update placement at some point) and the Label of the feature the sketch is connected to. I understand the renumbering of faces but regardless of face numbering the target feature name is still valid because the sketch was attached to a feature. So lets say sketch001 is attached to Pad001.Face3, I don't really care what face the sketch is connected to (at this point) I just want to know that I reconnect the sketch to Pad001, and then get a list of Faces of Pad001. On a recompute, face renumbering can occur, that's fine because I want the current list of the faces for each feature so I can reattach the sketch to it's feature. I will figure out the face attachment next.
I have a macro that can detect an error, it also will allow the user to move a selected sketch to different faces. That's where I need the list, I want to be able to take that sketch and move it to all the different faces of the feature it was originally attached to.
Let me know if there is something missing in my logic.
Using chrisb pic I want a list like this:
Code: Select all
Face1, Pad
Face2, Pad
Face3, Pad
Face4, Pad
Face5, Pad
Face6, Pad
Face7, Pad001
Face8, Pad001
Face9, Pad001
Face10, Pad001
Face11, Pad001
Thanks
Re: Messing around with the topo-naming issue
Second post, there is a previous post answering comments.
Can anyone tell me why this model won't recompute? To be fair I have remapped the sketches many different times but I still don't get why it won't recompute without an error, and the error is cpp. All of the mappings look correct. I have seen this prior and I had to erase pad004 and reproduce it, then everything was fine.
Thanks
Can anyone tell me why this model won't recompute? To be fair I have remapped the sketches many different times but I still don't get why it won't recompute without an error, and the error is cpp. All of the mappings look correct. I have seen this prior and I had to erase pad004 and reproduce it, then everything was fine.
Thanks
- Attachments
-
- topo_test3.FCStd
- (52.36 KiB) Downloaded 15 times
-
- pad34error.JPG (75.96 KiB) Viewed 705 times
Last edited by freedman on Tue Dec 29, 2020 8:59 am, edited 1 time in total.