Messing around with the topo-naming issue

Need help, or want to share a macro? Post here!
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Messing around with the topo-naming issue

Post by chrisb »

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.
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.
freedman
Veteran
Posts: 3436
Joined: Thu Mar 22, 2018 3:02 am
Location: Washington State, USA

Re: Messing around with the topo-naming issue

Post by freedman »

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.
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Messing around with the topo-naming issue

Post by chrisb »

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.
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!
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.
freedman
Veteran
Posts: 3436
Joined: Thu Mar 22, 2018 3:02 am
Location: Washington State, USA

Re: Messing around with the topo-naming issue

Post by freedman »

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!
I see, good example. It would seem (after seeing this) the topo-naming fix is two-fold.

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?
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Messing around with the topo-naming issue

Post by chrisb »

freedman wrote: Sun Dec 20, 2020 12:18 am 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.
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.
freedman
Veteran
Posts: 3436
Joined: Thu Mar 22, 2018 3:02 am
Location: Washington State, USA

Re: Messing around with the topo-naming issue

Post by freedman »

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

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
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: Messing around with the topo-naming issue

Post by onekk »

see if this help:

Code: Select all

print(dir(obj.Shape.Faces[0]))
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.
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/
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Messing around with the topo-naming issue

Post by chrisb »

freedman wrote: Mon Dec 28, 2020 7:35 am Does anyone know a way to isolate the feature associated with each face.
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:
SnipScreenshot-e5e3f8.png
SnipScreenshot-e5e3f8.png (9.2 KiB) Viewed 465 times
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.
freedman
Veteran
Posts: 3436
Joined: Thu Mar 22, 2018 3:02 am
Location: Washington State, USA

Re: Messing around with the topo-naming issue

Post by freedman »

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:

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
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
freedman
Veteran
Posts: 3436
Joined: Thu Mar 22, 2018 3:02 am
Location: Washington State, USA

Re: Messing around with the topo-naming issue

Post by freedman »

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
Attachments
topo_test3.FCStd
(52.36 KiB) Downloaded 15 times
pad34error.JPG
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.
Post Reply